Core Web Vitals and site speed: a guide to LCP, INP and CLS.

A visitor arrived at your site, but the page didn’t load; they tapped a button, but nothing happened; they started reading and the text jumped down. Each of these three small frustrations has a name at Google: Core Web Vitals. The clearest way to measure and improve site speed runs through these three metrics.

In this article we explain what Core Web Vitals are, the current “good” thresholds for LCP, INP and CLS, which tools to use to measure them correctly and how, and the improvements that make the biggest difference for each.

Even without a technical team, by the end of the article you’ll be able to check your site’s status yourself and ask your agency or developer the right questions.

Why is site speed both a customer and an SEO issue?

A slow site first loses you users. A visitor staring at a blank screen for a few seconds on a mobile connection goes back to the search and clicks the next result. For traffic you’ve paid for with ads, that is a direct loss of money.

On Google’s side, Core Web Vitals are among the signals its ranking systems consider as part of “page experience”. Google Search Central states this clearly; however, the same document stresses that content relevance is still far more decisive. So a fast page with weak content won’t rise to the top; between two pages of similar quality, though, experience can make the difference.

Speed alone won’t make you number one, but slowness can easily leave you behind.

Core Web Vitals metrics and 2026 thresholds

Core Web Vitals consist of three metrics. Each measures a different aspect of user experience: loading, interactivity and visual stability.

An important detail: Google evaluates these values at the 75th percentile of real users. In other words, at least 75 percent of visits must fall within the “good” threshold. For a page to pass Core Web Vitals, all three metrics must be good; if one is poor, no averaging takes place.

How to measure Core Web Vitals: field data and lab data

The most common measurement mistake is deciding based on a single PageSpeed score. There are two types of data, and they tell you different things:

• Field data: Chrome UX Report (CrUX) data collected from the real experiences of Chrome users. This is the data Google considers for ranking, and it reflects the average of the last 28 days.
• Lab data: A Lighthouse test run on a single simulated device and connection. It is ideal for diagnosing problems but doesn’t exactly reflect real user experience. It can’t measure INP directly; Total Blocking Time (TBT) is used instead.

Which tool should you use for what?

• PageSpeed Insights: Shows both field and lab data together for a single URL. Rely on the “real user experience” section at the top.
• Search Console — Core Web Vitals report: Groups your whole site into similar pages and shows which URLs are poor on mobile and desktop.
• Chrome DevTools (Performance panel): The developers’ tool for finding the cause of slow interactions and shifts line by line.
• web-vitals library: Google’s small JavaScript library for sending real user measurements to your own analytics tool.

How to improve LCP: show the main content faster

On most corporate sites, the LCP element is the large image (hero) or main heading at the top of the page. LCP time consists of four parts: the server’s first response (TTFB), resource discovery, resource download and rendering. Improvements follow the same order.

• Speed up the server response: web.dev considers a TTFB of 0.8 seconds or less to be good. Page caching, quality hosting and a CDN reduce this time significantly.
• Make the LCP image discoverable early: Put the image directly in the HTML, not via a CSS background or JavaScript; prioritise it with fetchpriority="high".
• Don’t lazy-load the above-the-fold image: Lazy loading is for images below the fold; on the main image it delays LCP.
• Shrink the image: Use WebP or AVIF, the right dimensions and srcset to avoid downloading unnecessarily large files on mobile.
• Reduce render-blocking resources: Inline critical CSS, remove unused CSS and synchronously loaded scripts, and use font-display: swap for fonts.

For the impact of hosting decisions on speed, see our article on choosing a domain and hosting as well.

How to improve INP: respond to clicks instantly

INP problems usually stem from the browser’s main thread being busy with JavaScript. The user taps the menu, but the response is delayed because the browser is running an analytics script or a large slider’s code at that moment.

• Break up long tasks: Split JavaScript tasks longer than 50 ms into chunks; give the user visual feedback first and do the heavy work afterwards.
• Review third-party scripts: Chat bubbles, heatmap tools and multiple ad and analytics tags are the most common INP culprits. Keep the ones you really use and defer loading the rest.
• Keep the DOM small: On pages with thousands of elements, re-rendering after every interaction becomes expensive.
• Reduce plugin and theme overhead: Unused code that ready-made themes load on every page slows interaction, especially on low-end phones.

This is where the choice of platform becomes decisive. For the difference between a site that grows with plugins and a lightweight site written for its needs, see WordPress or custom software.

How to improve CLS: stop the page from shifting

The line you’re reading suddenly jumping down, or a button moving just as you’re about to tap it, is what CLS measures. Fortunately the fixes are usually simple:

• Give images and videos dimensions: With width and height attributes or CSS aspect-ratio, the browser reserves the space in advance.
• Reserve fixed space for ads, banners and embeds: A cookie notice or campaign bar that loads later shouldn’t push content down; it should open as an overlay on top.
• Smooth out font swaps: Preload the web font and keep the fallback font’s metrics close to it.
• Use transform for animations: Animate with transform and opacity instead of layout-affecting properties such as top, left and height.

The most common speed problems by site type

Not every site is slow for the same reason. Here is a summary, by site type, of what we encounter in projects:

This table is a starting point; an exact diagnosis always comes from measurement. Still, knowing where the problem most likely lies saves time when talking to a developer. For example, if the product detail page of an e-commerce site is fast but the category page is slow, the problem is usually dozens of listed images being downloaded at once and at full size.

If you’re aiming for a fast, lightweight experience that feels like a mobile app, this needs to be discussed at the design stage. Every “small” feature added to a page later takes a share of the speed budget.

A step-by-step plan to speed up your site

Instead of trying to fix everything at once, start with what has the biggest impact:

• Step 1 — Open the Core Web Vitals report in Search Console and list the page groups rated “poor” on mobile.
• Step 2 — Test a sample URL from each group in PageSpeed Insights and note which metric is failing.
• Step 3 — Fix template-level problems first: hundreds of pages using the same template improve with a single fix.
• Step 4 — Apply quick wins such as images, caching and a CDN; then move on to JavaScript and third-party scripts.
• Step 5 — Click “validate fix” in Search Console and wait for the field data to update within 28 days.

Speed is not a one-off project but a budget that must be protected continuously. A new plugin, a large image or an extra tracking code can undo the gains within a few weeks. So before adding any new feature, ask “how much will this slow the page down?” If you want to see speed’s place in search visibility in a broader context, you can also take a look at our technical SEO checklist.

Frequently asked questions

Final word

Core Web Vitals reduce how your site feels to visitors to three numbers: the main content should appear within 2.5 seconds, every click should get a response within 200 milliseconds, and the page should shift by less than 0.1. Meeting these targets usually requires not an expensive rebuild but the right diagnosis and disciplined small fixes.

At CYF Tech, we design the websites and web software we build with a speed budget from the outset, and we also carry out Core Web Vitals analysis and improvements on existing sites. If you’d like to find out together why your site is slow, contact us.