Core Web Vitals 2026: what Google measures and 10 fixes

Core Web Vitals are the three metrics Google uses to measure the real experience of the people visiting your website: how long the important part takes to show up (LCP), how long the page takes to react when you tap something (INP) and how much the page "jumps" while loading (CLS). In 2026 the thresholds are still 2.5 seconds, 200 milliseconds and 0.1, measured on the 75th percentile of real visits. If your site fails them it does not vanish from Google, but it competes at a disadvantage and, above all, loses customers who get tired of waiting.

What each metric measures (and what it means for your business)

LCP: how long until the important part appears

Largest Contentful Paint measures the time until the largest visible element is painted: usually the header photo or the headline. Google considers an LCP of 2.5 seconds or less good, according to the official web.dev documentation. Above 4 seconds it is "poor". On a small business site the culprit is almost always a 3 MB hero image or slow hosting.

INP: how long it takes to respond when someone taps something

Interaction to Next Paint replaced FID as the official metric on 12 March 2024. It measures the delay between an interaction (a click, a tap, a keystroke) and the next repaint of the screen. Good: 200 ms or less; poor: more than 500 ms. Sites built with lots of plugins and third-party scripts (chats, maps, embedded videos, pixels) suffer the most here.

CLS: how much the page moves while loading

Cumulative Layout Shift quantifies those annoying jumps: you go to press a button and suddenly a banner appears and you press something else. Good: 0.1 or less; poor: more than 0.25. It usually comes from images without declared dimensions, fonts that change once loaded, or ads and cookie notices that push the content down.

Field data versus lab data

There is a nuance that confuses a lot of people: the Lighthouse or PageSpeed score you see in the "lab" panel is a simulation. What Google uses to evaluate your site is the field data from the Chrome UX Report (CrUX), i.e. the real experience of Chrome users who visited your page, measured at the 75th percentile and split between mobile and desktop. If your site gets little traffic you may not even have field data; in that case use the lab data as an approximation, bearing in mind that a cheap phone on 4G is slower than your agency's laptop.

Where to check: PageSpeed Insights (shows both field and lab) and the "Core Web Vitals" report in Google Search Console, which groups the URLs with problems.

10 typical fixes on small business websites

1. Shrink the header image. Export to WebP or AVIF, at the real width it is displayed at (do not upload the original camera photo) and load that first image with priority (fetchpriority="high"), without loading="lazy".
2. Lazy-load the rest of the images. Everything not visible on arrival should carry loading="lazy". It is an HTML attribute, no plugin needed.
3. Declare width and height on every image. With width and height the browser reserves the space and the content does not jump. It is the cheapest CLS fix there is.
4. Fonts: fewer families and preloading. Two typefaces at most, WOFF2 format, hosted on your own domain and with font-display: swap or, better, metric adjustments so the text does not shift when the font swaps.
5. Remove third-party scripts you do not use. Every chat, map, carousel or pixel you added "just in case" costs INP. Take stock and keep only the ones that generate business.
6. Load heavy stuff after the interaction. The Google map or the YouTube video can be shown as an image and loaded only on click. We call that a "facade".
7. Hosting and caching. A saturated shared server takes 1-2 seconds just to start responding (TTFB). Page caching, Brotli or gzip compression and, if your audience is in Spain, a server in Europe.
8. Minimal CSS and JavaScript. Generic templates load half a megabyte of CSS to use 5 % of it. A custom build loads what the page needs and nothing else.
9. A cookie banner that does not push the content. It should overlay (fixed position) rather than insert a block above the page. Same for notice bars.
10. Split long JavaScript tasks. If an interaction is slow it is usually because a script blocks the main thread for more than 50 ms. Chunking tasks, using requestAnimationFrame to paint first and deferring the non-urgent improves INP without rebuilding the site.

How much does it affect SEO?

No hype: page experience is a ranking factor, but relevant content weighs more. Two sites with the same content, the fast one wins; a slow site with better content can still rank ahead. What is certain is that speed affects conversion: every extra second on mobile is forms that never get sent and calls that never get made. That is why in our web projects we measure all three metrics before delivery and review them whenever content is added.

Frequently asked questions

What PageSpeed score do I need to "pass"?

None in particular. Google evaluates the three Core Web Vitals with real data, not the 0-100 Lighthouse score. Focus on getting LCP, INP and CLS into green in the Search Console report.

Can my WordPress site pass Core Web Vitals?

Yes, but it takes discipline: a light theme, few plugins, optimised images and caching. Most small business sites that fail do so because of plugin bloat, not WordPress itself.

How often should I check them?

Once a quarter and whenever you change something big (new template, new plugin, new photos). Field data is calculated over the last 28 days, so a fix takes a few weeks to show.

If you want to know where your website stands and which fixes are worth it, tell us about your project and we will tell you what we would do first.