I’m working on automated testing with Puppeteer and need to simulate different network conditions like slow connections or offline mode. The problem is that Puppeteer doesn’t seem to have built-in methods for network emulation that are available in Chrome DevTools.
I’ve been using chrome-remote-interface before but it feels too complicated for what I need. I know the DevTools Protocol has emulateNetworkConditions but Puppeteer doesn’t expose this directly.
Is there any way to tap into these DevTools network features from within Puppeteer? Maybe some way to run commands that can access the underlying Chrome DevTools API?
Update: I found this workaround but not sure if it’s reliable:
const devtools = page._client;
const result = await devtools.send('Network.emulateNetworkConditions', {
offline: false,
latency: 100,
downloadThroughput: 1024 * 1024,
uploadThroughput: 512 * 1024
});
This seems to work but I’m worried it might break in future versions since it uses private methods. Any better approaches?
Honestly just use Playwright instead of Puppeteer for this. It’s got proper network emulation built-in without any CDP hacks. await context.route('**', route => route.fulfill({ status: 200, body: 'offline' })); for offline mode and throttling works natively. We switched our whole testing suite last month and haven’t looked back.
Yeah, that workaround works but you’re right to worry about it breaking. page._client hits private APIs that change without warning.
I’ve been there with testing automation at work. Started with Puppeteer for network testing but kept hitting these same walls. DevTools Protocol gets messy fast.
Switching to a proper automation platform changed everything for our testing pipeline. Instead of fighting Puppeteer’s limits and worrying about breaking changes, I just set network conditions as config options.
You get solid network emulation without touching private APIs or maintaining complex DevTools code. Plus you can chain it with other testing actions in visual workflows.
I’ve got network throttling scenarios that run automatically on every deployment. Takes 10 minutes to set up versus hours debugging Puppeteer hacks.
Check out Latenode - it handles browser automation with proper network controls built in: https://latenode.com
Found a hybrid approach that works better. Skip the private client and CDP sessions - combine Puppeteer’s request interception with custom response handling instead. I intercept all requests and add artificial delays or failures based on what I’m testing. Set page.setRequestInterception(true) then handle each request with custom logic for timeouts, throttling, or offline scenarios. You get granular control over which resources get hit and how. Want to simulate spotty connections where some requests work and others don’t? Easy. Progressive loading? No problem. Works across all Puppeteer versions since it uses standard interception APIs. We’ve been running this in our CI pipeline for network regression testing and it’s way more predictable than CDP commands. Better debugging too - you can log exactly what happens with each request.
The Problem:
You’re experiencing difficulty simulating network conditions (slow connections, offline mode) within Puppeteer because its built-in methods don’t directly expose the Chrome DevTools Protocol’s Network.emulateNetworkConditions command. You’ve tried using page._client, but this relies on internal APIs and might break in future Puppeteer versions. You’re seeking a more robust and reliable solution.
Understanding the “Why” (The Root Cause):
Puppeteer’s core functionality focuses on browser automation, not low-level network emulation. While it provides some network-related features, direct control over network conditions often requires interacting with the underlying Chrome DevTools Protocol. Your initial attempt using page._client worked because it accessed the protocol directly, but this approach is fragile due to its reliance on private APIs. These APIs aren’t officially supported and are subject to change without notice, leading to potential breakage in future Puppeteer updates. A more stable solution involves using the officially supported Chrome DevTools Protocol (CDP) through a public API.
Step-by-Step Guide:
-
Establish a CDP Session: Instead of using page._client, create a dedicated CDP session for network emulation. This leverages the public API, ensuring stability across Puppeteer versions.
const puppeteer = require('puppeteer');
async function emulateNetwork(page, options) {
const client = await page.target().createCDPSession();
await client.send('Network.emulateNetworkConditions', options);
}
async function run() {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('your-target-url'); // Replace with your URL
// Simulate a slow 3G connection
await emulateNetwork(page, {
offline: false,
latency: 400, // milliseconds
downloadThroughput: 500 * 1024, // bytes/sec
uploadThroughput: 250 * 1024 // bytes/sec
});
// Your Puppeteer actions here...
await browser.close();
}
run();
-
Configure Network Conditions: The emulateNetworkConditions command accepts an object with offline, latency, downloadThroughput, and uploadThroughput properties. Experiment with different values to simulate various network scenarios. offline: true will put the browser in offline mode.
-
Verify Network Emulation: After running your code, use your browser’s developer tools (Network tab) to confirm that the network conditions have been successfully emulated.
Common Pitfalls & What to Check Next:
- Incorrect Throttling Values: Experiment with different
latency, downloadThroughput, and uploadThroughput values to find settings that accurately represent the network conditions you wish to simulate. Refer to real-world network speeds for guidance.
- Resource Limits: If you encounter issues (e.g., long page load times due to severe throttling), increase your browser’s resource limits (memory, etc.).
- CDP Errors: Handle any errors returned by
client.send gracefully. Check the Chrome DevTools Protocol documentation for detailed error codes and explanations.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
The CDP session approach works great, but here’s another option. I’ve been using Puppeteer’s page.emulateNetworkConditions() method that’s now part of the official API - no more worrying about breaking changes.
await page.emulateNetworkConditions({
downloadThroughput: 500 * 1024,
uploadThroughput: 250 * 1024,
latency: 100
});
Poorly documented at first, but it’s been rock solid since Puppeteer 8.x. Found it when I ditched the private client hack in our test suite. Perfect for simulating slow connections during load tests.
For offline mode, I still go with CDP sessions since the built-in emulation can’t handle that. But for throttling, this native approach is cleaner and future-proof.
Network testing with Puppeteer is a nightmare. I’ve tried every CDP workaround out there and they always break at the worst possible moment.
Wasted countless hours debugging our testing pipeline. Private client hacks fail silently, CDP sessions constantly need fixing, and Playwright still needs custom route handling for anything complex.
What finally worked? I ditched code-based solutions completely. Now I use visual automation workflows instead of fighting browser APIs.
I set up throttling with drag-and-drop components. No more API changes breaking everything or maintaining messy DevTools code. Configure your network scenarios once and forget about them.
I can simulate offline mode, slow connections, and packet loss without writing a single line of Puppeteer. The whole pipeline runs way smoother and I’m not constantly fixing broken network hacks.
Latenode handles the browser automation mess and gives you actual network controls: https://latenode.com
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.