Skip to content

Latest commit

 

History

History
58 lines (37 loc) · 4.32 KB

throttling.md

File metadata and controls

58 lines (37 loc) · 4.32 KB

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. They are identical to the WebPageTest "Mobile 3G - Fast" preset and, due to a lower latency, slightly faster for some pages than the WebPageTest "4G" preset.

Throttling basics

  1. Simulated throttling, which Lighthouse uses by default, is computed throttling after a trace has been recorded which makes it 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. The DevTools network throttling, which Lighthouse uses for throttlingMethod='devtools', is implemented within Chrome at the request-level. As a result, it has some downsides that are now summarized in this doc: 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 not recommended.
  4. Packet-level throttling tools are able to make the most accurate network simulation.

How do I get high-quality packet-level throttling?

If you want to use more accurate throttling, read on.

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.

Using comcast for network throttling

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=1600 --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=1600

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

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