Improving Core Web Vitals: LCP, INP and CLS in Practice

You improve Core Web Vitals fastest by first using field data to find out which of the three metrics – LCP, INP or CLS – fails for your visitors, and then fixing its main cause: server response or hero image for LCP, JavaScript on the main thread for INP, missing placeholders for CLS. Good means LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1.

Core Web Vitals are Google’s metrics for the user experience of loading, using and reading a page. They are one factor among many for visibility and no substitute for relevant content, but they reliably show where visitors wait or leave. This article explains how to measure correctly, what causes poor values and how to make the improvement last.

The Three Metrics and Their Thresholds

Metric	Measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	when the largest visible content in the first screen has loaded	up to 2.5 s	2.5–4.0 s	over 4.0 s
INP (Interaction to Next Paint)	how quickly the page visibly responds after a click, tap or key press	up to 200 ms	200–500 ms	over 500 ms
CLS (Cumulative Layout Shift)	how much visible content shifts unexpectedly	up to 0.1	0.1–0.25	over 0.25

Each metric is assessed at the 75th percentile of field data, separately for mobile and desktop: at least three out of four visits must meet the threshold. INP replaced the earlier metric FID in 2024. It takes the interactions of an entire visit into account and essentially reports the slowest one, not just the first. For an overview of the terms, see our glossary entry on Core Web Vitals.

Measuring Correctly: Field First, Then Lab

• Field data (real visitors): the “Core Web Vitals” report in Google Search Console, PageSpeed Insights based on the Chrome User Experience Report (CrUX) and your own real-user monitoring with the web-vitals library.
• Lab data (reproducible): Lighthouse, Chrome DevTools and WebPageTest for troubleshooting; Total Blocking Time serves as an approximation for INP.

Three peculiarities slow down the impatient. First, the CrUX data in Search Console and PageSpeed Insights covers a rolling period of 28 days, so improvements become visible there only gradually. Second, pages with little traffic have no field data of their own; then look at the domain level or use your own monitoring, which should not collect personal data. Third, the Lighthouse score is not a Core Web Vitals value: it can show 100 while real visitors on older smartphones on mobile networks fare considerably worse.

Improving LCP, INP and CLS Systemati­cally

LCP: four phases, four starting points

First establish which element is the LCP – usually a hero image, a video poster or a large heading. PageSpeed Insights and DevTools show it. Then you can see in which of the four phases the time is lost:

Phase	Typical cause	Remedy
Server response (TTFB)	slow hosting, missing caching, heavy database queries, many plugins	page and server cache, CDN, lean queries, suitable hosting
Resource load delay	hero image is discovered late, loaded via CSS background or script, or wrongly lazy-loaded	serve the image as img in the HTML, do not lazy-load it, prioritize it with fetchpriority=high
Resource load duration	oversized image file, no modern format	suitable sizes via srcset, compression, WebP or AVIF
Rendering (render delay)	render-blocking CSS or JavaScript, page built only in the browser by a framework	critical CSS early, scripts with defer, server-side rendering instead of purely client-side building

A classic mistake: the LCP image carries loading=lazy, a reflex from well-meant image optimization. Deferred loading (lazy loading) belongs only on images below the first screen. If server response accounts for the lion’s share, image optimization achieves little – check caching and hosting first.

INP: relieve the main thread

INP consists of three phases: input delay (the main thread is busy), processing (event handlers run) and presentation delay (until the next frame is painted). Poor values usually arise because too much JavaScript blocks the main thread.

• Split long tasks over 50 milliseconds into smaller steps and give the browser room in between, for example with scheduler.yield() where the browser supports it, or with setTimeout.
• Evaluate third-party scripts – tag manager, chat, tracking, consent tools – by value, load them only after consent or interaction and remove what nobody analyzes.
• Keep event handlers lean, move compute-heavy work into web workers, do not alternate layout reads and writes.
• Keep the DOM small and virtualize very long lists, because every update of large pages is expensive.
• Show feedback immediately, for example a loading state, even if processing takes longer.
• In frameworks, check hydration and re-renders and do not hydrate components without interaction.

