Core Web Vitals Explained: How to Improve LCP, INP and CLS

Core Web Vitals are three Google metrics that measure real visitors’ experience of a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Improving them usually means faster servers and images, less JavaScript on the main thread, and reserving space for content before it loads.

This guide explains what each metric measures, how to find out where your site stands, and the fixes that make the biggest difference for typical small business websites.

What Core Web Vitals are and why they matter

Google introduced Core Web Vitals to give site owners a small, consistent set of measurements for user experience. They are based on field data: how pages actually perform for real people using Chrome, on their own devices and connections, rather than how they perform in a single test on a fast office computer.

They matter for two reasons. First, Google’s ranking systems use them as part of a wider page experience assessment. That influence is real but modest; Google has been clear that relevant, helpful content matters more, and a fast page with weak content will not outrank a slower page that answers the question better. Second, and more importantly for most businesses, they describe things visitors actually notice. Slow-loading pages, buttons that lag and layouts that jump around all make it harder for someone to read, enquire or buy.

So treat Core Web Vitals as a usability project that happens to help SEO, rather than as a ranking trick.

The three metrics and their thresholds

Each metric is assessed at the 75th percentile of page visits, separately for mobile and desktop. In plain terms, at least three in every four visits need to hit the “good” threshold for the page to pass. Setting the bar there means people on older phones and slower connections count too, which is why a page can feel fast to you but still fail.

A note on FID and INP

Interaction to Next Paint replaced First Input Delay (FID) as one of the three core metrics in March 2024. FID only measured the delay before the browser began handling the first interaction on a page. INP looks at interactions throughout the visit and measures the full time until the screen visibly updates, so it is a much better reflection of how responsive a page feels. Many sites that comfortably passed FID found they had INP problems, particularly those with heavy JavaScript.

How to check your Core Web Vitals

There are two kinds of data, and they are easy to mix up.

• Field data comes from real Chrome users, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day period. This is what Google uses for its assessment.
• Lab data comes from a simulated test, such as Lighthouse, under fixed conditions. It is useful for diagnosing problems and testing fixes, but it is not what Google uses to judge your pages.

The main tools are:

Two practical points. Lighthouse cannot measure INP, because it does not interact with the page as a person would; Total Blocking Time is its closest lab indicator. And low-traffic pages may not have enough CrUX data to show individually, in which case Search Console groups them with similar pages or shows no data. All of these Google tools are free, and they sit well alongside the others in our list of free marketing tools for small businesses.

How to improve Largest Contentful Paint (LCP)

The LCP element is usually the largest image or block of text visible when the page first loads, often a hero image, a banner or the main heading. LCP time can be broken into four parts, and diagnosing which part is slow points you to the fix:

1. Time to First Byte (TTFB): how long the server takes to start sending the page.
2. Resource load delay: the gap before the browser starts downloading the LCP image.
3. Resource load duration: how long the image takes to download.
4. Element render delay: the time between the download finishing and the element appearing on screen.

Fixes that usually help

• Improve server response. Use good-quality hosting, page caching and a content delivery network (CDN). On WordPress, an overloaded shared server or an uncached page builder is a common cause of slow TTFB.
• Make the LCP image discoverable early. Put it in the HTML as a normal image rather than a CSS background or a script-loaded slider, so the browser finds it straight away.
• Never lazy-load the LCP image. Lazy loading is great for images further down the page but delays the most important one.
• Prioritise it. Adding fetchpriority=”high” to the hero image tells the browser to fetch it first.
• Shrink it. Serve modern formats such as WebP or AVIF, size images to the space they occupy, and use responsive images so phones do not download desktop-sized files.
• Reduce render-blocking resources. Inline critical CSS, defer non-essential JavaScript and limit the number of web fonts and font weights.
• Avoid hiding content until scripts run. Animations that fade content in after JavaScript loads can push LCP back considerably.

How to improve Interaction to Next Paint (INP)

INP measures the time from a user’s interaction, such as tapping a menu button or selecting a product option, to the next frame the browser paints. It reports roughly the worst interaction on a page visit, ignoring rare outliers on pages with many interactions. Each interaction has three phases:

• Input delay: the wait before your code can start running, usually because the main thread is busy with something else.
• Processing time: how long your event handlers take to run.
• Presentation delay: the time the browser needs to recalculate layout and paint the result.

