A developer runs PageSpeed Insights against a new landing page from a fast office connection, taps the device toolbar in Chrome DevTools to switch the preview to “Mobile,” watches the layout reflow correctly, and ships it. Three weeks later, Search Console’s Core Web Vitals report shows the same page failing INP for most of its real mobile traffic — and nothing about the page has changed since launch. That wasn’t a regression. It was there from day one. The “mobile” the developer tested was a resized browser window running on a desktop-class CPU over office wifi. The mobile that actually showed up was a two-year-old mid-range Android phone on a train, switching between a full 4G bar and a dropped signal every few minutes.
This guide assumes you’ve already worked through the general fixes for LCP, CLS, and INP — if you haven’t, start with how to improve Core Web Vitals in WordPress and come back here. What that guide doesn’t cover, and what actually explains the gap above, is the layer underneath the three metrics: what your testing setup is actually simulating, how far off that simulation is from a real phone on a real network, and what to do instead.
What Toggling “Mobile” in DevTools Actually Changes
Clicking the device toolbar icon in Chrome DevTools changes three things: the viewport dimensions, the user-agent string, and whether touch events fire instead of mouse events. That’s the entire list. It does not throttle the CPU. It does not throttle the network. It does not touch the GPU. The page you’re looking at after that toggle is running exactly as fast as it would on your own machine — just narrower.
This matters because the toggle is genuinely useful for what it does (checking a responsive layout doesn’t break at 390px wide) and genuinely misleading for what it implies. A page that looks correct in the resized viewport and loads instantly because it’s still running on your laptop’s CPU over your office connection tells you nothing about how it performs for the visitor it’s actually named after. CPU and network throttling exist as separate, opt-in settings inside DevTools’ Performance and Network panels — and in most workflows I’ve seen, nobody ever turns them on, because the viewport already looks like a phone and that reads as “done.”
How Far Off Your Test Machine’s CPU Really Is
Even when CPU throttling is switched on, the number behind it has been a moving target. Lighthouse’s long-standing default is a flat 4x slowdown multiplier applied to whatever machine is running the audit — described in Lighthouse’s own throttling documentation as an attempt to move “a typical run in the high-end desktop bracket” down into “the mid-tier mobile bracket.” It’s a single, hardware-agnostic guess, applied the same way whether you’re running the audit on a five-year-old laptop or a current MacBook Pro.
Google has already adjusted this once because the guess wasn’t holding up. A December 5, 2024 entry in PageSpeed Insights’ own release notes states the CPU throttling factor was changed “to account for the low CPU performance benchmarks typical in PageSpeed Insights production environments,” and that the change “should result in increased lab data TBT scores for sites on mobile.” In plain terms: PSI’s servers are themselves slower than most developer laptops, so the flat 4x multiplier was under-representing how a real mobile visitor experiences a busy page. If you run Lighthouse locally with its untouched 4x default and compare the score against what PageSpeed Insights reports for the same URL, don’t expect them to match — they’re no longer using the same throttling assumption, and most write-ups on this topic still don’t mention that.
Chrome tried to fix the guesswork properly starting in Chrome 134, with a feature Chrome DevTools calls calibrated throttling. Instead of applying a fixed multiplier to whatever machine you happen to be using, DevTools benchmarks your actual hardware for a few seconds and generates “low-tier mobile” and “mid-tier mobile” presets tuned to it specifically. It’s a real improvement — and it also exposed exactly how wrong the old fixed defaults were. Harry Roberts, writing for CSS Wizardry in August 2025, ran the calibration on his own development machine and found mid-tier mobile came out at 2.9x slower than his hardware, and low-tier at “a staggering 9.1x slower” — both well past DevTools’ old fixed 4x and 6x presets. His reference devices for what “low-tier” and “mid-tier” actually mean in 2025 are worth keeping in mind: a Samsung Galaxy A15 5G (MediaTek Dimensity 6100+, 4–8GB of LPDDR4X RAM, UFS 2.2 storage) for low-tier, and a Galaxy A54 5G (Exynos 1380) for mid-tier — his description of the A54 as “the volume mid-range many Europeans actually buy” is a far more useful mental model than an abstract multiplier.
Even calibrated CPU throttling has a hard boundary, and it’s worth knowing where it sits rather than assuming throttling covers everything. It only affects the CPU. Mobile and desktop GPUs differ architecturally, and throttling doesn’t touch the GPU process at all — Chrome’s own team gives the example of a GPU-heavy CSS effect (a blur filter, a large box-shadow) that renders identically fast in a calibrated DevTools test and takes 300ms or more longer on the real phone it’s supposedly simulating. Slower disk I/O, tighter memory bandwidth, and thermal throttling after twenty minutes of use in someone’s pocket are also outside what any CPU multiplier can account for. Calibration narrows the gap. It doesn’t close it.
The Network Profiles That Actually Matter
Network throttling splits into two genuinely different techniques, and knowing which one a tool is using changes how much you should trust the result. Lighthouse (and by extension PageSpeed Insights) uses simulated throttling: it runs the page once, unthrottled, then mathematically predicts what a throttled load would have looked like based on that trace. It’s fast and consistent, which is why it’s the default for a quick check. WebPageTest and Chrome DevTools’ Network panel instead use packet-level throttling, which actually shapes the traffic in real time rather than predicting it. Lighthouse’s own documentation is direct about which one to trust for a real investigation: “a deep investigation to performance should use packet-level throttling tools,” not the simulated estimate.
The specific numbers behind each profile matter too, because they’re not interchangeable even when they share a label:
| Profile | Download | Upload | Latency | Method |
|---|---|---|---|---|
| Lighthouse / PSI simulated mobile (default) | 1.6 Mbps | 750 Kbps | 150ms RTT | Simulated |
| DevTools “Slow 4G” | 1.4 Mbps | — | 562ms min. | Packet-level (matched to Lighthouse’s figure for comparability) |
| DevTools “Fast 4G” | 9 Mbps | — | 165ms min. | Packet-level |
| WebPageTest “3G – Regular” | 1.6 Mbps | 768 Kbps | 300ms | Packet-level, real device |
| WebPageTest “4G” | 9 Mbps | 9 Mbps | 170ms | Packet-level, real device |
| WebPageTest “Cable” (default if unset) | 5 Mbps | 1 Mbps | 28ms | Packet-level, real device |
Two things in that table are worth flagging directly. First, WebPageTest’s default connection profile is Cable, not a mobile one — if you run a test without explicitly picking a mobile device and a 3G or 4G profile, you’ve tested nothing that resembles a cellular connection at all, which is an easy setting to miss the first few times. Second, WebPageTest’s 3G profile is deliberately modeled on measured real-world connections from around 2014, not a current spec — it’s a conservative, worst-case baseline rather than “typical 3G today,” which is exactly why it’s still a useful stress test even in a mostly-4G/5G world. Latency, not just bandwidth, is doing a lot of the damage in the mobile profiles above — if your server response time is already stretched by a distant server location, a 300ms round trip on top of that compounds fast.
Testing on an Actual Phone, Not a Simulated One
WebPageTest’s free public instance isn’t just packet-level throttling against an emulator — its Dulles, Virginia location tests against physical Motorola G4 phones, real hardware that has been part of the tool’s free offering for years and is, by multiple long-standing accounts, literally sitting in the home lab of the person who built WebPageTest. That’s a genuine real-device test, and it’s worth using specifically because it removes every assumption baked into CPU/GPU throttling at once.
It also comes with a limit worth stating plainly rather than glossing over: the Moto G4 shipped in 2016 and is locked to Android 7. A test against it is a real device, but not a representative one for 2026 mobile traffic — closer to the low end of what the CSS Wizardry reference devices above describe than to a typical current mid-range phone like the Galaxy A54. “Real hardware” and “representative hardware” are two different claims, and a testing setup can satisfy one without the other. For most single-site owners this is still a useful, free data point precisely because it’s a hard floor — if a page performs acceptably on a nine-year-old phone over a 2014-grade 3G profile, it’s in reasonable shape for the mobile traffic that actually matters. If it doesn’t, that’s a real signal, not noise from an unrepresentative device.
The most practical upgrade beyond that free test, for a single WordPress site, isn’t a paid real-device-cloud subscription — those exist and are built for teams testing many device/browser combinations at once, which is more infrastructure than most individual sites need day to day. It’s simpler and cheaper than that: keep one current mid-range Android phone around, put it on an actual cellular connection rather than wifi, and load the live production URL on it every so often, particularly after a theme update, a new plugin, or before anything you’re treating as a real launch.
Why INP Specifically Punishes Mobile
Interaction to Next Paint became a stable Core Web Vital on March 12, 2024, replacing First Input Delay. Its thresholds, per Google’s own definition, are good at 200 milliseconds or below, needs improvement between 200 and 500ms, and poor above 500ms — measured at the 75th percentile of a site’s real user interactions. Google reports LCP, CLS, and INP separately for mobile and desktop, and the thresholds themselves are identical numbers for both. The real-world pass rates behind those identical numbers are not: an analysis of May 2026 CrUX data found desktop origins passing the “good” INP threshold 97.9% of the time, against 82.5% for mobile — a roughly 15-point gap, and the widest divergence between mobile and desktop of any of the three metrics after LCP.
The reason traces straight back to what INP measures: the delay between an interaction and the browser’s next visual update, which is overwhelmingly CPU-bound main-thread work. Identical JavaScript — the same event handler, the same DOM update, the same third-party script reacting to a click — that runs in 40ms on a desktop CPU can easily take 150 to 300ms or more on a mid-tier mobile chipset doing the exact same work, for the CPU-multiplier reasons covered above. A page can genuinely feel instant to whoever built and tested it on a laptop while feeling sluggish to most of its actual mobile visitors, and INP is the metric built specifically to catch that gap. The fix isn’t mobile-specific code — it’s the same JavaScript-reduction work covered in auditing third-party scripts and removing render-blocking resources, it just matters more on mobile because the CPU has far less headroom to absorb it.
A Mobile Testing Routine You Can Actually Run
- Start with real-user data, not a lab test. In Search Console’s Core Web Vitals report, filter by device and look at Mobile specifically — this is field data from actual visitors on actual hardware, and it’s the baseline everything else below is trying to approximate. See tracking website performance after launch for how to keep this in view on an ongoing basis rather than checking it once.
- Run PageSpeed Insights and read it as already-throttled. As covered above, PSI applies its own adjusted mobile CPU and network throttling by default — see how to use Google PageSpeed Insights for what its report actually shows. Don’t layer DevTools throttling on top of a DevTools-embedded Lighthouse run and treat it as a second, independent data point; it’s the same simulation compounding itself.
- Use calibrated CPU throttling in DevTools for fast local iteration. Run the calibration (Performance panel → Throttling → Calibrate) on your actual development machine, or better, on a genuinely weaker laptop if one is available, and use the resulting low-tier or mid-tier preset while you work. It’s the fastest feedback loop, and per the numbers above, calibrated is a meaningfully better guess than the old fixed defaults — but it’s still a guess, not a replacement for the next two steps.
- Run WebPageTest against your live production URL, not localhost, on a mobile device and a 3G or 4G profile. This is packet-level throttling against real hardware, and testing the actual cached, CDN-served production page (rather than an uncached local environment) is what makes the result meaningful.
- Keep one real mid-range phone around for anything that counts as a launch. A current Android device on an actual cellular connection catches what no amount of throttling can — GPU behavior, thermal effects, and simply what the page feels like to hold and use.
- Re-test after every plugin or theme update, not just at launch. A script addition that adds an imperceptible 20ms on your desktop CPU can add 150ms or more on the mobile chipsets your visitors are actually using — small changes compound faster on hardware with less headroom to spare.
Where This Testing Setup Usually Falls Apart
- Treating the DevTools viewport toggle as a performance test. It changes what the page looks like, not how fast it runs. Confirming a layout doesn’t break at phone width and confirming the page performs well on a phone are two separate checks.
- Assuming a single PageSpeed Insights run generalizes. A lab score is one measurement under one set of assumptions. The 75th-percentile field data in Search Console reflects the actual spread of devices and connections your real visitors show up on — a lab score that looks good doesn’t mean three in four real mobile visitors are having that experience.
- Testing localhost or staging instead of the live cached page. Caching, a CDN, and production-only optimizations can all change the result meaningfully — a staging environment without them tells you very little about what a real visitor actually loads.
- Trusting calibrated throttling as a permanent substitute for a real device. It’s a genuine improvement over the old fixed multipliers, and it still only covers CPU — GPU work, thermal throttling, and disk I/O are outside what it can simulate at all.
The Real Standard Is Whoever’s Actually Visiting, Not Your Laptop
Every tool covered here sits somewhere on the same spectrum, from a viewport toggle that changes nothing about speed, through simulated throttling, calibrated CPU throttling, a free but aging real device, up to a current mid-range phone on a real cellular connection. None of them is wrong to use — they answer different questions at different speeds. The mistake is treating whichever one is fastest to run as if it answers all of them. Search Console’s field data is the one number in this whole chain that isn’t a simulation of anything: it’s the actual population of devices and networks visiting the site, which is the only standard any of the lab tools above are trying to approximate in the first place.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.