Core Web Vitals are three measurements Google uses to judge how a page feels to use. They have a reputation for being mysterious, mostly because the tools that report them produce a different number every time you press refresh. The underlying ideas are simple.
The three metrics
LCP — how long until the main thing appears
Largest Contentful Paint measures when the biggest element in the viewport — usually a hero image or headline — finishes rendering. It is a proxy for “has the page loaded yet?” from the visitor’s point of view. Google considers 2.5 seconds or less to be good.
The usual culprits are an oversized hero image, a slow server response, or fonts and scripts that block rendering until they finish.
INP — how quickly the page responds to you
Interaction to Next Paint measures the delay between a tap or click and the page visibly reacting. It replaced the older FID metric because FID only measured the first interaction, which flattered pages that got slow later. Google considers 200 milliseconds or less to be good.
High INP almost always means too much JavaScript running on the main thread: heavy third-party tags, chat widgets, analytics stacked on analytics.
CLS — how much the page jumps around
Cumulative Layout Shift measures unexpected movement while the page loads — the classic case being a button that slides down just as you tap it, because an ad or image above it finally arrived. Google considers 0.1 or less to be good.
The fix is nearly always the same: give images, ads and embeds explicit dimensions so the browser reserves the space before the content arrives.
Lab data versus field data
PageSpeed Insights shows two things: a lab test run on a simulated device, and field data from real Chrome users over the previous 28 days. Only the field data affects search. That is why your score can swing wildly between refreshes while your actual ranking signal barely moves.
Why your score keeps changing
Lab scores depend on the simulated network, the device profile and how busy the server happens to be at that moment. Running the same test three times can produce three different numbers, and chasing those numbers is a good way to waste an afternoon.
Measure on a consistent real device, take the field data seriously, and judge changes by whether the same test on the same device improves before and after.
The fixes that actually matter
Images
Almost every slow site we audit is slow partly because of images: uploaded at full camera resolution, served at the same size to a phone, in a format from the 1990s. Resize them, compress them, serve modern formats, and lazy-load anything below the fold. This is usually the single biggest win, and nobody can see the difference.
Third-party scripts
Chat widgets, heatmaps, A/B testing tools, tag managers, pixels. Each one is someone else’s JavaScript running on your page. Measure what each costs, defer the ones that are not needed immediately, and remove the ones nobody has opened in six months.
Fonts
Loading six weights of two font families delays text rendering. Load the two or three weights you actually use, self-host or preconnect, and set a sensible display strategy so text appears rather than waiting invisibly.
The server
If the first byte takes a second to arrive, no front-end work will save you. Caching, tuned database queries and hosting that suits your traffic fix a problem that is invisible in most front-end audits.
How to measure properly
Use three sources together and you will get a picture you can trust:
- Search Console. The Core Web Vitals report shows field data grouped by URL pattern — the closest thing to what Google actually uses.
- PageSpeed Insights. Useful for the specific diagnostics: which image, which script, which font.
- A real device. Load the page on a mid-range phone on mobile data. It takes thirty seconds and tells you more than any score.
Pick one device and one connection, and use the same combination for every before-and-after comparison. Consistency matters far more than which tool you choose.
A sensible order of work
Most sites get the bulk of their improvement from the first two steps here, so start at the top and stop when the numbers are good enough:
- Fix the images: correct dimensions, compression, modern formats, lazy loading
- Audit third-party scripts and remove or defer what is not essential
- Reserve space for anything that loads late, to stop layout shift
- Trim fonts to the weights you actually use
- Add or fix caching, then check server response time
- Only then consider a theme or platform change
What not to bother with
Chasing a perfect 100 in a lab test is not a business goal. Neither is micro-optimising a page nobody visits. And a “speed optimisation plugin” installed on top of the problem is rarely a fix — it usually adds another layer of caching over the heavy assets that were the real issue.
The useful question is simpler: on a normal phone, on a normal connection, does this page appear quickly and respond immediately when tapped? Everything worth doing follows from answering that honestly.
Does speed improve rankings?
Speed is one signal among many, and a fast page does not outrank a better page. What speed reliably improves is how many visitors stay long enough to read, enquire or buy — which for most businesses is worth more than the ranking change would have been.
Treat Core Web Vitals as a proxy for “does this page feel solid on a normal phone”, not as a score to be gamed. The work you do for the first answer usually fixes the second anyway.