The browser’s main thread can only do one thing at a time. Any task that runs for more than 50 milliseconds is classed as a long task, and while it runs, the page cannot respond to the user. Poor INP is almost always a JavaScript problem.

Fixes that usually help

• Audit third-party scripts. Chat widgets, tag managers, analytics, review widgets, heatmaps and advertising scripts all compete for the main thread. Remove what you do not use and load the rest later where possible.
• Reduce plugin and app bloat. On WordPress and Shopify, each plugin or app may add its own scripts to every page, even where it is not needed.
• Break up long tasks. Developers can split heavy work into smaller chunks and yield to the main thread so the browser can respond to input in between.
• Give immediate visual feedback. Update the interface first, for example opening the menu or showing a loading state, and do slower work afterwards.
• Keep the DOM lean. Very large pages, often produced by page builders, make every layout recalculation slower.
• Avoid unnecessary work on input. Debounce handlers on scroll and typing, and avoid code that forces repeated layout recalculations.

How to improve Cumulative Layout Shift (CLS)

CLS measures how much visible content moves unexpectedly while someone is using the page. It is the problem behind tapping the wrong button because an advert loaded above it, or losing your place in an article as images pop in. Shifts that happen within half a second of a user’s own interaction, such as expanding an accordion, are not counted, because the user expects them.

Fixes that usually help

• Set dimensions on images and videos. Include width and height attributes, or use CSS aspect-ratio, so the browser reserves the right space before the file loads.
• Reserve space for adverts, embeds and iframes. Give containers a minimum height that matches the content expected to load into them.
• Do not insert content above existing content, such as cookie banners, promotional bars or “related” panels that push the page down after it renders. Overlay them instead, or reserve their space from the start.
• Manage web fonts. Preload key fonts and use font fallbacks with similar metrics so text does not reflow noticeably when the custom font arrives.
• Animate with transforms. Animations using CSS transform and opacity do not trigger layout shifts; animating height, top or margin does.
• Allow back/forward cache. Pages restored instantly from the browser’s back/forward cache typically avoid layout shifts and load delays entirely, so avoid patterns that make pages ineligible for it.

Why mobile usually fails first

It is common to see a site pass Core Web Vitals on desktop and fail on mobile. That is not a quirk of the tools. Phones generally have slower processors than laptops, and many visits happen on mobile networks with variable speed and latency. The same page, the same images and the same JavaScript take longer to load and process.

INP is especially sensitive to this, because a script that runs quickly on a powerful desktop can block the main thread for much longer on a mid-range phone. When you test, use the mobile results in PageSpeed Insights, and in DevTools apply CPU and network throttling so the lab conditions are closer to what many of your visitors experience. Designing and building for a mid-range phone first, then enhancing for larger screens, tends to produce pages that pass on both.

Common causes on small business websites

Most small business sites are built on WordPress, Shopify or a similar platform, and the same issues come up again and again:

If your site runs on WordPress, a well-built theme and disciplined plugin choices go a long way; our WordPress development team regularly rebuilds slow templates with performance in mind from the outset.

A practical workflow for fixing Core Web Vitals

1. Start in Search Console. Identify which URL groups fail, on which device type and for which metric.
2. Pick representative pages from each failing group, usually one per template: homepage, service page, product page, blog post.
3. Run them through PageSpeed Insights and note the field data and the lab diagnostics.
4. Diagnose in Chrome DevTools to find the LCP element, long tasks and layout shift sources.
5. Fix at template level, so one change improves every page that uses it.
6. Test in the lab to confirm the fix works before deploying.
7. Validate in Search Console after release, and allow the 28-day field data window to reflect the change.
8. Keep monitoring, because new plugins, scripts and content can undo gains quickly.

Prioritise the pages that matter commercially, such as key landing, service and product pages, rather than trying to perfect every URL at once. Speed improvements often help conversions as well as visibility, which is worth tracking alongside your website conversion rate.

Where to start on your own site

Open the Core Web Vitals report in Search Console, find the failing template that gets the most commercial traffic and fix that one first. Some fixes are a settings change in a caching plugin; others need a developer to restructure templates or JavaScript.

We handle both ends of that through our website speed optimisation service, and our technical SEO team makes sure the performance work fits into a wider plan for search visibility.

Share:LinkedInXEmail