Core Web Vitals Explained, and Which One to Fix First

Core Web Vitals are three measurements Google takes of how your page behaves for real visitors: how fast the main content appears, how quickly the page answers a tap or a click, and how much the layout jumps around while it loads. Fix the first one first. Loading speed is the metric a hosting decision can actually move, and it is the one most small business sites fail.

The other two are usually not hosting problems at all, which is worth knowing before you spend money trying to buy your way out of them.

What the Three Metrics Measure

Each one has a name, an abbreviation, and a threshold. The thresholds below are the ones Google publishes on web.dev, and they are assessed at the 75th percentile of real page visits.

LCP times the largest single element in the visible area. On most business sites that is a banner photo or an H1. It is not the moment the page finishes loading, and it is not the moment the first pixel appears. It is the moment the reader can tell what the page is about.

INP replaced First Input Delay, and the change made the metric much harder to pass. FID measured only the delay before the browser started handling your first interaction. INP watches every interaction on the page and reports the worst of them, including the time spent running your code and painting the result. A site with a heavy cookie banner and four tracking scripts feels sticky, and INP now says so.

CLS measures movement. Nobody tracks how far things moved in pixels; the score is a unitless product of how much of the screen shifted and how far it went. A single ad slot that loads late and pushes the article down by 200 pixels can fail the whole page on its own.

None of the three measures your server response time directly. Time to First Byte was never added to the set. It is, however, the first slice of LCP, which is exactly why hosting matters here and does not matter for the other two.

Why Your Local Test Passes and the Report Says You Fail

This is the part that costs people the most confusion. Run Lighthouse in your browser, get a green 96, then open Search Console and find the same page flagged as needing improvement. Both numbers are correct. They are measuring different things.

Lab data is a single simulated load on your machine and your connection, usually with browser extensions disabled and a cold cache, throttled to approximate a mid-range phone on a slow network rather than measured on one. It is repeatable and diagnostic. You change one thing, run it again, and see whether the change helped.

Field data is what actually happened to real Chrome users over the previous 28 days, collected into the Chrome User Experience Report. Search Console shows you field data. So does the "Discover what your real users are experiencing" panel at the top of a PageSpeed Insights report. The score is the 75th percentile, meaning three quarters of visits were at least that good and a quarter were worse.

That percentile is why a fast site can still fail. Your visitors are not all sitting on fiber in the same city as your server. Some are on a four-year-old Android phone on a congested mobile network at a soccer game. If a quarter of your traffic loads slowly, the fast three quarters do not rescue the score.

One more trap: Lighthouse cannot measure INP at all. There is no user to interact with the page in a synthetic test, so the lab report substitutes Total Blocking Time as a stand-in. A perfect TBT and a failing INP happen together often enough that it is worth checking the field panel before you conclude anything about interactivity.

Low-traffic pages get rolled up into an origin-level score for the whole site, so small sites often see one number covering everything. Fix site-wide causes, not page-by-page symptoms.

Fix LCP First

It is the metric most small sites fail, and the only one where infrastructure genuinely helps. It also degrades along the axis you cannot see from your own desk, which is distance and device quality.

A failing LCP breaks down into four pieces: the wait for the first byte, the delay before the browser discovers the image it needs, the time spent downloading that image, and the gap between the download finishing and the pixel appearing. Google's guidance on time to first byte puts the good threshold at 0.8 seconds. Blow through that and you have spent a third of your entire LCP budget before the browser has seen a single tag of your HTML.

Where it goes wrong on shared hosting is not usually raw CPU. It is queueing. Your PHP process waits behind other work on the same machine, the database query that builds the page takes longer than it should under load, and the visitor sees a blank screen the entire time. That is a server-side problem with a server-side fix, and no amount of image compression touches it. Our post on the signs a site has outgrown shared hosting covers what that queueing looks like from the outside, which is the diagnosis you want before you buy anything.

The client-side half of LCP is easier and free. Serve the hero image in a modern format at the size it will actually be displayed, and stop lazy loading it. Lazy loading the largest element in the viewport is the single most common self-inflicted LCP wound on WordPress sites, because a plugin applied loading="lazy" to every image on the page including the one above the fold. Set fetchpriority="high" on that image instead.

CLS Is the Cheapest Point You Will Ever Earn

Most layout shift comes from four things: images without width and height attributes, ads or embeds injected into a container with no reserved height, web fonts swapping in at a different size than the fallback, and content inserted above existing content after load.

The fix for the first is dull and effective. Put width and height back on every <img> tag. Browsers compute the aspect ratio from those attributes and reserve the space before the file arrives, so nothing below it moves when it lands. Keeping height: auto in your stylesheet does not undo that, contrary to advice still floating around from a decade ago.

Fonts are the awkward one. Setting font-display: swap stops the invisible-text period but trades it for a shift when the real font arrives; adding size-adjust to the fallback family closes most of the gap.

I would spend an hour on CLS before spending a day on INP, because the work is mechanical and the result is permanent. INP fixes tend to unravel the next time somebody adds a marketing script.

Should You Bother With INP?

Often, no. Nothing about your hosting plan changes how long a script takes to run on a visitor's phone, because that work happens on their processor while competing with every other tab they left open. Buying a bigger server does nothing for it.

So the fix list is short, and it is all deletion. Start with tracking scripts whose reports you no longer read, then look hard at any chat widget that ships its entire bundle on every page view when it could load on click. Consent banners are the other repeat offender, because many of them block the main thread while deciding what to show. On WordPress specifically, the plugin count matters far more than the theme, and an analytics suite you installed once and never opened is pure cost.

There is a real caveat here rather than a general one. If your site is a brochure with a contact form and no interactive components, INP will likely pass without you doing anything, and time spent on it is wasted. Check the field data first and only work on it if it is failing.

Stop Chasing a Perfect Score

The thresholds are pass or fail. A page at 2.4 seconds counts exactly the same as a page at 1.1 seconds, and the work required to get from the first to the second is enormous next to the work of getting from 4.2 down to 2.4.

Google's own page experience documentation says as much, in the polite way documentation says things: it describes these signals as one input among many and states plainly that great content still wins against a faster page with less to say. Treat vitals as a tiebreaker. An afternoon spent turning a 92 into a 99 is an afternoon not spent writing the page that would have earned the traffic in the first place.

Get every page into the green band. Then leave it alone and check quarterly.

Where Hosting Moves the Numbers, and Where It Does Not

Three hosting levers are real for LCP, and two of them are free. The first is where the server sits. A visitor in Sydney hitting a server in Chicago pays a round-trip penalty on every request that no software fixes, so picking a data center region near your actual audience is worth more than most optimization plugins. The second is caching, so that a repeat page view is served from memory rather than rebuilt from the database each time. Hepsia includes server-side accelerators for that layer.

The third lever, and the expensive one, is more capacity. If your response times climb during your busiest hours and fall back overnight, you are queueing behind your neighbors and semi-dedicated hosting or a VPS is the honest answer. If your response times are equally bad at three in the morning, the problem is your code or your database, and moving it to a faster machine just makes the same bad query finish slightly sooner.

Your Next Half Hour

Open PageSpeed Insights, put in your homepage, and read only the field data panel at the top. Ignore the score wheel underneath it. That part is lab data, and it is the number that has been telling you everything is fine.

A red LCP means finding out whether the delay is server time or image time before you change one other thing, because those two have completely different fixes and guessing wrong wastes a weekend. Red CLS means putting dimensions back on your images this week. Red INP sends you to your JavaScript with a list of things to delete.

If nothing is red, you are done. Go write something.