Core Web Vitals for business websites: what to fix first

Fix Largest Contentful Paint first, which on most business sites means the hero image, then layout shift, then responsiveness. Google's targets, judged at the 75th percentile of real visits, are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Measure before you change anything.

What are Core Web Vitals, and what counts as good?

They are three measurements of how a page feels to a real visitor. Google's web.dev guidance, as of November 2026, sets the targets below. A page passes when it meets all three at the 75th percentile of page loads, segmented across mobile and desktop.

Metric	What it measures	Good
Largest Contentful Paint (LCP)	How fast the main content appears	2.5 seconds or less
Interaction to Next Paint (INP)	How fast the page responds to taps and clicks	200 milliseconds or less
Cumulative Layout Shift (CLS)	How much the layout jumps while loading	0.1 or less

The 75th percentile matters. It means three in four visits must meet the target, so one fast test on your own laptop proves little. INP replaced the older First Input Delay as the responsiveness measure, so any advice that still talks about FID is out of date. Sources: Google's Web Vitals overview, LCP, INP and CLS.

Do Core Web Vitals affect Google rankings?

Modestly. Google's Search Central documentation says it highly recommends site owners achieve good Core Web Vitals for success in Search. Its page experience guidance is more measured: Google always seeks to show the most relevant content, even if the page experience is sub-par, but for many queries there is a lot of helpful content, and a great page experience can contribute to success in those cases (both pages checked November 2026).

Our reading is that a slow site will not rescue weak content and a fast site will not rescue irrelevant content, but between two similar pages the better experience helps. The bigger reason to fix them is that a page that jumps or lags loses visitors before they reach your enquiry form. See Google's page experience guidance and its Core Web Vitals page.

How do you measure them without guessing?

Use real-user data first and lab tests second.

• PageSpeed Insights shows field data from the Chrome User Experience Report over the previous 28-day collection period, plus a lab test for diagnosis. Field data tells you whether there is a problem; the lab test tells you where. A page with too little traffic may show no field data at all (PageSpeed Insights documentation).
• Search Console groups your URLs by status, so you can see which templates fail rather than testing one page at a time.
• Which pages to test: the homepage, your main service page, the contact page and your most-visited blog post. Fix the worst offender first, because one template usually drives many URLs.

Write down the three numbers before you start. Without a baseline you cannot tell whether a change helped.

What should you fix first?

Fix whichever metric is failing. If more than one is, our suggested order is LCP, then CLS, then INP, because the first two usually have the cheapest fixes.

1. LCP: make the biggest thing on the page arrive sooner. On most business sites the largest element is the hero image or a big heading. Google's LCP optimisation guide breaks the delay into time to first byte, resource load delay, resource load duration and render delay. The practical fixes:

• Resize and compress the hero image to the size it is actually displayed at.
• Do not lazy-load the hero image, and set fetchpriority="high" on the image likely to be the LCP element, as the guide recommends.
• If time to first byte is slow, look at hosting and caching, because a slow server makes a 2.5-second LCP hard to reach.

2. CLS: stop things moving. Google's CLS guidance says to always include width and height attributes on images and video, or reserve the space with CSS aspect-ratio, so the browser can allocate room while they load. Late-loading banners, cookie notices and embedded widgets that push content down cause the same problem.

3. INP: reduce what blocks the page. Long tasks on the main thread delay the page's response to a tap or click, and Google's INP optimisation guidance points at script evaluation during startup. In our view, the usual suspects are third-party tags: chat widgets, analytics, heatmaps and ad pixels. Remove any you do not use, and load the rest after the page is usable.

Which fixes are quick, and which need a developer?

This is our own rule of thumb, not a measured benchmark.

Fix	Typical owner	Effort
Resize and compress the hero image	Anyone who edits the site	Under an hour
Remove unused plugins and tracking tags	Site owner with a developer's check	An hour or two
Add image dimensions across templates	Developer	A few hours
Defer or replace heavy third-party scripts	Developer	Half a day to a day
Fix slow server response or caching	Developer or host	Varies; may mean changing host
Rebuild templates that shift or lag by design	Developer	Part of a redesign

If most of your failing items land in the last two rows, you are not tuning a site, you are fixing a platform.

When is the platform the problem?

When fixes keep being undone by the tools you edit with. Page builders that ship large scripts, themes that load fonts and sliders on every page, and plugin stacks that grew over years are hard to speed up without removing what the business relies on. At that point a rebuild is often cheaper than endless tuning, and it is worth pricing alongside the alternative: our guides to what a website redesign costs in the UK and what a business website costs in 2026 set out the ranges. If you are weighing a modern framework, why we build business sites on Next.js explains what it does and does not do for speed. And if you are choosing who does the work, ask each agency to show real-user Core Web Vitals for sites they have built, as set out in our guide to choosing a web development agency.

How do you stop the scores slipping back?

Re-measure after every release that touches templates, images or tags, and at least monthly. Scores rarely decay by themselves; they slip when someone uploads an uncompressed banner or adds a marketing tag. Make "check the three numbers" part of the release checklist, keep a short list of approved third-party scripts, and review it each quarter.

What to do next

Run your homepage and main service page through PageSpeed Insights today and record the three numbers. If all pass, leave them alone and spend the time on content. If one fails, fix that metric using the order above. If the fixes are blocked by the platform, talk to us about website design and development across our web practice, or tell us about your site.

Frequently asked questions

What are Core Web Vitals in plain English?

Three measurements of how a page feels to a real visitor: how quickly the main content appears (Largest Contentful Paint), how quickly the page reacts when someone taps or clicks (Interaction to Next Paint), and how much the layout jumps around while loading (Cumulative Layout Shift). Google publishes a target for each, and a page passes when it meets all three for most of its visitors.

Do Core Web Vitals affect Google rankings?

A little, and mainly as a tiebreaker. Google says it highly recommends good Core Web Vitals for success in Search, but also that it always seeks to show the most relevant content, even if the page experience is sub-par. Where many pages answer a query equally well, a better experience can contribute. Treat it as a quality floor, not a growth lever.

Why does PageSpeed Insights say there is no field data for my page?

Field data comes from real Chrome users over a rolling 28-day period, and a page needs enough visits to be included. A new or low-traffic page may not qualify. Test your busiest pages instead, and use the lab results as a guide to fixes while you wait for real-user data to build up.

Do I need a developer to fix Core Web Vitals?

For some fixes, no. Resizing a huge hero image or removing an unused chat widget is often a settings change. Fixes to scripts, fonts, page templates and server response need a developer. If your platform limits what can be changed, that is a sign to look at the platform itself.

How often should I check them?

After every release that changes templates, images or tracking tags, and at least once a month otherwise. Core Web Vitals usually slip because someone added a script or a bigger image, not because the code decayed.

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.