The gap
A page that loads in under a second on a developer's laptop takes four on the phone most of its visitors own. That is not an exaggeration and it is not a slow network: a mid-range Android from a couple of years ago has perhaps a fifth of the single-core JavaScript performance of a recent laptop, and Core Web Vitals field data is collected from real devices, weighted by real usage. For a local business site, most visits are from phones, and most of those phones are not flagships.
If you only test on the machine you develop on, you will ship pages that pass in the lab and fail in Search Console, and you will not understand why.
What "mid-range" means in practice
The device to design for is not the cheapest phone; it is the median one. In most markets that is a two- to three-year-old Android in the range that sold well at a few hundred dollars: Samsung's A-series, Motorola's G-series, Xiaomi's Redmi Note line, or equivalents. Roughly: a mid-tier chipset, four to six gigabytes of memory, and a browser that is up to date because Chrome updates independently of the operating system.
The network is usually fine, 4G or Wi-Fi. The constraint is the CPU. JavaScript that parses and runs in 200 milliseconds on a laptop takes over a second on this phone, and it blocks everything else while it does.
Option 1: a real device
Buy one. A used mid-range Android costs less than an hour of debugging and gives you the truth. Set it up with Chrome, connect it by USB, enable developer mode, and use Chrome's remote debugging (chrome://inspect on the desktop) to run the full DevTools performance panel against the phone. You see real CPU timings, real paint times, real interaction latency.
Keep it charged and on your desk. Load every page on it before you call it done.
Option 2: honest emulation
If you do not have the device, DevTools can approximate it, and most people set it too gently.
- CPU throttling: 4x slowdown at minimum, 6x for a genuinely mid-range target. The default 4x on a fast laptop is still generous.
- Network: "Slow 4G" preset (or the older "Fast 3G"). Real 4G is usually better than this, but the throttle also stands in for latency that emulation otherwise hides.
- Viewport: a real phone size, around 390 by 850 CSS pixels, with a device pixel ratio of 2 or 3, so images are requested at the sizes phones actually request.
- Cache disabled for first-visit testing; enabled for repeat-visit testing. Both matter.
Lighthouse's mobile preset applies its own throttling (a simulated mid-tier phone on slow 4G), which is why its scores are lower than what you see loading the page yourself. That is the point; it is closer to your users than your unthrottled browser.
What changes when you test this way
JavaScript cost becomes visible. Frameworks, tag managers, chat widgets, animation libraries and analytics that seemed free show up as long red blocks on the main thread. Interaction to Next Paint, invisible on a laptop, becomes a real number, often over the 200 millisecond threshold.
Images get the blame they deserve. A hero image sized for desktop and served to a phone at three times the needed resolution is a visible multi-second delay on the throttled network.
Fonts and render-blocking CSS show as blank screen. The two seconds of white that a laptop hides become obvious.
Third parties dominate. On many business sites, more than half the main-thread time on a mid-range phone belongs to scripts the site owner did not write.
A testing routine
For each key page (home, a service page, the contact page, the booking flow), on the device or the honest emulation:
- Cold load, first visit. Note LCP and what the LCP element is.
- Interact: open the menu, tap a button, start typing in the form. Note any lag.
- Scroll the full page. Note any jank or layout shift.
- Repeat load, cached. Should be fast; if not, caching is broken.
- Record a performance profile of the cold load and look at the main-thread flame chart for the longest tasks and who owns them.
Twenty minutes per page. It finds most of what field data will eventually report, weeks earlier.
Reconciling with field data
Search Console's Core Web Vitals report and the CrUX data behind it are the ground truth, aggregated over 28 days from real Chrome users. Your device test should roughly match: if the phone shows LCP around 3 seconds and CrUX says 2.8, you are measuring the right thing. If the phone says 1.5 and CrUX says 3.5, your emulation is too generous or your users are on slower devices or networks than you assumed. Adjust the throttle until they agree, and then trust the local test for iteration.
Why it matters for the business
The visitor on the mid-range phone is the customer. They are searching for a dentist or a plumber from a car park, on the phone they have, and the first site that loads gets the call. Testing on their device is not a performance nicety; it is testing on the actual customer's actual experience.
Every Core Web Vitals engagement we do starts on a mid-range Android, and the before-and-after numbers we report are from that device, because those are the numbers that match what Search Console will say and what customers will feel.