On this page
Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how quickly the main content loads, how quickly the page responds when someone taps or clicks, and how much the layout jumps around while loading. Google recommends that site owners achieve good Core Web Vitals, both for success in search and for a better experience generally. The good news is that each measurement points to specific, fixable causes.
This guide explains each measurement in plain terms, what good looks like according to Google, and how to check and improve your own scores. If you would like help with your site's performance and search visibility, our SEO service page explains how we work.
What Core Web Vitals measure
According to Google's Core Web Vitals guide, the three metrics measure real-world user experience for loading performance, interactivity and visual stability. The thresholds below come from Google's Web Vitals overview.
| Metric | What it measures | Good result |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: how soon the main content appears | Within 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness: how soon the page reacts to taps, clicks and key presses | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability: how much content moves unexpectedly | 0.1 or less |
Google also recommends measuring at the 75th percentile of page loads, separately for mobile and desktop. In practice, that means most visits, not just the fastest ones, should meet these targets.
Loading: largest contentful paint
Largest Contentful Paint (LCP) is the time it takes for the largest piece of content in view, often a main image or heading, to appear.
Common causes of a slow LCP
- A slow server response. Everything waits for the server, so slow hosting or heavy code delays the main content.
- A large main image. An oversized hero image takes a long time to download, especially on mobile.
- The main image loading late. Setting the top image to load lazily, or loading it through scripts, can delay it.
- Render-blocking files. Styles and scripts that must load before the page can be shown.
A worked example
A service business's home page shows a large photo at the top. The photo is uploaded at full camera resolution and set to load lazily like the images further down. Resizing it to the size it is shown at, compressing it and letting it load straight away usually improves LCP noticeably, without any change to the design.
Responsiveness: interaction to next paint
Interaction to Next Paint (INP) measures how long the page takes to respond visually after someone interacts with it, such as tapping a button, opening a menu or typing in a form.
Common causes of poor INP
- Heavy JavaScript running on the page, keeping the browser busy when the visitor interacts.
- Third-party scripts, such as chat widgets, advertising tags and trackers, competing for the browser's attention.
- Large, complex pages that take a long time to update after each interaction.
- Expensive work on every tap, such as filters that recalculate a long product list instantly.
Steps to improve it
- List every script on the page and remove those you no longer need.
- Delay non-essential scripts until after the page has loaded.
- Load heavy tools, such as chat, only on pages where they are used.
- Ask your developer to break long tasks into smaller pieces so the page can respond in between.
Stability: cumulative layout shift
Cumulative Layout Shift (CLS) measures how much visible content moves unexpectedly while the page loads. Everyone has experienced it: you go to tap a link, and the page jumps so you tap an advert instead.
Common causes and fixes
- Images without set dimensions. The browser does not know how much space to leave, so text moves when the image arrives. Fix: give images a width and height.
- Adverts, embeds and banners inserted above content. Fix: reserve space for them in advance.
- Web fonts swapping in late and changing the size of text. Fix: use font loading settings that reduce the change, and limit the number of fonts.
- Content added above existing content, such as cookie banners or notices. Fix: place them in space that does not push content down, or reserve room for them.
Checking and improving your scores
- Test key pages with PageSpeed Insights. It shows field data from real visitors where available, alongside a lab test and suggestions.
- Check Google Search Console. Its Core Web Vitals report groups pages with similar problems across your site.
- Start with templates, not individual pages. If all product pages share a template, fixing the template improves them all.
- Fix the metric that fails most widely first, then the next.
- Test changes on a staging site before going live, and measure before and after.
- Be patient with field data. Real-visitor data is collected over time, so improvements appear gradually.
Questions to ask your developer
- Which of our page templates fail each metric, on mobile and desktop?
- What is the largest element on our key pages, and how quickly does it load?
- Which scripts run on every page, and which could be removed or delayed?
- Do our images and embeds have reserved space?
Our guides on why your website is slow, how to speed up a slow WooCommerce store and what website maintenance includes cover the wider causes of slow pages and how to keep them fast.
Summary
- Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS) for real visitors.
- Google's good thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, at the 75th percentile.
- Slow LCP usually comes from slow servers and large or late main images.
- Poor INP usually comes from heavy or third-party scripts; poor CLS from missing dimensions and inserted content.
- Measure with PageSpeed Insights and Search Console, fix templates first and test changes before going live.
Good Core Web Vitals mean a faster, calmer experience for every visitor. If you'd like your site's Core Web Vitals reviewed, you can tell us about it here.