Your site is fast for you and slow for everyone else
You test on a fast laptop, a good connection, and a warm cache. Your customers do not. Here is how to find out what they actually experience — and what is usually worth fixing first.
Your site loads instantly. You know this because you have loaded it several hundred times, on a laptop with a fast processor, over office broadband, with every asset already cached by your browser.
None of that describes the person deciding whether to fill in your contact form. They are on a mid-range phone, on mobile data, on a train, seeing your site for the first time. That first load is the only one that matters, and it is the one you almost never test.
Lab data and field data are different things
Most performance conversations start with a score out of 100 from a testing tool. That number is lab data: one simulated load, on a simulated device, from a simulated location. It is useful for debugging, because it is repeatable and it points at causes.
It is not evidence about your users. For that you want field data — measurements from actual visits, on actual devices. Google collects this for real Chrome traffic and reports it in Search Console and PageSpeed Insights, and it is what actually feeds the ranking signal. If the two disagree, believe the field data. It is the one describing reality.
Two habits that make field data much more useful:
- Read the 75th percentile, not the average. Averages hide the tail, and the tail is where you lose people. A quarter of your visitors having a bad time is a serious problem that a healthy-looking average will conceal entirely.
- Segment by device. Desktop and mobile are effectively different websites with different problems. A site can be comfortably fast on one and failing on the other, and the combined figure will tell you neither.
What the three metrics actually mean
Core Web Vitals get discussed as an SEO checklist. They are more useful read as three plain questions about the experience.
Largest Contentful Paint — "when did the page look loaded?" The moment the biggest visible thing finishes rendering. Usually your hero image or headline. This is the closest proxy for "did the site feel fast," and it is the one most worth attention.
Interaction to Next Paint — "did it respond when I touched it?" Measures the delay between a tap and something visibly happening. This is where heavy JavaScript shows up. A page that painted in a second but ignores taps for another two feels broken, not slow — and users treat it far less forgivingly.
Cumulative Layout Shift — "did it move under my thumb?" Content jumping as late assets arrive. The classic symptom is tapping a link and hitting an ad that loaded into the space a moment earlier. It is usually the easiest of the three to fix and the most immediately infuriating to experience.
What usually turns out to be the problem
Across most sites, the same small set of causes accounts for the bulk of the damage.
Images, nearly always. Full-resolution photographs served to phones, in formats a decade old, with no dimensions declared so the layout shifts when they arrive. Fixing images alone resolves a surprising share of all three metrics: modern formats, correctly sized variants per breakpoint, explicit width and height, lazy loading for anything below the fold — and not lazy loading the hero, which is a common own goal.
Fonts. A custom font that blocks rendering means a blank screen while it downloads. Preload the one face you need above the fold, set a sensible display strategy so text appears immediately in a fallback, and be honest about how many weights you actually use. Most sites ship several they never render.
Third-party scripts. Analytics, chat widgets, heat maps, consent banners, ad pixels, the tag manager that loads all of them. Each was added for a good reason and none was ever removed. They are frequently the single largest cost on the page, and they run on your users' devices at your users' expense.
Audit them. For each one, ask who looks at the data it produces and when they last did. Load what survives asynchronously, after the page is interactive.
Shipping the whole application to render one page. If a visitor has to download and execute the code for your entire site to read one article, the code is the bottleneck. Send HTML for content and JavaScript only for the parts that genuinely need it.
The order that works
Performance work has sharply diminishing returns, so the order matters more than the effort.
- Measure the field data first. Find out which metric is actually failing and on which device class. Optimising the one that was already fine is the most common way to spend a fortnight and move nothing.
- Fix the images. It is the highest ratio of improvement to effort on almost every site, every time.
- Cut the third-party scripts. Usually the second largest win, and it costs engineering time only in the sense that somebody has to be willing to have the conversation.
- Then look at your own code. By this point the remaining problems are genuinely yours, and you can see them clearly rather than through the noise.
The honest expectation
Speed is a ranking factor, but a modest one. A fast page that does not answer the query will not outrank a slow page that does, and no amount of optimisation substitutes for having something worth reading.
What speed reliably does is stop you losing the visitors you have already paid to attract. Someone who leaves before your page renders costs you the full acquisition price and returns nothing, and they never appear in your conversion-rate analysis as anything but absence. That is the case for the work — not the score, and not the ranking.
