Website speed and Core Web Vitals: what to fix first for real gains

Almost every team has opened a page speed report glowing red and wondered where to start. This article re-sorts the work by real impact: which metrics Google actually measures, what counts as passing, and what deserves to be fixed first.

Which metrics make up Core Web Vitals?

Core Web Vitals is the set of three metrics Google uses to describe page experience from the user's point of view. LCP (Largest Contentful Paint) measures how long the largest content block in the viewport takes to render, usually a hero image or a heading block, and answers the question "does the page look loaded yet". INP (Interaction to Next Paint) measures the response delay when a user clicks, taps or types, counted through to the moment the screen repaints. INP officially replaced FID in March 2024 and is stricter, because it measures the full interaction life cycle rather than only the first interaction. CLS (Cumulative Layout Shift) measures unexpected layout shift, the effect where content jumps while a user is reading or about to click.

The "good" thresholds Google publishes are: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. The "poor" band starts at LCP above 4 seconds, INP above 500 milliseconds and CLS above 0.25. Everything in between is labelled needs improvement. The detail teams most often miss is how the grading works: a page only passes when the 75th percentile of real visits sits inside the good band, which means the slowest 25 percent of your users still drag the result down.

Data source: the thresholds Google publishes for the Core Web Vitals metric set.

How does lab data differ from real user data?

This is where most teams lose time. Lab data comes from a single simulated run on an assumed device and network profile, for example a Lighthouse report inside Chrome DevTools. It is repeatable and convenient for diagnosis, because it points at exactly which resources block rendering. Real user data, also called field data, is collected from the browsers of actual visitors, for example the Chrome user experience report, aggregated over a 28 day window. It reflects every kind of device and connection: a slow mobile network in a provincial town, a low end Android handset, ad blockers, browser extensions.

The practical consequence: a Lighthouse score of 100 does not guarantee a good real experience, and conversely a page with a mediocre lab score can still pass Core Web Vitals if most of its visitors arrive on fast devices and fast connections. Lighthouse also cannot fully measure INP the way real users interact. The short rule: use field data to decide whether there is a problem, use lab data to find the cause.

Aspect	Lab data	Real user field data
Source	Lighthouse, DevTools	Chrome user experience report
How it is produced	One simulated run, fixed profile	Measured from real visits, aggregated over 28 days
Measures INP	Not fully	Yes
Best used for	Diagnosing causes	Deciding pass or fail
Time to reflect a change	Immediate	Slow, needs enough new data

Because field data updates on a 28 day window, expect to wait a few weeks after optimisation before the numbers move. Do not draw conclusions after a single day.

Why fix what is blocking access before optimising speed?

Speed only has value once a page is indexed and users can reach the content. If a page is blocked in robots.txt, still carries a noindex tag left over from a staging build, or has a canonical pointing at a different page, that page does not appear at all, and every second shaved off LCP is wasted. Likewise, a redirect chain three or four hops long adds a few hundred milliseconds and dilutes link signals, while internal links that lead to 404 pages push users out of the funnel the moment they click.

The sensible order is therefore: clear up indexability, fix 404 pages and redirect chains, check the sitemap, and only then touch Core Web Vitals. This group of tasks usually costs hours rather than days, and the impact is far clearer than trimming LCP from 2.8 seconds to 2.4 seconds. You can run a quick self check with the free SEO and GEO audit tool from Chạm AI before opening any performance dashboard.

Common causes and how to fix them in priority order

Most slow websites are not slow for mysterious reasons. Five groups of causes repeat over and over. Working through them in the order below usually recovers most of the performance without rebuilding the interface.

1. Heavy images with no declared dimensions. The number one culprit behind both LCP and CLS. The fix: compress and move to modern formats, export images at the size they are actually displayed instead of loading a 4000 pixel file into an 800 pixel frame, always declare width and height so the browser reserves the space, lazy load anything below the fold and preload the hero image.
2. Render blocking fonts. The browser waits for the font file before painting text, so headings appear late and LCP suffers, or it paints with a fallback and then swaps, so text jumps and CLS suffers. The fix: limit the number of font variants, declare a swap display strategy, preload the font file used for headings.
3. Third party JavaScript. Tracking tags, chat widgets, A and B testing, advertising pixels all pile onto the main thread and push INP up. The fix: inventory every script currently installed, delete the ones whose reports nobody reads, defer the rest, and load heavy widgets only when the user scrolls to them.
4. No caching. Static assets without cache headers force returning visitors to download everything again. The fix: set long lifetimes for versioned static files, and enable caching at the server or content delivery network layer.
5. Ads or banners injected into the layout. Notification bars, ad slots and cookie popups that add height after the page has painted push content down exactly when the user is about to click. The fix: reserve a fixed height container for anything that loads late, or let those elements overlay instead.

How much does speed affect rankings?

It is worth saying plainly, to avoid the wrong expectations: speed is one ranking factor among many, not the deciding one. Google describes page experience as a supporting signal, one that carries weight when competing pages are otherwise equally relevant to the search intent. In practice a slow page that answers the question well still tends to outrank a fast page with shallow content. Speed optimisation cannot rescue weak content.

The real damage from a slow page shows up elsewhere: bounce rate and conversion rate. If users close the tab before the content appears, no ranking is good enough to become an order. The industry circulates various figures along the lines of one second of delay costing a fixed share of revenue, but those numbers are widely quoted without the measurement conditions attached, so it is more honest to state it qualitatively: the slower the page, the higher the abandonment rate, and the size of the loss depends on your own industry and order value. The right way to verify it is to compare your own site data before and after optimisation.

It is also worth separating the scope. This is classic technical SEO, serving crawlers and the browsing experience. Optimising to be cited by AI tools is a different problem with its own criteria and measurement, covered in what GEO is and how to get cited by AI. Do not merge the metrics of both efforts into one report.

FAQ - Frequently asked questions