A slow first paint, sluggish taps and content that jumps around while loading all show up in the same place: Core Web Vitals. This guide explains how to improve Core Web Vitals metric by metric, moving from measurement to diagnosis to fixes that hold up in real-world data.
What Core Web Vitals measure
Core Web Vitals are three metrics Google uses to describe real user experience: LCP for loading, INP for responsiveness and CLS for visual stability. INP replaced FID in 2024 and considers interactions across the whole page visit, not just the first one. Scores are assessed at the 75th percentile of visits.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5–4 s | > 4 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Measure first: field data vs lab data
Field data comes from real Chrome users (CrUX) and is what Google evaluates. Lab data comes from tools like Lighthouse in a controlled environment and is best for debugging.
- PageSpeed Insights shows both for a single URL.
- The Core Web Vitals report in Search Console groups problem URLs across the site.
- The Chrome DevTools Performance panel reveals which scripts block the main thread.
- Adding your own real user monitoring fills gaps on lower-traffic pages.
Group pages by template rather than checking them one by one. Product, category, blog and landing pages usually share components, so fixing one template improves every page that uses it. Prioritise the templates that carry the most traffic.
A high Lighthouse score does not guarantee good field data, and INP in particular needs real interactions to measure.
How to improve LCP
Break LCP into four parts: server response time, resource discovery delay, download time and render delay.
- Speed up the server: static generation, caching and a CDN reduce TTFB.
- Make the LCP image discoverable early: use a plain img tag in the HTML, set a high fetch priority and never lazy-load it.
- Shrink the file: serve AVIF or WebP at the right size with srcset.
- Cut render-blocking resources: inline critical CSS and defer non-essential third-party scripts.
How to improve INP
Poor INP almost always comes from long JavaScript tasks keeping the main thread busy.
- Split tasks longer than 50 ms and yield back to the browser between chunks.
- Show visual feedback first in event handlers and defer heavy work.
- Ship less JavaScript: remove unused libraries, code-split, and render on the server where possible.
- Audit third-party tags such as analytics, chat widgets and ad scripts.
- Virtualise very long lists to keep the DOM small.
How to improve CLS
- Give every image, video and iframe explicit dimensions or an aspect-ratio.
- Reserve space for ads, banners and cookie notices instead of injecting them above content.
- Tune font-display and fallback font metrics to reduce text reflow.
- Animate with transform rather than layout properties like top or left.
Most of these decisions are made in design. A UI/UX design process that defines component sizes and loading states up front prevents layout shift before any code is written.
Common Core Web Vitals mistakes
- Optimising only the homepage: Google groups similar pages. If product, category or blog templates carry most traffic, that is where the work is.
- Testing only on desktop: phones have slower CPUs and less stable connections, so problems usually appear there first.
- Chasing the score: tricks that raise a Lighthouse number without helping real users are risky and do nothing for field data.
- Lazy-loading everything: deferring the above-the-fold hero image makes LCP worse.
- Unmanaged third-party tags: each script added through a tag manager can create an INP problem developers never see. A lightweight performance check in the tag approval process helps.
What these share is a gap between the change and real user data. Do not call a fix done until field data confirms it.
Keeping the gains
New features, scripts and campaign pages can undo your work. Set a performance budget, add Lighthouse checks to CI and watch field data regularly. Because field data uses a rolling 28-day window, improvements take a few weeks to show in reports. Framework-specific tips are in our Next.js SEO and performance guide.
At BernSoftware we treat performance as part of the architecture rather than a late fix. Explore our web development services or contact us to review your Core Web Vitals together.
Frequently asked questions
How much do Core Web Vitals affect rankings?
Google says page experience is considered by its ranking systems, but relevant and helpful content matters far more. The bigger payoff from better Core Web Vitals is usually user experience and conversions.
Why is my Lighthouse score high while Search Console reports problems?
Lighthouse runs one lab test under fixed conditions. Search Console uses real user data from many devices and networks, which can reveal slow devices and interaction issues a lab test misses.
How long until fixes show up in Search Console?
Field data is aggregated over 28 days, so it usually takes a few weeks for improvements to be fully reflected.
Planning a project like this?
Plan it in 10 steps