Core Web Vitals 2026: A Practical Fix List for Slow Sites

Most slow sites are not slow because of the framework. They are slow because of a hero image, an ad script and a font that loads three times before the headline appears.

Measure the right thing first

Core Web Vitals are three numbers, and each one answers a different question. Largest Contentful Paint asks how long until the main content appears. Interaction to Next Paint asks how quickly the page reacts when someone taps. Cumulative Layout Shift asks how much the page jumps around while it loads. A site can score well on one and badly on the others, which is why a single green badge tells you very little.

Start with real-user data, not a lab score. Field data shows what your visitors actually experience on their phones and networks. The lab tools are useful for debugging, but they run on a fast connection with a clean cache. Optimising only for the lab is how teams end up with a perfect score and a site that still feels slow.

LCP: fix the hero, then the fonts

The largest element is usually the hero image or the headline. If it is an image, serve the right size, use a modern format and do not lazy-load it. A preload hint for the hero can help, but only when the image is genuinely the first thing you want. Preloading everything is the same as preloading nothing.

Fonts are the second common cause. A custom font that blocks the headline can delay the largest paint by a second or more. Use font-display swap, subset the font, and host it yourself if the third-party font service is slow in your region. If the brand can live with a system font, use one and be faster than everyone else.

INP: the script you forgot about

Interaction to Next Paint is the metric most sites ignore and the one users feel. A page that loads in a second but freezes for 400 milliseconds when you tap a menu is a bad page. The usual cause is a long JavaScript task, often from a tag manager, a chat widget, an analytics bundle or a heatmap recorder.

Audit the third parties before you rewrite components. Load chat and analytics after the page is interactive, defer what can be deferred, and remove what nobody uses. A small bundle that does less will beat a clever optimisation of a large one. If a script is not paying for itself in a measurable way, delete it.

A perfect lab score on a fast connection is not a performance strategy. Your customers are on a train.

CLS: reserve the space

Layout shift is mostly a design discipline problem. Set width and height on images, reserve space for embeds and ads, and avoid injecting banners above content after load. If a cookie notice pushes the page down, give it a fixed slot instead of letting it reflow the article.

Web fonts can also shift text when the fallback is replaced. Match the fallback metrics or accept a small trade-off. The goal is not zero movement for its own sake; it is that nothing moves under the reader's thumb while they are trying to tap.

A fix list you can work through

Work in order of impact and effort. First, shrink and prioritise the hero. Second, remove or defer third-party scripts. Third, fix image dimensions and font loading. Fourth, revisit the JavaScript that runs on first interaction. Most sites see a meaningful gain before they touch the framework.

• Compress and resize the hero image for mobile and desktop separately.
• Preload only the hero and the primary font, nothing else.
• Load chat, ads and analytics after the main content is interactive.
• Set explicit dimensions on images, video and embeds.
• Re-measure with field data two weeks later, not the same afternoon.

What not to do

Do not chase a perfect score by hiding content or delaying the metric. Do not add a performance framework that costs more than the problem. And do not optimise the homepage while the article template, where most readers land, stays slow. Check the pages that actually get traffic.

Performance is a maintenance habit, not a project. Every new script and every new image is a chance to undo the last round of work. Put the numbers on a dashboard, review them monthly, and give someone the authority to say no to a tag.