Website speed: Core Web Vitals and what improves them

A slow website costs you in ways that rarely show up as a single line in a report. People leave before the page appears, tap a button that doesn’t respond, or hit the wrong link because the layout jumped. Google packages the most important of these experiences into three measures it calls Core Web Vitals.

This guide explains what each one measures, what counts as good, how to check your own site and which fixes tend to help. It is written for founders and managers who need to brief a developer or agency, not for performance engineers.

The three Core Web Vitals

Google’s web.dev guide to Web Vitals names three current Core Web Vitals, each covering one part of the experience:

The thresholds come from web.dev’s pages on LCP, INP and CLS. INP became a stable Core Web Vital in 2024, replacing First Input Delay, so older reports that mention FID are out of date.

One detail changes how you read the numbers. Google assesses each metric at the 75th percentile of page loads, split by mobile and desktop. A page passes only when it meets the “good” threshold for all three metrics at that level. Put simply, three out of four visits need to be good, not just the average.

Does it affect search rankings?

Google Search Central’s page on Core Web Vitals says Google “highly recommend[s] site owners achieve good Core Web Vitals for success with Search” and that they are part of a page experience that “aligns with what our core ranking systems seek to reward”. It does not say good scores guarantee a higher ranking, so treat speed as something that helps visitors first and search second.

How to check your site

There are two kinds of data, and they answer different questions.

• Field data comes from real visitors using real devices. Google’s Chrome User Experience Report (CrUX), the Core Web Vitals report in Search Console and PageSpeed Insights all show it. This is what Google uses for its assessment.
• Lab data comes from a test run in controlled conditions, using tools such as Lighthouse, Chrome DevTools or WebPageTest. It is good for diagnosing problems and checking a fix before release, but it may not match what real users experience.

Start with field data to find which pages and which metric fail, then use lab tools to work out why. Small sites may not have enough traffic for field data; in that case, lab tests on a mid-range phone setting are a reasonable stand-in.

What improves LCP

LCP measures when the largest visible element, often a hero image, a video poster or a large block of text, finishes rendering. web.dev’s guide to optimising LCP breaks it into four parts: time to first byte from the server, the delay before the main resource starts loading, the time spent downloading it, and the delay before it is drawn.

Its main recommendations:

• Make the main image discoverable in the page’s HTML, and don’t lazy-load it. The guide says plainly: “Never lazy-load your LCP image.” Marking it with fetchpriority="high" also helps.
• Cut render-blocking CSS and avoid synchronous scripts in the page head.
• Compress images, use modern formats, and serve them from a content delivery network (CDN) with caching.
• Speed up the server’s first response and reduce redirects.

The guide also warns that fixing one part can shift time into another, so check the whole sequence after each change.

What improves INP

INP looks at the delay between an interaction and the next frame the browser paints, across the whole visit. It doesn’t count scrolling or hovering. Poor INP usually means the browser’s main thread is busy running JavaScript when the user taps.

web.dev’s advice is to find slow interactions in field data first, then reproduce them. Typical fixes include breaking up long tasks, reducing how much JavaScript runs, moving heavy work off the main thread, and keeping the page’s structure (the DOM) a manageable size. On many small business sites, a quick win is removing third-party scripts that aren’t earning their keep: old tracking tags, chat widgets nobody uses, and duplicate analytics.

What improves CLS

web.dev lists the common causes of layout shift: images or videos without set dimensions, web fonts that render at a different size from the fallback font, and ads or widgets that resize themselves. The fixes follow from the causes. Give images and embeds a width and height or a fixed space, reserve room for ad slots and banners before they load, and choose font loading settings that limit reflow. When a user action triggers a slow request, show a placeholder straight away so content doesn’t jump when the result arrives.

A worked example

An example (illustration only). A small fashion retailer’s product pages show these field figures on mobile at the 75th percentile: LCP 4.3 seconds, INP 180 ms, CLS 0.22.

• LCP is poor. The developer finds the main product photo is a 2.5 MB file, lazy-loaded by a theme setting. They resize and compress it, switch off lazy loading for that image and add a high fetch priority.
• INP is good, so no work is needed there yet.
• CLS needs improvement. A promotional banner loads after the page and pushes everything down. The team reserves a fixed space for it at the top of the page.

Lab tests confirm the changes. The team then waits for the field data to update over the following weeks before judging the result, because field figures are gathered from real visits over time.

Common mistakes

• Chasing a perfect lab score while real-user data stays poor. Field data is what counts.
• Testing only on a fast office computer. Most problems show up on mid-range phones and mobile networks.
• Lazy-loading everything, including the main image, which delays LCP.
• Adding scripts without removing old ones. Every tag manager addition has a cost.
• Treating speed as a one-off project. New features, apps and campaigns slow sites down over time, so check monthly.

Core Web Vitals are most useful for sites where visitors arrive from search or ads and decide quickly whether to stay: shops, publishers and lead generation pages. For a logged-in internal tool with a handful of users, plain responsiveness testing with those users may be a better use of time than chasing Google’s thresholds.