Core Web Vitals explained: how to get a fast, stable website

A website that loads slowly, jumps around while you read or reacts a second after a tap simply feels bad. Google has turned that feeling into three measurable values: the Core Web Vitals. For a business owner this sounds technical, but the core is simple: does the page load fast enough, does it stay still, and does it respond immediately? In this article we explain what the three metrics mean, which thresholds Google uses, how to measure them and what to do about them in practice.

What are Core Web Vitals?

Core Web Vitals are the three metrics Google singles out as the core of a web page's user experience. Each measures one aspect:

• Largest Contentful Paint (LCP): how quickly the main content of the page becomes visible, usually a large image or heading.
• Interaction to Next Paint (INP): how quickly the page responds when someone clicks, taps or presses a key.
• Cumulative Layout Shift (CLS): how much the page shifts unexpectedly while loading or afterwards.

INP replaced the older First Input Delay metric as a Core Web Vital. If you read an old article about “FID”, that part is outdated.

The thresholds

According to Google's documentation on web.dev, a page scores “good” when it meets the following values:

1. LCP: 2.5 seconds or faster.
2. INP: 200 milliseconds or faster.
3. CLS: 0.1 or lower.

“Poor” means an LCP above 4 seconds, an INP above 500 milliseconds and a CLS above 0.25. Everything in between is “needs improvement”. An important detail: the 75th percentile of all page visits is used, separately for mobile and desktop. That means at least three quarters of visits must meet the threshold. One quick measurement on your own laptop therefore says little.

Field data and lab data: what is the difference?

This is where most business owners trip up.

• Field data comes from real visitors, collected through Chrome. This is what counts. You see it in the Core Web Vitals report in Search Console and in PageSpeed Insights (when there are enough visitors).
• Lab data comes from a simulated test, such as Lighthouse. It is useful for finding problems and testing changes, but it is not the same as what visitors experience.

A small local website often has too little traffic for field data. Then PageSpeed Insights only shows lab data. Use it as direction, not as the final verdict.

Why it matters, and why not too much

Google states that Core Web Vitals are used by its ranking systems, but that they are one of several signals. Good content that matches what someone is looking for remains more important than a perfect score. A fast site with little to offer does not beat a good site that is slightly slower. There are, however, two practical reasons to care that have nothing to do with ranking: visitors leave a slow or jumping page sooner, and a form or button that does not respond immediately costs enquiries.

Improving LCP

LCP is usually determined by one element: the main image or the large heading at the top. What you can do:

• Make the image smaller. Serve images at the size they are displayed, in a modern format such as WebP or AVIF, with multiple sizes for mobile and desktop.
• Do not lazy-load the LCP image. Deferred loading is good for images further down the page, but slows down the image that is in view straight away. Give that image priority instead.
• Shorten the server response time. Good hosting, caching and few heavy plugins make a difference.
• Limit blocking CSS and fonts. Load only the styles and fonts needed for the visible part, and limit the number of font variants.

Improving INP

INP is about the time between a visitor's action and the next visible result. JavaScript is usually the cause.

• Remove scripts you do not use: old chat widgets, trackers, sliders and animation libraries.
• Load external scripts deferred, so they do not block the main thread.
• Break up heavy tasks and avoid long calculations on a click, for example in a menu or filter.
• Test on an average phone, not only on a fast laptop.

Improving CLS

Jumping pages occur when the browser does not know how much space something needs.

• Always give images and videos a width and height, or a fixed aspect ratio.
• Reserve space for embedded maps, review widgets, ads and cookie banners.
• Do not insert content above existing content after the page has been shown, unless the visitor asks for it.
• Make sure fonts do not cause a big jump once they have loaded.

Measuring in practice

A workable plan for a small website:

1. Enter your most important pages in PageSpeed Insights and look at the field data first, if it is there.
2. Open the Core Web Vitals report in Search Console to see groups of pages with problems.
3. Fix the biggest cause first. Often it is one image that is too heavy or one slow external widget.
4. Measure again. Field data lags, because it is collected over a period of weeks.

Example: a local business with a heavy homepage

Say a business in Zeeland Flanders has a homepage with a large photo slider, a chat widget and an embedded map. On mobile it takes a while for the first photo to appear (LCP), the page jumps when the map loads (CLS) and the menu reacts slowly because the slider runs a lot of JavaScript (INP). The fix is rarely complicated: one well-optimised main image instead of a slider, the map loaded only when someone scrolls to it with fixed space around it, and the chat widget only if it is really used. Less is more here.

Checklist

• The main image is the right size and in a modern format.
• The LCP image is not loaded lazily.
• Images, videos and embeds have fixed dimensions.
• Unused scripts and plugins are removed.
• External scripts are loaded deferred.
• You have measured on mobile, with field data where possible.

In conclusion

Core Web Vitals are not a goal in themselves, but a useful yardstick for a pleasant website. At CUBO Agency we build custom websites with clean code and light pages, so speed is not an afterthought. Want to know how your site is doing? Book a free intro call. Also read website development in Terneuzen for the broader context.

Sources

Reviewed on 28 October 2026 against the sources below. Rules and guidelines change; this article is general information, not legal or tax advice.

• Web Vitals (web.dev)
• How the Core Web Vitals metrics thresholds were defined (web.dev)
• Largest Contentful Paint (web.dev)
• Interaction to Next Paint (web.dev)
• Cumulative Layout Shift (web.dev)
• Understanding page experience in Google Search results (Google Search Central)
• PageSpeed Insights (Google)

Book an intro call