Core Web Vitals are three numbers Google uses to measure how a page feels to a real person: how fast the main content loads, whether the layout jumps around while it does, and how quickly the page reacts when you tap or click. They are part of Google's page experience signals, which means they work as a ranking tie-breaker. Between two pages that answer a query equally well, the faster, steadier one has the edge.
This guide explains each of the three, plus the supporting numbers you will see in the same report, and then shows the real fixes that took this site's mobile score from 77 to 98. Nothing here is theory. It is the same work I run on client sites in an SEO audit.
What a good result looks like
Here is where this site sits today, straight from Google's PageSpeed Insights: 98 on mobile and 100 on desktop, on the same code. The two tests look different because mobile is run on a throttled, slower simulated device, so it always has less room to work with. Mobile is the harder target, and since mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score worth chasing. Google measures mobile and desktop separately, so desktop still counts too.
The three Core Web Vitals, one at a time
Everything on the scoreboard comes down to three real-user metrics. A page passes when 75 percent of real visitors fall inside the "good" band for each.
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading | 2.5s or less | Over 4s |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less | Over 0.25 |
| INP (Interaction to Next Paint) | Responsiveness | 200ms or less | Over 500ms |
LCP: how fast the main thing loads
Largest Contentful Paint is the moment the biggest element in view finishes rendering, usually the hero image or the headline block. It is the reader's gut sense of "has this page loaded yet". What drags it down is nearly always one of four things: a heavy, uncompressed hero image, a slow server or host, render-blocking CSS and JavaScript that must run before anything paints, and web fonts that arrive late.
The fixes follow the causes. Compress and serve the hero as WebP at the right size, and preload it so the browser fetches it early. Use srcset so a phone pulls a small version and a desktop a larger one, instead of shipping one heavy file to every device. That is a separate lever from preloading: preload fetches the image sooner, srcset makes sure it is the right weight, and on a slow mobile connection the srcset part is often what saves the most. Cut or defer render-blocking scripts, and self-host your fonts instead of pulling them from a third-party domain. On this site LCP is 1.9s on mobile and 0.5s on desktop, and the single biggest lever was the hero image: right format, right size per device, preloaded.
CLS: whether the page holds still
Cumulative Layout Shift measures how much the content jumps around as the page loads. You have felt it: you go to tap a link, an image or banner loads above it, and the whole page shoves down. The usual culprits are images and embeds with no width and height set, ad or banner slots injected after load, and fonts that swap and reflow the text.
This is the most fixable vital, and the cheapest win on the list. Put explicit width and height (or an aspect ratio) on every image and iframe so the browser reserves the space before the file arrives. Give injected elements a fixed slot. Set font-display so a font swap does not reshuffle the layout. This site sits at a CLS of 0, and it got there almost entirely by adding size attributes to images.
INP: how fast the page answers you
Interaction to Next Paint replaced First Input Delay in March 2024. It measures the delay between you doing something, a tap, a click, a keypress, and the page actually showing a response, taking close to the worst interaction across the whole visit. A high INP is a page that feels sluggish and unresponsive, and the cause is almost always JavaScript hogging the main thread: heavy frameworks, big third-party scripts, and long tasks that block the browser from reacting. It is also the vital the most sites fail, so it is worth the attention.
The fix is to give the main thread less to do. Defer or split heavy JavaScript, hold third-party scripts off the critical path until the user needs them, and break long tasks into smaller pieces. The clearest example on this site is analytics: the Google tag does not load until the first interaction or the browser goes idle, so it never blocks that first tap. That one change keeps total blocking time, the lab stand-in for INP, at 40 milliseconds.
The other numbers in the report
The same Lighthouse report shows three more metrics. These are lab diagnostics, useful for finding problems, but they are not the vitals Google ranks on.
- First Contentful Paint (FCP). When the first text or image appears. An early signal that something is happening.
- Total Blocking Time (TBT). How long the main thread was blocked during load. It is the lab proxy for INP, so lowering TBT usually lowers INP for real users too.
- Speed Index. How quickly the page visibly fills in. On this site it shows 3.5s on mobile and lands in the amber band, while every actual vital is green. That is a fair reminder that the overall score is a blend, and a single amber lab number is not worth panicking over when the real-user vitals all pass.
Lab data and field data are not the same
There are two ways to measure all of this, and mixing them up causes a lot of confusion. Lab data is a single simulated test, like the Lighthouse run in the screenshots above, on a fixed device and connection. It is repeatable and great for debugging. Field data is what real Chrome users actually experienced over the last 28 days, and it is what Google uses for ranking. You can see your own field data in the Core Web Vitals report inside Search Console.
The practical order: use the lab test to find and fix problems fast, then watch the field data in Search Console to confirm real users feel the change. A lab score can be perfect while the field still lags, especially on a page that only just got fixed, because the field window is a rolling average. Reading that report is part of the wider habit covered in how to read your monthly SEO report.
What actually moved this site from 77 to 98
The jump was not one clever trick. It was a short list of unglamorous fixes, each aimed at a specific metric:
- Self-hosted the fonts. Pulling fonts from a third-party domain adds a connection and a render delay. Serving them from the same domain, preloaded, cut straight into LCP.
- Deferred analytics off the critical path. The Google tag now loads on first interaction or idle instead of during load, which kept total blocking time, and therefore INP, low.
- Responsive images in WebP. Every image ships as WebP at several sizes with srcset, so a phone downloads a small file and a desktop a larger one, never the wrong one.
- Width and height on everything. Explicit dimensions on images and figures reserve their space, which is why CLS is 0.
None of that touched the design or the content. It is exactly the kind of finite, technical work that a small site needs once, not every month, which is the point I make in the technical SEO fixes agencies won't touch.
A quick checklist
- Compress the hero image, serve it as WebP, and preload it.
- Set width and height on every image, iframe, and embed.
- Self-host fonts and set font-display so text does not reflow.
- Defer analytics and other third-party scripts off the load path.
- Test in the lab with PageSpeed Insights, then confirm in Search Console field data.
Core Web Vitals are one part of a technical SEO check, alongside indexing, schema, and titles. If you would rather have someone measure yours, find what is dragging them down, and hand you a prioritized fix list, that is exactly what the fixed-price SEO audit does: one report, a flat $150, no retainer, no ranking promises. If the work turns out to be ongoing, the monthly retainer picks it up from there. Get in touch to start.
Frequently asked questions
What are Core Web Vitals?
Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. They come from real Chrome users and feed into ranking as a page experience signal.
What is a good Core Web Vitals score?
A page passes when 75 percent of real users see LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less. In the Lighthouse lab test the overall score is good from 90 to 100. This site scores 98 on mobile and 100 on desktop.
Why is my mobile score lower than desktop?
Lighthouse tests mobile on a throttled, slower simulated device and connection, so the same page has less CPU and bandwidth to work with. Mobile is the harder target, and because mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score to optimise for. Google measures mobile and desktop separately, so desktop still counts.
Do Core Web Vitals affect SEO rankings?
Yes, as a tie-breaker rather than a magic lever. Between two pages of similar relevance, the faster and steadier one has an edge. Fixing vitals will not outrank a far more relevant page on its own, but poor vitals can hold back a page that otherwise deserves to rank.