Measure INP in the field wherever possible, because it depends on actual interactions. In the lab, the DevTools Performance panel helps. The default Lighthouse run does not capture interactions and provides Total Blocking Time as an indicator instead.

CLS: reserve the space

• Give images, videos, maps and iframes fixed dimensions, via width and height or aspect-ratio.
• Reserve space for banners, ads, embeds and cookie notices; better to show banners as an overlay at the edge than to push content down.
• Preload web fonts, choose font-display deliberately and use a fallback font with similar metrics so line breaks stay stable when fonts load.
• Never insert content above content that is already visible.
• Implement animations with transform and opacity, not via size or position values.

Third Parties, CMS and Hosting: Where the Effort Really Arises

On company websites a large share of the load often comes not from your own code but from tag manager, chat widget, consent banner, maps, social embeds and plugins. Go through the list script by script: who uses it, who analyzes it, what does it cost in load time? On CMS-based sites, plugins often load CSS and JavaScript on every page, even where they are not needed. How to make WordPress both safer and leaner is described in the article Securing WordPress.

Staying Fast: Budgets and Process

New plugins, larger images and additional tracking tags gradually worsen the numbers. That is why performance needs a fixed routine:

1. Rank templates by traffic and business relevance: home page, service or product pages and landing pages first, rarely used subpages later.
2. Set budgets per template: bundle size, image weight, number of third-party scripts, Lighthouse values as an early warning.
3. Check budgets in the build pipeline so overruns are noticed before release – more in the article DevOps and GitOps pipelines.
4. Check field data regularly and measure before and after larger releases.
5. Include performance in the definition of done and release notes, like security updates.

Lever	Effort (guideline)	Mainly affects
Optimize and prioritize the hero image	low	LCP
Set dimensions for images and embeds	low	CLS
Enable page and server cache	low to medium	LCP
Preload fonts and match the fallback font	low to medium	CLS, LCP
Reduce or defer third-party scripts	medium	INP, LCP
Split JavaScript, reduce hydration	medium to high	INP
Change hosting or architecture	high	LCP, INP

Practical Example: Service Pages of a Service Provider

Suppose a service provider with a WordPress website sees in Search Console that mobile service pages fail on LCP and CLS. The analysis shows typical causes: the hero image sits as a CSS background in a slider and is lazy-loaded by a plugin, the consent banner pushes the text down, and the chat widget loads on every page. An optimization cycle over four weeks then looks like this:

1. Week 1 – baseline: record CrUX data, Lighthouse values and server timing of the most important templates.
2. Weeks 2 to 3 – optimization: serve the hero image as img with high priority and exclude it from lazy loading, reserve space for the banner, load the chat only after interaction.
3. Week 4 – re-measurement: comparison with the baseline and documentation including before-and-after screenshots.

The goal: LCP at the 75th percentile under 2.5 seconds – without bending the marketing tracking. Especially with consent banners and analytics tools, solutions are needed that balance privacy, measurability and speed. In the field data, the success shows only gradually because of the 28-day window.

Typical Mistakes and Checklist

Typical mistakes

• Chasing the perfect Lighthouse score on the home page while the most visited subpages are ignored
• Measuring optimizations only in the lab; in live operation the tag manager loads additional scripts
• lazy-loading the LCP image or inserting it only via script
• adding cookie banner, chat or tracking afterwards without measuring again

Checklist for fast pages

• Check field data in Search Console regularly, mobile and desktop separately.
• Hero image optimized, embedded in the HTML and with high load priority.
• Fixed dimensions for images, videos and embeds.
• Critical fonts preloaded, fallback font matched.
• Third-party scripts reduced to what is necessary and loaded after consent or interaction.
• Performance budgets stored in the pipeline.
• Before-and-after measurement for every larger release.

How Nano Concepts Supports You

We first record field data, Lighthouse values and server timing of your most important templates, implement the measures and prove the effect with re-measurement – as part of page speed optimization or as part of technical SEO and relaunch. Nano Concepts handles development; design and online marketing we deliver together with our partner agency LOMA DESIGN. In the free initial consultation we clarify where your site stands and which levers pay off first.