Open joafeldmann opened 9 years ago
I really like to see this feature to be implemented as well
I would also really like to see this feature in future releases
+1 :+1: Would be amazing
I'm wondering, what would be the benefit gained from this feature? If the bandwidth is throttled, will it affect the metrics? It would affect the timing metrics (timeToFirstByte, latency), but in a predictable way.
If that's the only difference, then it doesn't make sense to slow down the connection just to see a result that the connection was slow. Am I missing something?
Can someone go into more detail about the benefit?
My concerns are:
By throttling the bandwidth (like webpagetest does) you give developers more control over the Window performance metrics results. Moreover, we can see much better the difference between a mobile test and a desktop test, where not only the viewport size is different but also most of the other metrics.
Emulating RTT (Round Trip Time) will be great to test locally hosted app against various network connections and devices (WiFi vs 3G).
https://chromedevtools.github.io/devtools-protocol/tot/Network#method-emulateNetworkConditions - this is now provided by Chrome DevTools which we will use thanks to #707.
offline
True to emulate internet disconnection.
latency
Minimum latency from request sent to response headers received (ms).
downloadThroughput
Maximal aggregated download throughput (bytes/sec). -1 disables download throttling.
uploadThroughput
Maximal aggregated upload throughput (bytes/sec). -1 disables upload throttling.
connectionType
Connection type if known.
# Copied from
# WebKit/Source/devtools/front_end/network/NetworkConditionsSelector.js
# Units:
# download/upload: byte/s
# latency: ms
NETWORK_CONDITIONS = {
'GPRS': {
'download': 50 * 1024 / 8, 'upload': 20 * 1024 / 8, 'latency': 500},
'Regular2G': {
'download': 250 * 1024 / 8, 'upload': 50 * 1024 / 8, 'latency': 300},
'Good2G': {
'download': 450 * 1024 / 8, 'upload': 150 * 1024 / 8, 'latency': 150},
'Regular3G': {
'download': 750 * 1024 / 8, 'upload': 250 * 1024 / 8, 'latency': 100},
'Good3G': {
'download': 1.5 * 1024 * 1024 / 8, 'upload': 750 * 1024 / 8,
'latency': 40},
'Regular4G': {
'download': 4 * 1024 * 1024 / 8, 'upload': 3 * 1024 * 1024 / 8,
'latency': 20},
'DSL': {
'download': 2 * 1024 * 1024 / 8, 'upload': 1 * 1024 * 1024 / 8,
'latency': 5},
'WiFi': {
'download': 30 * 1024 * 1024 / 8, 'upload': 15 * 1024 * 1024 / 8,
'latency': 2}
}
See https://github.com/puppeteer/puppeteer/pull/6759 (in phantomas since https://github.com/macbre/phantomas/pull/857) -> use puppeteer.networkConditions
:
const puppeteer = require('puppeteer');
const slow3G = puppeteer.networkConditions['Slow 3G'];
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.emulateNetworkConditions(slow3G);
await page.goto('https://www.google.com');
// other actions...
await browser.close();
})();
@gmetais
The latest Puppeteer brings https://github.com/puppeteer/puppeteer/pull/7343 - CPU throttling emulation.
factor
<?[number]> Factor at which the CPU will be throttled (2x, 2.5x. 3x, ...). Passing null
disables cpu throttling.NOTE Real device CPU performance is impacted by many factors that are not trivial to emulate via the Chrome DevTools Protocol / Puppeteer. e.g core count, L1/L2 cache, thermal throttling impacting performance, architecture etc. Simulating CPU performance can be a good guideline, but ideally also verify any numbers you see on a real mobile device.
const puppeteer = require('puppeteer'); const slow3G = puppeteer.networkConditions['Slow 3G']; (async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.emulateCPUThrottling(2); await page.goto('https://www.google.com'); // other actions... await browser.close(); })();
Throttling bandwidth would be nice to simulate mobile connection speed.