Network and CPU throttling
Making a fast test machine behave more like a slow phone or connection, so performance problems appear under repeatable conditions.
See it
What it is
Network and CPU throttling deliberately slow a lab test so fast developer hardware behaves more like a constrained visit. Network throttling adds latency and caps download and upload throughput. CPU throttling stretches main-thread work, exposing JavaScript, style, layout, and paint costs that disappear on a new laptop.
Use both for repeatable comparisons between builds. Chrome DevTools ships named Network presets such as Slow 4G and Fast 4G plus 4x and 20x CPU slowdown, and Lighthouse runs its mobile audit under a fixed profile of its own, which makes a before and after result useful even when it is not a perfect model of any one phone or mobile network.
Gotcha: throttling is a simulation, not a device lab. A desktop with a CPU multiplier still has different memory, thermal limits, GPU, radio, and scheduling behavior from a budget phone. Keep one lab profile fixed for regression testing, then check field data or real hardware before claiming users will see the same number.
Ask AI for it
Create a repeatable mobile lab profile in Chrome DevTools using a custom Network throttling profile and CPU throttling. Record the exact latency, download throughput, upload throughput, and CPU slowdown multiplier in the test README. Run three cold-cache loads at a fixed mobile viewport, collect the median LCP, Total Blocking Time, and Speed Index from Lighthouse, then repeat three warm-cache loads without changing any other setting. Save the Lighthouse reports as artifacts and print the throttle settings beside every result. Use this fixed profile for build-to-build regression checks, and keep the results separate from CrUX or other real-user field data.