Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibility to throttle bandwidth #493

Open
joafeldmann opened this issue Feb 5, 2015 · 10 comments
Open

Possibility to throttle bandwidth #493

joafeldmann opened this issue Feb 5, 2015 · 10 comments
Labels
Chrome-headless Tasks related with migration from PhantomJS to Puppeteer's headless Chrome enhancement
Milestone

Comments

@joafeldmann
Copy link

Throttling bandwidth would be nice to simulate mobile connection speed.

@macbre macbre added this to the Roadmap milestone Feb 5, 2015
@macbre macbre modified the milestones: Roadmap, v1.11 Mar 1, 2015
@macbre macbre added the research label Mar 3, 2015
@macbre macbre modified the milestones: Roadmap, v1.11 Mar 3, 2015
@tufandevrim
Copy link

I really like to see this feature to be implemented as well

@lightheaded
Copy link

I would also really like to see this feature in future releases

@macbre macbre modified the milestones: Roadmap, v1.12 May 5, 2015
@albertogasparin
Copy link

+1 👍
Would be amazing

@ts-web
Copy link

ts-web commented May 6, 2015

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?

@albertogasparin
Copy link

My concerns are:

  • how much my computer connection affects the results? And how can we mitigate the difference between my tests over a 100Mbps connection vs a 10Mbps connection?
  • how can we better track front-end code improvements? Because if I made some changes that affect mobile domContentLoaded time by 0.5s over a 3G connection, they can be nearly invisible on a 100Mbps test.

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.

@macbre
Copy link
Owner

macbre commented May 8, 2015

Emulating RTT (Round Trip Time) will be great to test locally hosted app against various network connections and devices (WiFi vs 3G).

@macbre macbre modified the milestones: v1.12, v1.11 May 8, 2015
@macbre macbre modified the milestones: v1.11, Roadmap May 30, 2015
@macbre macbre modified the milestones: v1.14, Roadmap Oct 27, 2015
@macbre macbre modified the milestones: v1.14, Roadmap Dec 19, 2015
@macbre macbre removed this from the v1.14 milestone Dec 19, 2015
@macbre macbre added Chrome-headless Tasks related with migration from PhantomJS to Puppeteer's headless Chrome and removed research labels Dec 31, 2018
@macbre
Copy link
Owner

macbre commented Dec 31, 2018

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.

@macbre macbre pinned this issue Dec 31, 2018
@macbre macbre unpinned this issue Aug 26, 2020
@macbre macbre modified the milestones: Roadmap, v2.1 Oct 26, 2020
@macbre
Copy link
Owner

macbre commented Nov 12, 2020

Resources

https://source.chromium.org/chromium/chromium/src/+/refs/tags/72.0.3626.30:tools/android/loading/emulation.py

# 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}
}

@macbre macbre modified the milestones: v2.1, v2.2 Jan 9, 2021
@macbre
Copy link
Owner

macbre commented Feb 3, 2021

See puppeteer/puppeteer#6759 (in phantomas since #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

@macbre macbre modified the milestones: v2.2, v2.3 Apr 7, 2021
@macbre
Copy link
Owner

macbre commented Jun 29, 2021

The latest Puppeteer brings puppeteer/puppeteer#7343 - CPU throttling emulation.


page.emulateCPUThrottling(factor)

  • factor <?[number]> Factor at which the CPU will be throttled (2x, 2.5x. 3x, ...). Passing null disables cpu throttling.
  • returns: <[Promise]>

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();
})();

@macbre macbre modified the milestones: v2.3, v2.4 Jun 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Chrome-headless Tasks related with migration from PhantomJS to Puppeteer's headless Chrome enhancement
Projects
None yet
Development

No branches or pull requests

6 participants