A tiler in Leeds hears from a customer that his website “takes ages” on a phone. He runs it through a testing tool, sees a score in red and a list of technical suggestions, and has no idea which of them matters. Some of the advice is about images, some about scripts, some about fonts, and none of it says what a visitor would notice.
Core Web Vitals give that list a structure. Each of the three metrics maps to something a person feels, and each has a short list of typical fixes. Read the metric first, then pick the fix, and the report stops being a wall of jargon.
The three targets and how they are judged
According to web.dev, a page is judged on three things, each with a “good” threshold:
- Largest Contentful Paint (LCP): how long the biggest visible element, usually a hero image or a headline, takes to appear. Good is 2.5 seconds or less.
- Interaction to Next Paint (INP): how quickly the page reacts when someone taps, clicks or types. Good is 200 milliseconds or less.
- Cumulative Layout Shift (CLS): how much the content jumps around while loading. Good is 0.1 or less.
The scores are taken at the 75th percentile of page loads, separately for mobile and desktop. A page passes only when all three metrics reach their targets at that level, which means three out of four visits have to be at least that good. One fast test on your own laptop says little.
Where to read your own numbers
There are two kinds of data. Field data comes from real visitors, and web.dev treats it as the primary measure. Lab data comes from a simulated test, which is useful while you are fixing things but, in web.dev’s words, not a substitute for field measurement.
- Search Console has a Core Web Vitals report showing how groups of your pages perform.
- PageSpeed Insights shows field data when enough exists for your page and a lab run alongside it.
- Lighthouse in Chrome measures LCP and CLS in the lab, but it cannot measure INP because it does not interact with the page. It reports Total Blocking Time as a stand-in.
When the page loads slowly: LCP
web.dev splits LCP into four parts: the wait for the server to start answering, the delay before the main image or text starts loading, the time to download it, and the delay before it is drawn. Improving one often just moves time to another, so check all four. These changes work on most business sites:
- Put the main image in the page’s HTML so the browser finds it early, rather than loading it through a script or a CSS background.
- Do not lazy-load that image. Lazy loading is for pictures further down the page. Marking the one or two most likely LCP images with fetchpriority=“high” tells the browser to fetch them first.
- Compress the image, serve a size that fits the screen and use a modern format.
- Reduce redirects and use a content delivery network or caching so the first response arrives sooner.
- Keep render-blocking CSS and scripts in the page head small.
When things jump: CLS
Layout shift is the experience of going to tap one button and hitting another because an image or banner pushed everything down. The fixes are mostly about reserving space:
- Give every image width and height attributes, or set a CSS aspect-ratio, so the browser knows the room needed before the file arrives.
- Reserve a fixed space for embeds, maps, cookie banners and adverts, and keep that space even if nothing loads.
- Choose a fallback font that is close to your web font and consider font-display settings so text does not reflow when the real font arrives.
- Animate with transform rather than properties such as top or left, which force a re-layout.
When taps feel sluggish: INP
INP measures the delay between an action and the next visible update, and web.dev calls anything above 500 milliseconds poor. Slow responses usually come from the browser being busy running scripts when the visitor acts. Fixes are mostly about doing less work: load less JavaScript during page load, split long tasks so the page can respond between them, and avoid very large page structures. On a typical small-business site, the quickest gains often come from removing plugins and tracking scripts you no longer use.
How much does this matter for search?
Google’s documentation says it strongly recommends good Core Web Vitals for success in Search and for a better user experience. It frames them as one part of page experience, which sits alongside other things its ranking systems look at. In other words, speed is worth fixing and it is not a replacement for relevant, useful content. A page that loads in two seconds but says nothing helpful will not be rescued by its scores.
A sensible order of work is to fix the slowest important page first, usually the home page or your main service page, re-test in the field data after a few weeks, and then move on. For the cost side of building fast sites, our guide to website design cost is a useful companion.