Core Web Vitals Explained: How to Improve Website Speed

Core Web Vitals are three metrics Google uses to judge how quickly a page loads, how fast it responds to input and how stable it stays while loading. Good scores are an LCP of up to 2.5 seconds, an INP of up to 200 milliseconds and a CLS of up to 0.1. Below you’ll find what the abbreviations mean, how to check your own scores and which fixes really improve website speed.

What are Core Web Vitals?

Google introduced Core Web Vitals as a shared yardstick for user experience on the web (web.dev: Web Vitals). Each metric matches a question your visitors ask without thinking about it: is the content coming? Does the page react when I tap? Will things stay where they are?

The three Core Web Vitals

• LCPLargest Contentful Paint: when has the largest element in view finished loading – usually an image or a headline?good: up to 2.5 s
• INPInteraction to Next Paint: how quickly does the page respond after someone clicks, taps or presses a key?good: up to 200 ms
• CLSCumulative Layout Shift: how much does visible content jump around unexpectedly while the page loads?good: up to 0.1

Between “good” and “poor”, each metric has a band Google calls “needs improvement”:

Metric	Good	Needs improvement	Poor
LCP	up to 2.5 s	up to 4 s	over 4 s
INP	up to 200 ms	up to 500 ms	over 500 ms
CLS	up to 0.1	up to 0.25	over 0.25

LCP: when does the main content appear?

LCP measures the time from the moment someone opens a page until the largest image or block of text in the viewport has rendered (web.dev: LCP). On many sites that’s the hero image or the main headline. It’s a close match for the feeling that “the page is there”.

INP: how responsive is the page?

INP watches every click, tap and key press during a visit and reports how long the slowest of them took before anything changed on screen (web.dev: INP). Scrolling and hovering don’t count. In March 2024, INP replaced the older FID metric, which only looked at the first interaction.

CLS: does everything stay put?

CLS captures unexpected movement: you go to tap a link and a banner slides in just as your finger lands. Shifts that happen right after user input, such as a menu opening on click, are excluded (web.dev: CLS). CLS is a score without a unit. Lower means calmer.

The 75th percentile: what “passing” means

Google doesn’t look at the average but at the 75th percentile. In other words, three out of four page visits need to hit the good threshold. Mobile and desktop are assessed separately. Plenty of sites pass on desktop and fail on mobile, where slower processors and patchier connections add up.

Field data vs lab data: two ways to measure

The first time people open PageSpeed Insights, they’re often puzzled by two different sets of results on the same page. That’s by design.

Field data comes from the Chrome User Experience Report (CrUX): anonymised measurements from real Chrome users over the past 28 days. This is the only data that feeds into Google’s assessment. It only shows up once a page has enough traffic, though.

Lab data comes from Lighthouse. It loads the page once under fixed conditions, for example a simulated mid-range phone on a throttled connection. That’s ideal for testing and comparing changes, but it isn’t your real audience. Lighthouse can’t measure INP at all, because nobody clicks anything. It reports Total Blocking Time as a stand-in.

The 0–100 score at the top of a Lighthouse report isn’t a Core Web Vitals result, by the way. A page can score 95 and still fail in the field, or the other way round.

PageSpeed and other tools for checking your scores

Three free tools cover most of what you need:

• PageSpeed Insights: enter a URL to see field data for that page and for your whole domain, followed by a Lighthouse audit with specific suggestions. Switch between the mobile and desktop tabs.
• Search Console’s Core Web Vitals report: shows which groups of similar pages across your site are good, need improvement or are poor. This is where patterns emerge, such as every blog post having a CLS problem.
• Chrome DevTools: the Performance panel shows LCP, CLS and INP live as you click through the page yourself. Use it to find out which element is your LCP and which interaction is slow.

A note on patience: because field data covers 28 days, improvements take a few weeks to show up there.

Where to start

Start with mobile and with whichever metric is worst. Think in templates rather than individual pages: if all your service pages share a layout, one fix to that template solves the problem everywhere at once. Lighthouse’s suggestions are a useful starting point, but they don’t all matter equally for your site. Shrinking one oversized hero image often does more than ten small tweaks.

How to improve website speed: LCP

A poor LCP almost always comes down to a handful of causes, and the most common one is the hero image.

• Compress images and use modern formats: WebP or AVIF files are usually much smaller than JPEG or PNG at the same quality. With srcset, each device gets a suitable size instead of a huge desktop image.
• Don’t delay the LCP image: loading="lazy" belongs on images further down the page, never on the hero. fetchpriority="high" tells the browser this image comes first.
• Cut render-blocking CSS and JavaScript: everything that has to load before the first image pushes LCP back.
• Keep fonts lean: load only the weights you actually use, ideally from your own server.
• Hosting, caching and a CDN: if the server takes ages to send its first byte, no amount of image optimisation will save you. Good caching serves ready-made pages instead of building them on every request, and a CDN moves files closer to visitors in other countries.

Improving INP: less JavaScript, faster responses

A poor INP means the browser is busy with something else when someone taps. Usually that something is JavaScript.

• Audit third-party scripts: chat widgets, tracking, ad networks and embedded videos often bring a lot of code with them. Ask whether each one is still needed, and load the rest only when it’s required.
• Ship less JavaScript: large frameworks and plugins that load on every page, even if only one page uses them, eat into responsiveness.
• Break up long tasks: heavy code should run in small chunks so the browser can respond to input in between.
• Give instant feedback: a button can react visibly first and do the actual work afterwards.
• Don’t overload pages: a very large number of elements on a page makes every update slower.

Improving CLS: nothing should jump

Layout shifts are usually quick to fix once you know the cause.

• Set dimensions on images and videos: with width and height or aspect-ratio, the browser reserves the space before the image arrives.
• Reserve space for ads and embeds: ads, maps and social media embeds get a container with a fixed minimum height.
• Cookie banners as overlays: a banner that pushes the page down from the top causes shifts. One that sits on top of the content doesn’t.
• Match your fonts: if the web font is much wider than the fallback, text jumps when it swaps in. A well-matched fallback or size-adjust softens this.
• Animate with transform: movement via transform doesn’t push other elements around. Changing height or margins does.

How much do Core Web Vitals matter for SEO?

Google describes Core Web Vitals as part of page experience, which its ranking systems take into account (Google Search Central: Page experience). The same page also makes clear that Google will still show the most relevant content even if its page experience is sub-par. Good content beats good load times.

The work still pays off, mostly because of people rather than algorithms. Someone staring at a blank phone screen, or tapping the wrong button because the layout jumped, is less likely to come back and less likely to get in touch. You feel that directly, whatever Google does. It’s especially noticeable in local SEO, where so many searches happen on the go.

Ambitious design doesn’t have to be slow either. Our article on 3D websites with WebGL shows how a site with a 3D scene stays fast: content first, effects second. And if you’re planning a redesign, measure before and after. We’ve covered how to handle a website relaunch without losing SEO separately.

Your checklist

1. Run PageSpeed Insights on your homepage and key pages, mobile first
2. Look for patterns in Search Console’s Core Web Vitals report
3. Find your LCP element and optimise the hero image: modern format, right size, no lazy loading
4. Trim fonts to the weights you need
5. List every third-party script and remove what you don’t need
6. Set dimensions on all images, videos and embeds
7. Build cookie banners and ads so nothing jumps
8. Check hosting and caching
9. Revisit your field data after four weeks

Fast sites are easiest to get when speed is part of the plan from day one, which is how we approach web design. For existing sites, we measure and improve load times and Core Web Vitals as part of SEO and ongoing care, with hosting included if you like. Tell us through the contact form which site you’d like us to look at.