Your site is fast. Your customers' phones disagree.

Almost every speed diagnosis starts the same way: you open the site on the office laptop, on fibre, on a large screen, and it flies. The Lighthouse report comes back green. Then analytics says people leave before they read anything.

There is no contradiction. Two different measurements are describing two different things.

Lab data and field data are not the same number

Lighthouse is a controlled test: a simulated device, a simulated network, a page with no third-party cookies. It is useful for reproducing problems and comparing versions, and it is the tool we reach for when we change code. It is not what your customer sees.

The Core Web Vitals Google actually uses come from the Chrome User Experience Report: real data from Chrome users who agreed to share telemetry. Mid-range phones on patchy mobile networks, browser extensions, cookie banners: all of it counts. It is also the data behind the Core Web Vitals report in Search Console.

The practical rule is simple: when lab data and field data disagree, field data wins. It is what your customers experience and what Google measures.

The 75th percentile is the one that counts

Three thresholds are worth keeping at hand:

• LCP (Largest Contentful Paint), the page’s main element: under 2.5 s.
• INP (Interaction to Next Paint), the response to the user’s first interaction: under 200 ms. It replaced First Input Delay in March 2024 and is stricter, because it measures the whole interaction rather than only the input delay.
• CLS (Cumulative Layout Shift), the page moving while it loads: under 0.1.

The threshold is not the interesting part; the aggregation is. Google evaluates those numbers at the 75th percentile, the value below which 75% of visits fall. A 2 s average with the slowest quarter sitting at 4.5 s is still a fail, and that quarter tends to be the people buying on their phones.

What actually moves the needle

In order of real-world impact, after enough projects to see the pattern:

1. Images. They are almost always the LCP element. Modern formats, correct dimensions, a srcset with honest widths, and the hero image loading before the ones below the fold. A 2 MB hero served to a 400 px phone is the most common problem we find and the cheapest to fix.
2. Third parties. A chat widget, a pixel, two tags and a tag manager can cost more than the whole application. If nobody can say what a script does, remove it or load it after interaction.
3. Whatever runs before first paint. Translation: blocking fonts, a huge stylesheet, a full framework for a static page. Every millisecond of JavaScript on the main thread is a millisecond that is not answering a tap.

None of this is exotic. The difference is measuring with field data, accepting that the 75th percentile does not forgive, and treating performance as part of the design rather than a last-minute review before launch.