Core Web Vitals, what to fix first

Core Web Vitals measure how a real page feels to a real visitor: how fast the main content paints, how quickly the page responds to a tap, and whether the layout stays put while it loads. If you run one site the advice is simple enough. If you run twenty, a hundred, or a whole client portfolio, the hard part is not knowing what the metrics mean, it is deciding what to fix first so you spend your hours where they move the numbers. This guide gives you that running order, with the multi-site operator specifically in mind.

The three metrics, in plain English

There are three Core Web Vitals, and each maps to a different kind of pain a visitor feels.

• Largest Contentful Paint (LCP) is how long it takes the biggest visible element (usually a hero image or a headline block) to render. Google wants this at 2.5 seconds or faster at the 75th percentile.
• Interaction to Next Paint (INP) is how quickly the page visibly reacts when someone taps or clicks. The target is 200 milliseconds or less. INP replaced the old First Input Delay in 2024, and it is stricter because it watches every interaction, not just the first.
• Cumulative Layout Shift (CLS) is how much the layout jumps around as things load. The target is 0.1 or less. This is the metric that makes people tap the wrong button when an advert or a late image shoves the page down.

Search Console reports these against field data, meaning the experience of your actual visitors over the trailing 28 days, not a single lab test. That distinction matters later.

The order to fix them in

Do not treat the three as equal work with equal payoff. For most hosting-managed sites the effort-to-result ratio ranks like this.

Start with CLS. Layout shift is almost always caused by a handful of fixable things: images and video without width and height attributes, adverts or embeds injected after load, and web fonts that swap and reflow the text. Adding explicit dimensions and reserving space is a template edit, not an architecture change, and on a page-builder or theme it often fixes CLS across every page at once. Highest payoff, lowest risk, so it goes first.

Then LCP. This is where your hosting actually shows up in the score. LCP has a floor set by how long your server takes to send the first byte (TTFB). If a shared box is overloaded and TTFB is 900 milliseconds before a single pixel paints, no amount of front-end tuning gets you under 2.5 seconds. Compress and correctly size the hero image, serve it in a modern format, preload it, and make sure your server and cache are not the bottleneck.

Finish with INP. Interaction responsiveness is the deepest work because it usually means auditing JavaScript: heavy third-party scripts, chat widgets, analytics stacks, and plugins that block the main thread. It is real engineering, so tackle it once the cheaper wins are banked.

Where hosting genuinely moves the needle, and where it does not

Be honest with yourself about this, because it saves wasted money. Core Web Vitals are overwhelmingly a front-end and content problem. The one metric your server directly influences is LCP, through TTFB. A faster stack, HTML caching, HTTP/2 or HTTP/3, and enough headroom that your site is not queueing behind noisy neighbours all pull TTFB down and give LCP room to hit target. If your sites run on WordPress, a stack tuned for it removes a lot of that server-side latency; that is the practical case for WordPress SEO hosting rather than a generic shared plan.

What hosting does not do is fix CLS or INP for you. Those live in your theme, your images, and your scripts. And to be clear about a related point our audience always asks: a dedicated Class C IP has no effect on Core Web Vitals at all. Its value is defensive, keeping your site off an IP with bad neighbours, and it gives network operators footprint control. It is not a speed feature and it is not a positive ranking signal on its own. Do not expect an IP change to move a Vitals score.

Measure before you touch anything

The single most common mistake is optimising against a lab tool while Google grades you on field data. Lighthouse and similar tools run one simulated load and give you a lab number; useful for finding causes, but it is not your score. Search Console shows the field data that actually counts, aggregated from real visitors over 28 days. Two consequences follow. First, a cold cache or a single slow run can make a page look worse than it is, so never trust one measurement. Second, because field data trails by weeks, your fixes will not show up in the report the same day, so do not panic-edit when the graph has not moved yet.

For the underlying definitions and current thresholds, Google's own reference is the authority worth bookmarking: web.dev on Core Web Vitals.

Doing this across many sites at once

For a single site you fix by hand. For a portfolio you fix by template. This is the leverage that multi-site operators have and single-site owners do not.

• Group sites by shared theme or page builder, then fix the CLS and LCP causes once in the shared template so every site inherits the change.
• Standardise your plugin and script stack across the network. A single bloated widget rolled out everywhere drags INP down on every property; removing it fixes all of them.
• Watch server-level metrics, not just per-page scores. If TTFB is climbing across many sites at once, the cause is the box, not the pages, and that points at capacity rather than code. When one shared server is the shared bottleneck, moving the heavier sites to a dedicated SEO VPS gives them the headroom to keep TTFB low independently.

For more on tuning speed and Vitals across an estate of sites, see the rest of the Performance and Core Web Vitals hub.

A quick running order to keep

1. Confirm the real problem in Search Console field data, not a one-off lab run.
2. Fix CLS first: dimensions on media, reserved space for late content, stable fonts.
3. Fix LCP next: right-sized hero image, and a server and cache that keep TTFB low.
4. Fix INP last: trim and defer the JavaScript that blocks interaction.
5. Wait for field data to catch up, roughly a few weeks, before judging the result.

Fix in that order and you spend the least time for the most improvement, whether you are tending one site or a hundred.