Website speed and Core Web Vitals: why it matters, how to measure and fix it
Maybe Digital · 8 min read · Updated:
Short answer
Core Web Vitals are three metrics Google uses to measure real user experience: LCP (Largest Contentful Paint) is "good" at 2.5 seconds or less, INP (Interaction to Next Paint) at 200 milliseconds or less, and CLS (Cumulative Layout Shift) at 0.1 or less. A fast site keeps visitors, makes conversion easier and counts in its favour in Google's page experience assessment.
Why speed matters
Visitors lose patience while a page loads. On mobile in particular, on a weak connection, a slow site gets closed before its content is seen. However well designed, a page nobody sees can't sell.
Google also uses Core Web Vitals when assessing page experience. Speed alone won't lift you to the top; content is still the main factor. But between two pages of similar quality, the one offering a better experience can get ahead. Most importantly, a fast site makes it easier to fill in a form, add a product to the cart or make a call.
Core Web Vitals: three metrics in plain words
Google collects these metrics from real users' visits and rates a page "good" on a metric when at least 75 percent of page loads fall within the threshold. INP replaced FID (First Input Delay) in March 2024, which is why older guides still mention FID.
- LCP (Largest Contentful Paint): how long it takes for the largest visible element, usually the main image or heading, to appear. Good: 2.5 seconds or less.
- INP (Interaction to Next Paint): how quickly the page visibly responds when a user taps a button or opens a menu. Good: 200 milliseconds or less.
- CLS (Cumulative Layout Shift): unexpected movement of content while the page loads, such as a button jumping down just as you tap it. Good: 0.1 or less.
How to measure: field data and lab data
There are two kinds of measurement, and knowing the difference prevents bad decisions. Field data comes from real users visiting your site in Chrome; it's what Google takes into account. Lab data is a simulation on one test device under set conditions; it's ideal for finding a problem and trying a fix.
PageSpeed Insights (pagespeed.web.dev) shows both: real-user data at the top when there's enough traffic, and a Lighthouse lab test with suggestions below. The Core Web Vitals report in Google Search Console covers your whole site and groups similar pages, so you can see which page types have problems. A Lighthouse score of 100 isn't the goal on its own; the real goal is all three metrics being "good" for real users.
The usual causes of a slow site
On most slow sites, the problem comes from a handful of familiar places. Look first at which metric is poor; the cause usually follows from that.
- Large, uncompressed images: usually the number one cause of poor LCP.
- Web fonts: late-loading fonts make text appear late or shift.
- Third-party scripts: chat widgets, ad and tracking tags, embedded videos and social plugins.
- Too much JavaScript: heavy code that keeps the browser busy makes the page slow to respond to taps, i.e. poor INP.
- A slow server and no CDN: if the first byte arrives late, everything else is late too.
- Images, ad slots and banners without reserved dimensions: the typical causes of poor CLS.
Fixes: where to start
Serve images at the right size and in modern formats such as WebP or AVIF; lazy-load images that aren't visible at first, but never lazy-load the main image, prioritise it instead. Give images width and height so the page doesn't shift.
Reduce the number and weight of fonts, self-host them where possible, and use the font-display setting so text shows without waiting. Review third-party scripts one by one: remove the ones nobody uses, and load the necessary ones after the page has loaded.
Good hosting and a CDN (content delivery network) serve the page from a point close to the user. Load JavaScript only on the pages that need it and only as much as needed; render what you can on the server and send it as plain HTML. Measure again after every change, and remember that field data can take a few weeks to update.
Speed isn't a one-off job
A site that's fast today slowly gets heavier with every new plugin, tracking tag and large image. That's why speed should be a regular part of maintenance: checking the Search Console report monthly and asking "how much will this slow the page down?" before adding a new tool keeps problems from piling up.
Frequently asked questions
- My PageSpeed score is low. Will Google penalise me?
- The Lighthouse score isn't a direct ranking signal. Google looks at Core Web Vitals data from real users, and that's just one signal alongside stronger factors such as content and relevance. A low score still points to problems worth fixing.
- Why don't I see any field data?
- Field data comes from real visits by Chrome users. If a site or page doesn't have enough traffic, PageSpeed Insights shows only the lab result. In that case, use lab tests as your guide.
- Will a more expensive server make my site faster?
- If the server is the bottleneck, yes. But if the problem is large images, fonts or too much JavaScript, a bigger server won't fix it. Measure which metric is poor and why first.