To improve Core Web Vitals, start with three usual culprits: oversized images and video, too much JavaScript, and content that jumps as the page loads. Core Web Vitals are three scores Google collects from real Chrome visits and counts among its search signals, so fix them before you spend more on traffic.
The HTTP Archive's 2025 Web Almanac found that only 48% of mobile websites passed all three Core Web Vitals (desktop: 56%). In our own audit of 3,196 local businesses, the median mobile PageSpeed score was 60 out of 100, and a quarter of sites scored under 50.
This guide explains each metric, what breaks it, how to fix it, and a one-week plan. Planning a new site instead? Our business websites service treats Core Web Vitals as a requirement, with server-rendered pages, optimised images and a JavaScript budget for every page.
What are Core Web Vitals? LCP, INP and CLS explained
Each is measured at the 75th percentile of real visits, so three out of four visits need to hit the target.
| Metric | Measures | Good | Mobile sites passing (2025) |
|---|---|---|---|
| LCP, Largest Contentful Paint | How quickly the main content appears | 2.5 seconds or less | 62% |
| INP, Interaction to Next Paint | How quickly the page responds when you tap or type | 200 milliseconds or less | 77% |
| CLS, Cumulative Layout Shift | How much the page jumps around while loading | 0.1 or less | 81% |
What INP means for your site
INP replaced First Input Delay in March 2024. The old metric measured only the first interaction; INP covers the whole visit. Pages that passed the old metric can fail INP, especially JavaScript-heavy ones with chat widgets, trackers and animations.
How to fix LCP (slow main content)
LCP is the hardest metric on mobile. The usual causes:
- Huge images and videos. Usually the first thing to check. In our audit, one homepage loaded a single 50 MB background video, and another weighed 94 MB in Google's mobile test.
- Slow server response. Cheap shared hosting, no caching, or a page built from scratch on every visit.
- Render-blocking resources. Large CSS and JavaScript files the browser must download before it can draw anything.
- The main image loads late, because it's lazy-loaded, set as a CSS background or inserted by JavaScript.
Fixes:
- Serve images in modern formats (WebP or AVIF) at the right size for each screen, using
srcset. -
Never lazy-load the main (above-the-fold) image; give it
fetchpriority="high"instead. - On mobile, replace autoplaying background videos with a poster image or a heavily compressed short loop.
- Add page caching and a CDN, so pages are served from near the visitor.
- Inline the CSS the first screen needs and defer the rest.
How to fix INP (slow response to taps)
INP fails when the browser's main thread is too busy to respond:
- Too much third-party JavaScript: chat widgets, ad scripts, several analytics tags, heatmaps and A/B testing tools, often on every page.
- Long tasks: big chunks of JavaScript running without a break, so a tap waits in the queue.
- Heavy page builders and plugins that ship lots of script.
- Expensive work on every interaction, such as re-rendering a whole page when one field changes.
Fixes:
- Audit third-party scripts. Remove what nobody uses; load chat widgets on interaction or once the page settles.
- Break up long tasks so the browser can respond between them.
- Defer non-essential JavaScript, and ship less of it: often the single biggest win.
- Show visual feedback first (the button press), then do the heavy work.
How to fix CLS (jumping layout)
- Images and videos without dimensions, so no space is reserved before they load.
- Late-loading banners: cookie notices, promo bars and ads that push content down.
- Web fonts swapping in and changing text size.
- Content injected above existing content by scripts.
Fixes:
- Always set
widthandheight(or an aspect ratio) on images, videos and embeds. - Reserve space for banners and ads, or overlay them instead of pushing content. (Overlaid banners must not hide the element a keyboard user is on: see our guide to website accessibility requirements.)
- Use
font-displaysettings and size-matched fallback fonts to reduce shift.
How to measure Core Web Vitals
- PageSpeed Insights (pagespeed.web.dev) shows field data (real Chrome users, given enough traffic) and lab data (a simulated test). Field data is what counts.
- Google Search Console's Core Web Vitals report groups your URLs into good, needs improvement and poor.
- Chrome DevTools' Performance panel shows exactly which scripts and tasks block the page.
Test on a mid-range phone over mobile data, not your office laptop: that's what customers use.
Are Core Web Vitals a ranking factor?
Yes, but not a dominant one. Google is clear that relevant, helpful content matters most: a fast page with weak content won't outrank a slower page that answers the question better. Our guide to AI Overviews and search visibility covers what else matters now.
The stronger argument is commercial. Visitors leave slow pages, mistap jumpy ones and abandon forms that lag. Speed affects whether a visit becomes an enquiry, whatever your ranking.
A one-week plan to improve Core Web Vitals
- Day 1: Run PageSpeed Insights on your homepage, top service page and contact or checkout page. Note which metric fails.
- Day 2: Compress and resize every image over 200 KB; fix the main image's loading.
- Day 3: List every third-party script; remove or delay what you can.
- Day 4: Add dimensions to media and reserve space for banners.
- Day 5: Turn on caching and a CDN if you haven't.
- Days 6 and 7: Re-test. Field data takes about 28 days to fully update, so track the trend in Search Console.
Frequently asked questions
What is a good INP score?
200 milliseconds or less at the 75th percentile of real visits. INP measures how quickly the page responds to taps and typing across the whole visit.
Why does PageSpeed Insights show different numbers from Search Console?
PageSpeed Insights adds lab data (a simulated test) to field data from real Chrome users, when your site has enough traffic. Field data is what counts, so treat lab scores as a debugging aid.
How long do Core Web Vitals take to update after a fix?
About 28 days for field data. Re-test with PageSpeed Insights to check the fix, then track the trend in Search Console's Core Web Vitals report.
The bottom line
Failing Core Web Vitals usually have unglamorous causes: oversized media, too many scripts and layouts that jump. Fix those three first, and the visitors you already have are more likely to become customers.
Want a second opinion on your scores? Book a free consultation with the team behind our business websites and we'll go through your PageSpeed report together.
Sources
- HTTP Archive, Web Almanac 2025, Performance chapter (July 2025 data): https://almanac.httparchive.org/en/2025/performance
- web.dev, Core Web Vitals overview and thresholds: https://web.dev/articles/vitals
- web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
- Google Search Central, Understanding Core Web Vitals and Google search results: https://developers.google.com/search/docs/appearance/core-web-vitals
- ZNova Studio audit of 3,196 local business websites (October 2026): /insights/local-business-website-statistics
Originally published on znovastudio.com.
Top comments (0)