Core Web Vitals: what Google measures and how to improve them.

You open PageSpeed Insights, type in your site’s address and see an orange 54. Is that why you’re not moving up on Google? The answer is more complicated, and it starts with Core Web Vitals: three metrics Google uses to assess how real visitors experience the loading and use of a page.

Below you’ll see what each one measures, which thresholds apply, how much they really weigh in rankings and which changes to a WordPress site are worth making first. They’re also the fixes we make most often on the sites we maintain.

01What Core Web Vitals are: LCP, INP and CLS

Core Web Vitals are the core subset of Web Vitals, Google’s metrics for user experience. There are three, and each one answers a simple question:

• LCP (Largest Contentful Paint), loading. How quickly the largest element on the first screen appears, usually the main image or the heading. It’s the moment the visitor feels the page has “arrived”.
• INP (Interaction to Next Paint), responsiveness. How quickly the page reacts when you tap a button, open a menu or type in a field, throughout the visit. INP replaced the older FID on 12 March 2024.
• CLS (Cumulative Layout Shift), stability. How much the content “jumps” while it loads. The classic example: you go to tap a link and at the last moment it moves down, because an image or a banner loaded above it.

The thresholds, as shown in the Search Console Core Web Vitals report:

These metrics are considered stable: according to web.dev, they change at most once a year and every change is announced in advance. Since FID was replaced, the thresholds haven’t changed.

02Real users or the lab: which number counts

There are two kinds of measurement, and mixing them up is the most common misunderstanding we hear.

Field data consists of measurements from real visitors using Chrome, collected in the Chrome User Experience Report (CrUX). This is what the Search Console report shows. A page counts as “good” when at least 75% of visits are within the threshold (the 75th percentile), separately for mobile and desktop, and it only passes when it meets the target on all three metrics.

Lab data is a simulation: Lighthouse loads the page once, on a specific device and network speed. That’s where the well-known 0–100 PageSpeed Insights score comes from. It’s invaluable for finding what’s wrong, but it isn’t what the Core Web Vitals report shows. Lighthouse can’t even measure INP, since there’s no real user to tap anything, and it uses Total Blocking Time (TBT) as a proxy.

03How to measure your site’s Core Web Vitals

Two free Google tools are all you need:

• PageSpeed Insights. At the top it shows the field data for the page and for the whole site, if there’s enough. Below that, the Lighthouse diagnosis with the specific causes. Start with the mobile tab, where results are usually worse.
• Search Console. The Core Web Vitals report groups pages with a similar experience, e.g. all the products of an e-shop, and shows which group has a problem and on which metric. A group’s status is the worst of the three. When you fix something, you start validation and Google monitors the pages for 28 days.

A point that affects many small businesses: if the site doesn’t have enough traffic, Search Console will say no data is available and PageSpeed Insights will only show the lab results. That doesn’t mean everything is fine. It means Lighthouse is your guide, with attention to LCP, CLS and TBT.

04How much they count for Google and for sales

Google writes that Core Web Vitals are used by its ranking systems. But it writes just as clearly that there is no single “page experience” signal, that the most relevant content always takes priority even if the experience isn’t good, and that good numbers in the reports don’t guarantee top positions. They can help when there are many equally useful pages for a search.

Put simply: a slow site with the best content for “boat rental Corfu” won’t disappear from the first page. But among five similar rental sites, page experience can be one of the factors that sets them apart.

The most immediate reason to care is the visitors who already come. Vodafone Italy ran an A/B test on a landing page: the version with a 31% better LCP brought 8% more sales. In a Deloitte study commissioned by Google across 37 brands in Europe and the US, a 0.1-second improvement in four mobile speed metrics was linked to 8.4% more conversions on retail sites and 9.2% higher spend per customer. These are figures from large businesses and not a guarantee for every site, but they show which way the scales tip.

05LCP in WordPress: server, cache and images

On the WordPress sites we audit, LCP is usually the first problem. According to web.dev, 40% of sites in CrUX don’t meet the threshold. There are two main causes: a slow server response and a heavy or late-loading main image.

Hosting and page cache

Without a cache, WordPress builds every page from scratch on every visit, with PHP and database queries. On overloaded shared hosting this eats up time before anything else even starts to load. A page cache serves ready-made HTML and a CDN brings it closer to the visitor; according to web.dev, only 33% of requests for HTML pages are served from a CDN. In e-shops, the cart and checkout aren’t cached, so the server counts double there. That’s why speed starts with maintenance and hosting, not with a plugin.

Images at the right size and format

A photo from your phone, uploaded as it is, is the most common culprit. Upload images at the size the theme needs, in WebP or AVIF, and let WordPress create the smaller versions (srcset), so phones download a smaller file.

The main image doesn’t want lazy-loading

Lazy-loading delays images until they’re needed. It’s right for those further down and wrong for the first-screen image, which should load immediately, with fetchpriority=”high”. Since version 6.3, WordPress does this itself for the image it considers the likely LCP, which according to its team usually improves LCP by 5–10%. But it can’t do it when the image is set as a CSS background or when a slider loads it with JavaScript. web.dev reports that on 73% of mobile pages the LCP element is an image, and that for 35% of these the image’s address isn’t visible in the initial HTML.

Fonts

Every font weight is a separate file. Keep the ones you actually use, host them on your own server and preload the main one, so text appears without delay.

06INP: less JavaScript, less weight

INP suffers when the browser is busy with JavaScript and can’t respond to the user’s tap in time. Tasks over 50 ms are considered “long” and delay the response. In WordPress, JavaScript comes mainly from three sources:

• Page builders and “do-it-all” themes. They load code for dozens of features on every page, even if the page uses two. That’s why we build custom themes without a page builder. What this means for your budget we explain in the article on how much a website costs.
• Plugins. The problem isn’t only how many there are, but what each one loads and where. A form plugin that loads its scripts on every page, while the form is only on the contact page, is a common finding.
• Third-party scripts. Chat, advertising pixels, maps, booking widgets, cookie banners. Keep the ones you really use and load the rest later, or only on the pages that need them.

07CLS: reserve space for whatever loads later

CLS is usually the easiest to fix. The main causes:

• Images without dimensions. With width and height (or aspect-ratio in CSS), the browser reserves the space before the image arrives. According to web.dev, 66% of pages have at least one image without dimensions.
• Elements that appear above. Promo banners, notifications and embeds (maps, video, social) need a reserved height. A cookie banner that pushes the page down instead of appearing over it is a classic mistake.
• Animations. Animations using transform, instead of top, margin or height, don’t move the rest of the content.
• Fonts. When the final font differs a lot in size from the fallback, the text changes width and pushes whatever is around it.

08Where to start

1. Look at the field data in Search Console or PageSpeed Insights, mobile first. If everything is in “Good”, speed isn’t your problem.
2. If LCP is poor across the whole site, look at the server and cache first. If it’s poor on specific templates, look at their main image.
3. For INP, list which scripts run on each page and remove anything that isn’t needed.
4. For CLS, check image dimensions, banners and fonts.
5. After every change, give it time: field data changes gradually and validation in Search Console takes 28 days.

If you want to know where to start on your own site, our technical audit starts with speed and Core Web Vitals, and speed optimization fixes them in the order that counts.