How to Improve Core Web Vitals

A speed test used to give one score, and the industry sold one-score fixes. Then Google replaced it with three measurements, each named with an acronym, and most owners stopped reading at the acronyms.

That is a shame, because the three are the questions a customer would ask in plain words. How long until I can see the thing? Does it answer when I tap it? Did it just jump out from under my thumb? Google calls them Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, measures them on real visitors, and counts them in ranking. The how fast should a website load guide covers why speed matters and how Google uses it. This one is the repair manual: what each metric means, what breaks it, and what to do, split by whether you need a developer.

One thing before starting. Google grades on the 75th percentile of real visits, so the site has to be good for three visitors out of four, including the ones on old phones with two bars. A site that is fast at your desk can fail all three.

Largest Contentful Paint is the time from the tap on your link until the largest element in the first screen, usually a hero photo or the headline block, has finished drawing. Good is 2.5 seconds or less. It is the metric most business sites fail, for a short list of reasons.

A big image. The largest element is usually a photo, and the photo is usually too large; a 4-megabyte hero takes seconds on cellular no matter what else is right. A slow server. A second before the first byte is a second added to everything. Render-blocking code. Stylesheets and scripts the browser must download before it draws anything. Lazy-loading the hero. A well-meaning plugin sets every image to load lazily, including the one at the top. Fonts. The headline cannot paint until the custom font arrives.

Interaction to Next Paint measures how long the page takes to respond visibly after a tap, click or keystroke. Good is 200 milliseconds or less. It replaced a gentler metric in 2024 and is stricter, because it counts every interaction in the visit, not only the first.

INP is the scripts metric. A page feels dead to the touch when the phone is busy running code: a chat widget starting up, a slider calculating, an analytics tag batching events, a builder's framework wiring up every box. Tap the menu during that and nothing happens for half a second. On a laptop the same code runs in a tenth of the time, which is why owners rarely notice.

The usual causes: too many plugins and scripts, each doing a little work on every tap; heavy embeds such as maps, social feeds and chat tools; menus and forms built with more code than they need; and a builder that renders the page through layers of its own JavaScript.

Cumulative Layout Shift measures how much visible content moves while the page loads. Good is 0.1 or less. It is the metric behind an experience everyone has had: you go to tap a button, a banner loads above it, the button moves, and you tap an ad instead.

CLS is a discipline metric more than a speed one. It comes from things inserted into the page without space reserved for them: images with no width and height set, so the text jumps down when the photo arrives; banners, cookie notices and announcement bars injected at the top after the content has drawn; custom fonts that reflow every line because they are a different size than the fallback; embeds that start at zero height and expand; content dropped in late by a script above what the visitor is reading.

Print this and hand it to whoever works on the site. If they recognize every row, you are in good hands; if they reach for a plugin, you are not.

Website speed optimization is sold as a mystery so it can be sold as a package. Much of it is not mysterious. Here is the honest split.

Do the first list before paying for the second. Owners who work through it commonly move LCP out of the red on their own. The how to improve an old website guide puts these steps beside the other repairs an aging site needs. What remains is quoted as a fixed-price speed fix after a free audit says which items apply.

Every platform has a floor. On a lean coded site it is near zero: the page arrives finished, the phone has little to run, and all three vitals sit in the green by default. On a WordPress site with a page builder the floor is higher, because the builder's framework, the theme's styles and the plugins all run on every visit. Trimming gets a builder site into the green on LCP and CLS with effort. INP often will not move, because the builder is the script.

We see this most on sites optimized more than once. Each pass helps; each update erodes it. At that point there are two honest options: WordPress optimization with ongoing maintenance, which holds a builder site at a respectable score for a monthly fee, or a rebuild on a platform without the floor. The WordPress to Next.js page explains what that involves, and the WordPress versus Next.js guide explains the difference without the sales pitch. Both are legitimate. A third optimization pass sold as if it were the first is not.

Speed pays for what it does downstream: visitors who stay, taps that work, forms that get finished. Once the page is fast on a phone, the mobile design best practices guide covers what to do with it.