Skip to content

Latest commit

 

History

History
70 lines (44 loc) · 6.58 KB

throttling.md

File metadata and controls

70 lines (44 loc) · 6.58 KB
Raw

The mobile network throttling preset

This is the standard recommendation for mobile throttling:

  • Latency: 150ms
  • Throughput: 1.6Mbps down / 750 Kbps up.
  • Packet loss: none.

These exact figures are used as Lighthouse's throttling default and represent roughly the bottom 25% of 4G connections and top 25% of 3G connections (In Lighthouse it is sometimes called "Slow 4G" used to be labeled as "Fast 3G"). This preset is identical to the WebPageTest's "Mobile 3G - Fast" and, due to a lower latency, slightly faster for some pages than the WebPageTest "4G" preset.

Types of throttling

Within web performance testing, there are four typical styles of throttling:

  1. Simulated throttling, which Lighthouse uses by default, uses a simulation of a page load, based on the data observed in the initial unthrottled load. This approach which makes it both very fast and deterministic. However, due to the imperfect nature of predicting alternate execution paths, there is inherent inaccuracy that is summarized in this doc: Lighthouse Metric Variability and Accuracy. The TLDR: while it's roughly as accurate or better than DevTools throttling for most sites, it suffers from edge cases and a deep investigation to performance should use Packet-level throttling tools.
  2. Request-level throttling , also referred to as Applied throttling in the Audits panel or devtools throttling in Lighthouse configuration, is how throttling is implemented with Chrome DevTools. In real mobile connectivity, latency affects things at the packet level rather than the request level. As a result, this throttling isn't highly accurate. It also has a few more downsides that are summarized in Network Throttling & Chrome - status. The TLDR: while it's a decent approximation, it's not a sufficient model of a slow connection. The multipliers used in Lighthouse attempt to correct for the differences.
  3. Proxy-level throttling tools do not affect UDP data, so they're decent, but not ideal.
  4. Packet-level throttling tools are able to make the most accurate network simulation. While this approach can model real network conditions most effectively, it also can introduce more variance than request-level or simulated throttling. WebPageTest uses packet-level throttling.

Lighthouse, by default, uses simulated throttling as it provides both quick evaluation and minimized variance. However, some may want to experiment with more accurate throttling... Learn more about these throttling types and how they behave in in different scenarios.

DevTools' Audits Panel Throttling

In Chrome 79 and earlier, you could choose between the throttling types of Simulated, Applied, and none.

Starting with Chrome 80, the Audits panel is simplifying the throttling configuration:

  1. Simulated throttling remains the default setting. This matches the setup of PageSpeed Insights and the Lighthouse CLI default, so this provides cross-tool consistency.
  2. No throttling is removed as it leads to innacurate scoring and misleading metric results.
  3. Within the Audits panel settings, you can uncheck the Simulated throttling checkbox to use Applied throttling. For the moment, we are keeping this Applied throttling option available for users of the View Trace button. Under applied throttling, the trace matches the metrics values, whereas under Simulated things do not currently match up.

We plan to improve the experience of viewing a trace under simulated throttling. At that point, the Applied throttling option will be removed and Simulated throttling will be the only option within the DevTools Audits panel. Of course, CLI users can still control the exact configuration of throttling.

How do I get packet-level throttling?

This Performance Calendar article, Testing with Realistic Networking Conditions, has a good explanation of packet-level traffic shaping (which applies across TCP/UDP/ICMP) and recommendations.

The comcast Go package appears to be the most usable Mac/Linux commandline app for managing your network connection. Important to note: it changes your entire machine's network interface. Also, comcast requires sudo (as all packet-level shapers do).

Windows? As of today, there is no single cross-platform tool for throttling. But there are two recommended Windows-specific network shaping utilities: WinShaper and Clumsy.

comcast set up

# Install with go
go get github.com/tylertreat/comcast
# Ensure your $GOPATH/bin is in your $PATH (https://github.com/golang/go/wiki/GOPATH)

# To use the recommended throttling values:
comcast --latency=150 --target-bw=1638 --dry-run

# To disable throttling
# comcast --stop

Currently, comcast will also throttle the websocket port that Lighthouse uses to connect to Chrome. This isn't a big problem but mostly means that receiving the trace from the browser takes significantly more time. Also, comcast doesn't support a separate uplink throughput.

Using Lighthouse with comcast

# Enable system traffic throttling
comcast --latency=150 --target-bw=1638

# Run Lighthouse with its own throttling disabled
lighthouse --throttling.requestLatencyMs=0 --throttling.downloadThroughputKbps=0 --throttling.uploadThroughputKbps=0 # ...

# Disable the traffic throttling once you see "Gathering trace"
comcast --stop