Almost every decision about how fast a website feels is made on a device no customer owns. The team works on a quick machine with a short path to the server, acceptance runs on that same machine, and the report looks respectable. The field tells a different story: across all websites, 48 percent (Web Almanac 2025) pass the Core Web Vitals on mobile, while 56 percent (Web Almanac 2025) pass on desktop. Eight percentage points sounds manageable, but the gap is spread very unevenly across the three metrics – and for interactivity it turns into a chasm. This article explains why the test device is the wrong yardstick, which reference device actually matches the 75th percentile, what built-in throttling can and cannot do, and how both turn into a budget the work can be steered by. Where the time goes on weak hardware is what a technical performance analysis shows, putting field and lab data side by side.
Key takeaways
- The developer machine is a poor yardstick because a lab test is by design a single device on a single network in a single location (web.dev). In Germany, by contrast, 50.89 percent (Statcounter Global Stats) of page views come from a phone.
- The device gap is widest for interactivity: 97 percent (Web Almanac 2025) of sites have good INP on desktop against 77 percent (Web Almanac 2025) on the phone – 20 percentage points (Web Almanac 2025) apart, the widest of the three Core Web Vitals.
- The reference device is a mid-range phone, not a flagship: entry-level devices run single-core work about nine times (Performance Inequality Gap) slower than a current top-end phone, mid-tier devices more than 3.5 times (Performance Inequality Gap) slower.
- Throttling in the standard test is a fixed factor, not a device model: the multiplier is 4x (Lighthouse) and it works relative to the machine you measure on (Chrome for Developers) – the same configuration yields two different target devices on two machines.
- Public field data knows only three device classes (Chrome for Developers), derived from the user agent, and the browser signals are deliberately coarse: reported memory is rounded to the nearest power of two (MDN Web Docs).
- Device plus network produce a hard budget: 1.2 MiB (Performance Inequality Gap) on the critical path for a three-second goal, of which 0.62 MiB (Performance Inequality Gap) is JavaScript. The median mobile home page ships 632 KB (Web Almanac 2025) of JavaScript.
Why the developer machine is the wrong yardstick
A lab measurement is, by construction, a single point taken from a distribution. The Chrome documentation says so plainly: a lab test consists of a single device connected to a single network and run from a single geographic location (web.dev). That is not a flaw, it is the purpose – only under those conditions do two runs stay comparable. It becomes a problem when that one point stands in for the whole distribution and nobody justifies where the point sits. In Germany, 50.89 percent (Statcounter Global Stats) of page views come from phones and 47.38 percent (Statcounter Global Stats) from desktops, so the target device is probably not a machine with a power supply. How to line up lab and field numbers without ending up with two competing truths is covered in the article on field data versus lab data.
The clearest illustration of how far the device classes sit apart is the time the main thread stays blocked. In the HTTP Archive lab, which emulates one uniform device for mobile runs, the median blocking time is 1,916 milliseconds (Web Almanac 2025) against 92 milliseconds (Web Almanac 2025) on desktop. That is more than twentyfold on an identical page. At the upper end of the distribution the gap grows further: 7,555 milliseconds (Web Almanac 2025) on mobile against 802 milliseconds (Web Almanac 2025) on desktop at the 90th percentile. Same JavaScript, same dependencies, same order – only a different processor underneath. If you want to break that block into smaller pieces, the tooling is described in the article on breaking up long tasks.
A reading is a point, not a distribution
What the field data says about the device gap
The gap between phone and desktop does not point the same way across the three Core Web Vitals, and that is the first finding that takes the heat out of the discussion. For loading, desktop leads: 74 percent (Web Almanac 2025) good LCP against 62 percent (Web Almanac 2025) on mobile. For layout stability the picture flips, with 81 percent (Web Almanac 2025) of mobile pages and 72 percent (Web Almanac 2025) of desktop pages reaching a good CLS – narrow views with few columns simply shift less often. If you are hunting the causes of jumping layouts, they are laid out in the article on avoiding layout shifts. The device class is therefore not a blanket penalty; it bites where compute time is needed.
That is exactly why interactivity is the metric where weak hardware shows up most sharply. On desktop, 97 percent (Web Almanac 2025) of websites have good INP, on the phone 77 percent (Web Almanac 2025). The gap of 20 percentage points (Web Almanac 2025) is the widest of the three metrics and closes only slowly. INP measures the time from an input to the next paint, and that time is made up of script execution, style recalculation and layout – all work that lands on the visitor's CPU and not on the server. Which interventions actually help there is described in the article on improving Interaction to Next Paint.
| Metric | Desktop | Phone | Why |
|---|---|---|---|
| Good Core Web Vitals overall | 56 % | 48 % | network and compute combined |
| Good LCP | 74 % | 62 % | narrower network, slower decoding |
| Poor LCP | 7 % | 13 % | the unfavourable edge grows twice as fast on mobile |
| Good INP | 97 % | 77 % | script work depends on single-core speed |
| Good CLS | 72 % | 81 % | narrow views shift less often |
It gets more instructive when the mobile numbers are split by page type and popularity. Mobile home pages reach 80 percent (Web Almanac 2025) good INP, while secondary pages manage only 69 percent (Web Almanac 2025) – precisely the pages with filters, sorting, forms and a basket. And across the thousand most visited websites the figure drops to 63 percent (Web Almanac 2025), because that is where the most code runs. Popularity and budget therefore do not protect against the device gap; if anything they widen it. For test planning that means the benchmark is not the home page on the fast device but the interaction page on the slow one. What that kind of prioritisation looks like is shown in the article on reading a Lighthouse report.
The reference device is not the fastest one on the team
If script work is the bottleneck, then the single-core speed of the target device is the number everything hangs on. The analysis of global device distribution states it as a hard ceiling: the pace of JavaScript-driven experiences is largely gated by single-core performance, so the device at the 75th percentile sets a firm limit on how much JavaScript a website may lean on (Performance Inequality Gap). The spread behind that is considerable: entry-level devices run single-core work about nine times (Performance Inequality Gap) slower than a current top-end phone, and mid-tier devices more than 3.5 times (Performance Inequality Gap) slower. Measuring on a flagship is therefore not slightly optimistic, it is an order of magnitude off.
A typical device, not an outlier
The recommended reference device is a mid-range Android phone from 2023. It launched at 250 USD (Performance Inequality Gap), below the global average selling price of 353 USD (Performance Inequality Gap). The point is not frugality but representativeness: a quarter of all devices and networks sit below that mark.
The installed base ages slower than the test shelf
Phones stay in service longer. The annual replacement rate is estimated at 23.7 percent (TechInsights), which puts devices at the 75th percentile at nearly three years old. A test device replaced every year drifts further from the visitors' installed base with each passing year.
The network spread keeps widening
The distance between the 25th and 75th percentile of connectivity grew from 15 to 21 Mbps (Performance Inequality Gap), an increase of 40 percent (Performance Inequality Gap). The bottom quarter gained only 28 percent (Performance Inequality Gap) over the same period. Measuring on your own line means measuring the wrong edge.
A reference device needs a reference network, otherwise half of the delay stays invisible. For 2026 the 75th percentile of connectivity is given as 9 Mbps (Performance Inequality Gap) down, 3 Mbps (Performance Inequality Gap) up and 100 milliseconds (Performance Inequality Gap) round-trip time, derived from worldwide network measurement data without population weighting. These figures are uncomfortable because they contradict the everyday feeling in the office. They do, however, explain why the same page looks different in the field data than in the last acceptance report. Bringing the two together needs a fixed measurement profile rather than a daily mood – an approach the article on anchoring performance targets in tenders and acceptance works through for contracts.
The core in one sentence
Throttling is a factor, not a device model
The obvious answer to weak hardware is built-in throttling, and it is a good first step – as long as you know what it does. The default profile of the common mobile test throttles the network to 150 milliseconds (Lighthouse) of latency, 1.6 Mbps (Lighthouse) down and 750 Kbps (Lighthouse) up, with no packet loss. Compute is slowed by a constant multiplier of 4x (Lighthouse), which shifts a typical run from the range of high-end desktop machines roughly into mid-tier mobile territory. That is an approximation with a clear intention, and it is documented as exactly that.
The catch sits in the word constant. Throttling works relative to the machine you measure on: a 2x factor makes the CPU twice as slow as its usual performance, and the architecture of mobile devices cannot really be reproduced that way (Chrome for Developers). Two machines with the same factor therefore produce two different target devices. How wide the spread is shows up in the compute index from the same documentation: high-end desktop machines land at 1500 to 2000 (Lighthouse) points, mid-tier phones at 125 to 800 (Lighthouse). For the same news site that means 2 to 4 seconds (Lighthouse) of script execution at the top end and 20 to 40 seconds (Lighthouse) at the bottom.
{
"//": "Two profiles side by side -- default and reference network.",
"//": "The CPU factor is calibrated per machine, never copied.",
"default": {
"rttMs": 150,
"throughputKbps": 1638,
"uploadThroughputKbps": 750,
"cpuSlowdownMultiplier": 4
},
"reference_network_p75": {
"rttMs": 100,
"throughputKbps": 9000,
"uploadThroughputKbps": 3000,
"cpuSlowdownMultiplier": null,
"note": "derive the factor from the runner's own benchmark"
}
}What throttling does not reproduce
What field statistics really know about devices
Anyone hoping to read the device class straight out of field data hits a limit quickly. Public field statistics distinguish three device classes (Chrome for Developers) – phone, tablet and desktop – and derive them from the user agent string (Chrome for Developers). That says nothing about compute: a top-end phone and a five-year-old entry-level device land in the same bucket. At least the scoring logic itself is device-aware: the threshold for good INP is 200 milliseconds (web.dev), measured at the 75th percentile (web.dev) of page loads and explicitly segmented between mobile and desktop devices. That segmentation is precisely why an average across all devices is rarely a usable basis.
In the browser itself two signals are available, and both are imprecise on purpose. Reported memory is deliberately blurred to make fingerprinting harder: the actual value is rounded to the nearest power of two and then divided by 1024 (MDN Web Docs). The core count carries a similar caveat – the browser may report a lower number of logical processors to better reflect how many workers can run at once, so the value does not serve as an absolute measure (MDN Web Docs). As a signal for coarse bucketing in your own field measurement both are still enough, as long as you treat them as buckets and not as readings.
// Coarse bucketing for your own field measurement.
// Both signals are deliberately fuzzy -- buckets, not numbers.
function deviceClass() {
const cores = navigator.hardwareConcurrency || 0; // may be reported lower
const memory = navigator.deviceMemory || 0; // rounded to a power of 2
if (!cores && !memory) return 'unknown'; // do not guess
if (memory && memory <= 2) return 'weak';
if (cores && cores <= 4 && memory <= 4) return 'weak';
if (cores <= 6 || memory <= 4) return 'mid';
return 'strong';
}
// Attach the class to every reading, or the report averages it away.
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
navigator.sendBeacon('/metrics/', JSON.stringify({
metric: 'inp',
value: Math.round(entry.duration),
deviceClass: deviceClass(),
pageType: document.body.dataset.pageType
}));
}
}).observe({ type: 'event', durationThreshold: 40, buffered: true });From reference device to a budget that holds
Reference device and reference network only become useful once they turn into a number a design can be checked against. Converted into a budget, a three-second goal leaves 1.2 MiB (Performance Inequality Gap) on the critical path, of which 0.62 MiB (Performance Inequality Gap) is JavaScript when half the page is script. Reality looks different: mobile JavaScript payloads reach 680 KiB (Performance Inequality Gap) at the median and 1.3 MiB (Performance Inequality Gap) at the 75th percentile. The median mobile home page ships 632 KB (Web Almanac 2025) of JavaScript – the second largest item after images, and the only one that also costs compute time on weak hardware. How to derive concrete limits per page type from that is described in the article on JavaScript and performance budgets.
- Name the target device and write it down: one device class, one network profile, one percentile. Without those three, every later discussion about readings is a discussion about equipment.
- Buy a real device from the target class and keep it on the shelf. It does not replace the throttled run, but it exposes what a constant factor cannot reproduce.
- Calibrate the throttling factor per machine instead of copying it – the factor works relative to the compute power present (Chrome for Developers) and moves with every new runner in the pipeline.
- Extend your own field measurement with a coarse device class and evaluate metrics per class. An average across all devices hides exactly the edge that matters.
- Use the interaction page as the benchmark rather than the home page: on mobile, secondary pages sit at 69 percent (Web Almanac 2025) good INP against 80 percent (Web Almanac 2025) for home pages.
- Put the budget into the build pipeline as a limit and make every deviation visible instead of discovering it at the next acceptance review. What low-risk experimentation looks like alongside that is shown in the article on A/B tests without flicker.
That weight and pass rate are connected can be read straight from the field: among mobile home pages under one megabyte, 57 percent (Web Almanac 2025) pass the Core Web Vitals, while from five megabytes upward only 30 percent (Web Almanac 2025) do. The rate falls with every weight class, and in every single class the mobile figure sits below the desktop one. That is the real reason a budget achieves more than a list of individual optimisations: it limits the cause instead of treating symptoms after the fact. If you also want to adapt delivery to the visitor's network, the building blocks are in the article on adaptive loading on slow connections.
The uncomfortable question in every performance conversation is not how fast the page loads on the team's machine. It is: on which device should it still be good – and who decided that it is this one?
Target device instead of test device is therefore less a technical decision than an organisational one. The technology behind it is modest: a named device, a named network, a calibrated factor, a bucketing scheme in your own field measurement, and a budget that follows from both. The hard part is resolving to be measured against that bar even though your own machine returns better numbers. Those who make that call get figures that hold in the field what they promise in the report. Which metrics count and how they interact is set out on our page about the Core Web Vitals; where compute time goes on weak hardware for your website is answered by an analysis with field and lab data together with our frontend optimisation.
Sources and Studies
Related Articles
fetchLater: Sending Beacons Without Costing Speed
Farewell events often fail to deliver the final measurement on mobile. How fetchLater() fixes that, which quota applies and what the fallback looks like.
Soft Navigations: Measuring Core Web Vitals in SPAs
Single-page apps only report the first load to CrUX. How the Soft Navigations API from Chrome 151 measures route changes and splits LCP, INP and CLS per route.
Style Recalculation: When CSS Slows the Browser Down
Why style calculation costs time at runtime, how Selector Stats and Long Animation Frames make its share visible, and which changes actually shrink the scope.