Table of Contents
ToggleTL;DR (Too Long; Didn’t Read) 👇
- Core Web Vitals measure the real experience of your visitors. They cover how fast your page loads (LCP), how quickly it responds (INP) and how steady it stays (CLS). All of it comes from real Chrome user data.
- INP replaced FID in March 2024. It measures how quickly your site responds to every click, tap and keypress, not just the first, so it's a tougher test.
- To pass, all three metrics need to be "good" for at least 75% of visits. That's LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Start with mobile and your "Poor" pages.
- Good scores help your rankings and conversions. Helpful content still comes first, but a fast, stable site keeps visitors around and turns more of them into customers.
About Google's Core Web Vitals Report
Google’s Core Web Vitals report sits within Google Search Console and shows how your website performs on key user experience factors. It uses real-world data from Chrome users to show how your pages perform for actual visitors, focusing on three areas: loading, interactivity and visual stability.
Pages are assessed at the 75th percentile, which means at least 75% of real visits need to hit the “good” mark. Search Console groups similar URLs together, so fixing one template can often fix hundreds of pages at once.
Why are Core Web Vitals important?
For SEO
The metrics in the Core Web Vitals reports are for things that Google considers essential in evaluating your website’s overall user experience. And, of course, anything that Google deems important for website performance is important to pay attention to — if you want to be shown when people search for what you offer on Google.
Google favours websites with a good user experience. The Core Web Vitals Report section in Google Search Console tells you how you’re doing for user experience. Strong Core Web Vitals won’t outrank better content on their own. Relevant, helpful content still comes first, both in Google and in AI search tools.
For business
The Core Web Vitals report is designed to give you actionable information that can help you to enhance your site’s usability, which improves the experience of people visiting your website. It also increases your visitor engagement on the site (or, rather, prevents this from dropping due to poor UX).
Paying attention to the results in your Core Web Vitals report is good for business in general, as it tells you about the experience of your website visitors and how to improve it. A frustrating website experience can make people abandon your website and move on to faster-loading pastures.
Overall, optimising your performance on metrics reported in the Core Web Vitals reports within Google Search Console can:
- Ensure smoother website operation.
- Give your website users a better experience.
- Better engage your website users.
- Reduce people ‘bouncing’ off your site in a blind rage of frustration.
- Improve your SEO results by giving good ‘signals’ to Google for UX (User Experience).
- Ultimately, this can lead to more conversions for your website and a bigger presence online.
Times have changed: INP has replaced FID
In March 2024, Google officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the Core Web Vitals measure of responsiveness. FID was then removed from Search Console reporting later that year. To understand why, it helps to look at what FID measured and where it fell short.
What was First Input Delay (FID)?
We’re so glad you asked, friend. First Input Delay was a measurement of the delay between the user’s first interaction on a website and the time it took for the browser to start handling it. For website users, it measured how long they waited after they first clicked a button or link, pressed play on a video or tapped on a dropdown menu before the browser could start processing it. The shorter the delay was, the more ‘responsive’ the website seemed.
Why does responsiveness matter?
Quite simply, if a website takes too long to respond after you “tell it to do the thing”, it’s a terrible experience, and you’re more likely to leave.
Think of a website like an elevator. You press the button, but nothing happens: the doors don’t open, and the button doesn’t light up. You start to wonder if you pressed it properly or if the elevator is out of order. You might wait, or you might take the stairs. Either way, it’s not a great experience.
Now imagine that elevator is the main entry point into a store. For many businesses, that’s exactly what their website is. People are impatient online, and if a site doesn’t respond quickly, they’ll assume it’s broken or just leave. On an ecommerce site, they may even think twice about handing over their credit card details. It comes across as budget, broken or unprofessional.
What is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) is similar to First Input Delay (FID) but is much more comprehensive.
Interaction to Next Paint is a performance metric on the responsiveness of a webpage to user interactions. It measures the time it takes from when a user interacts with the webpage (like a link click or button click) to when a visible response happens on the webpage. It’s the time it takes for something to visibly happen as a result. INP watches every click, tap and keypress (not scrolling or hovering) and reports close to the slowest one, not the average.
In our elevator example, think of it as the time before the light on the elevator button appears, but not necessarily when the elevator actually arrives.
A good INP score means that the webpage quickly responds to something the user does, and is very similar to FID in this way.
So what's the difference between the two? And why did INP replace FID?
FID focused on the delay between the user’s first interaction and the time it took for the website to respond, but it didn’t measure the delay between that interaction and when visual feedback appeared on the screen. INP measured when there was a visual reaction on the webpage.
A good INP score indicates a quicker visual response after a user interaction, which generally means a better user experience.
Another key difference was that First Input Delay only measured the delay from the first interaction on a webpage. Interaction to Next Paint measured the delay in a visual reaction to any interaction.
So, in short, Interaction to Next Paint gave a more complete picture of website responsiveness and the user experience.
How are your Core Web Vitals looking?
INP has had most of the attention so far, but it’s only one of three metrics in your Core Web Vitals report. To pass, a page needs to hit the “good” mark for all three. If your website is the elevator, here’s what each Core Web Vital measures:
Interaction to Next Paint (INP): how quickly the button lights up
As covered above, INP measures how quickly your site visibly responds when someone clicks, taps or types. Google wants this within 200 milliseconds. INP is a tougher measure than FID was, so a site can feel reasonably quick at first glance and still have room for improvement. Heavy JavaScript, long-running tasks, third-party scripts such as chat widgets and tag managers, and complex interactive features are the usual culprits.
Largest Contentful Paint (LCP): how quickly the doors open
LCP measures how long it takes for the main content on a page to appear, usually a hero image, banner or large block of text. Google wants this within 2.5 seconds. Slow LCP is usually caused by large, unoptimised images, slow server response times, or render-blocking CSS and JavaScript that holds up the page.
Cumulative Layout Shift (CLS): whether the floor stays still
CLS measures how much the page jumps around, either while it loads or as you use it. You’ve probably experienced it, you go to tap a button, an ad or image loads above it, and you end up tapping something else entirely.
It’s like the elevator buttons rearranging just as you go to press one. Google wants a CLS score of 0.1 or less. Common causes include images and embeds without set dimensions, late-loading ads or banners, and web fonts that swap in and resize text.
Here’s how to keep on top of all three:
- Check your Core Web Vitals report. In Search Console, review the mobile and desktop results and prioritise URL groups marked "Poor" or "Needs improvement". The report shows which metric is causing the issue, so you know where to focus.
- Start with mobile. Mobile results are often weaker than desktop, and mobile is how most people will find you on Google.
- Track your fixes. After making improvements, use Search Console's tracking option to monitor the affected URL group. The report uses real-user data collected over a rolling 28-day period, so changes won't appear straight away.
- Keep an eye on single-page apps. Sites built with frameworks such as React or Next.js can rely heavily on soft navigations, where content changes without a full page reload. Chrome is continuing to improve how these experiences are measured, so they're worth monitoring closely.
How do you optimise your Core Web Vitals?
Firstly, you’ll want to know where you stand against the benchmarks in the table below.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading | ≤ 2.5s | 2.5–4s | > 4s |
| Interaction to Next Paint (INP) | Interactivity | ≤ 200ms | 200–500ms | > 500ms |
| Cumulative Layout Shift (CLS) | Visual stability | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Then, in simple terms, optimising your Core Web Vitals comes down to three things:
- Get your main content on screen fast (LCP). Reduce delays in loading scripts and fetching resources, keep images lean and make sure your server responds quickly.
- Make every interaction feel instant (INP). Your site should respond quickly to every click, tap and keypress, not just the first. For more complex interactions that take longer, show quick visual feedback so people know something is happening.
- Keep the page steady (CLS). Reserve space for images, ads and embeds so content doesn't jump around.
It also signals that Google is as serious as ever about the importance of user experience, and you should be too if you want to get the best results you can in Google’s search engine, which is still by far the most widely used search engine globally.
If you’ve got a website with slow performance, now is a good time to get that website upgrade underway (chat to the good folks here at Excite Media about that).
Core Web Vitals improvements in more technical terms
For those more technically-minded, here are some of the key optimisations for each Core Web Vital. (If this looks like an unknown language to you, don’t worry — our technical team have you covered. If you’re a client with us, we’ve got you covered. If you’re not already a client with us, you can be. Wink.)
Improving Largest Contentful Paint (LCP)
Improving server response times:
- Use server-side rendering or prerendering to display content on screen faster.
- Use a Content Delivery Network (CDN) to serve content from servers closer to your visitors.
- Optimise your server's performance by upgrading server hardware or improving database queries.
Optimising images and assets:
- Compress images and serve modern formats like WebP or AVIF.
- Preload your main hero image (or add fetchpriority="high" to it, which is now Google's first recommendation for the LCP image), and don't lazy-load images that appear at the top of the page.
- Minimise render-blocking CSS and JavaScript so the browser can display content sooner.
Improving Interaction to Next Paint (INP)
Minimising JavaScript execution time:
- Use code splitting to only load the JavaScript needed for the current page.
- Defer or asynchronously load JavaScript to prevent it from blocking the main thread.
- Break up long tasks and yield to the main thread (e.g. with scheduler.yield(), with a setTimeout fallback for browsers that don't support it yet, such as Safari) so the browser can respond to input.
- Minimise unused JavaScript, and audit your third-party scripts, removing any that aren't essential.
Optimising browser rendering:
- Use CSS containment to limit the areas the browser needs to lay out or paint.
- Keep your DOM size in check, and avoid large, complex layouts and layout thrashing (forced synchronous layout: JavaScript alternately reading and writing layout properties, so the browser recalculates over and over).
Implementing user interaction feedback:
- For complex interactions that may take time, give a visual indication that the user's action is being processed, such as loading spinners and visual cues.
Improving Cumulative Layout Shift (CLS)
Reserving space for content:
- Set width and height attributes (or CSS aspect ratios) on images and videos.
- Reserve space for ads, embeds and banners so they don't push content down when they load.
- Avoid inserting new content above existing content, unless it's in response to a user action.
Handling fonts and animations:
- Preload key web fonts and use font-display: optional, or size-matched fallback fonts (size-adjust)settings that minimise text resizing when fonts load.
- Animate with CSS transforms instead of properties that change layout, like top, left, width or height.
Core Web Vitals FAQs
Are Core Web Vitals a ranking factor?
Yes, Core Web Vitals are used by Google’s ranking systems. But they’re not a silver bullet, and good scores don’t guarantee top rankings. A slower page can still outrank a faster one if its content is more relevant. Think of Core Web Vitals as a tiebreaker: they help you stand out when competing pages are otherwise similar.
Why don’t my PageSpeed Insights scores match Search Console?
They measure different things. Tools like Lighthouse (the score shown in PageSpeed Insights) run a one-off “lab” test on a simulated device. A standard Lighthouse test can’t measure INP because nobody is clicking anything, so it uses Total Blocking Time as a stand-in. Search Console uses “field” data from real Chrome users over the past 28 days.
PageSpeed Insights shows field data too, in the ‘Discover what your real users are experiencing’ section at the top, and that’s what counts. Lab tests are handy for diagnosing problems, but the field data is what Google uses to assess your Core Web Vitals.
Why does my report say there’s “not enough usage data”?
Google needs a certain amount of real Chrome traffic before it can report on a page or URL group. Smaller or newer sites often won’t have enough yet. In the meantime, PageSpeed Insights and Lighthouse can still give you a useful indication.
Why did my “good” URLs suddenly drop?
Don’t panic. The report is based on sampled real-user data, so URL counts can shift from month to month even when nothing on your site has changed. If a drop persists or lines up with a site change, it’s worth investigating.
Need a hand with your Core Web Vitals?
Core Web Vitals can get technical fast, but the goal is simple: a website that loads quickly, responds instantly and doesn’t jump around. Get those right, and you’ll give both your visitors and Google a better experience.
Already an Excite Media SEO client? You don’t need to worry. Our technical and SEO teams keep an eye on your Core Web Vitals and handle these changes for you.
Not a client yet? Get in touch to chat about our SEO or website services.