Fast pages rank better. Know which ones are slow.

Core Web Vitals are three metrics that describe how a page feels to a visitor:

• Largest Contentful Paint (LCP): how long until the main content, usually the hero image or the first block of text, is visible. Good: 2.5 s or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps, clicks or types. Good: 200 ms or less. INP replaced First Input Delay in March 2024.
• Cumulative Layout Shift (CLS): how much the content jumps around while it loads. Good: 0.1 or less.

The Core Web Vitals test that counts is the one Google runs on real visitors: it looks at the 75th percentile of visits over the last 28 days, separately for mobile and desktop. A page passes when all three metrics are good at that percentile, which means most of your visitors, not just the lucky ones on fast Wi-Fi, had a good experience.

“How many seconds should my page take to load?” has no single answer, because a page is never loaded at one moment: the first bytes arrive, then the main content, then images further down, then scripts that make it interactive. The Core Web Vitals thresholds split that question into parts that match what visitors notice:

• Server response (TTFB): under 0.8 seconds. Not a Core Web Vital, but everything else waits for it.
• Main content visible (LCP): within 2.5 seconds.
• Reaction to a tap or click (INP): within 200 milliseconds.
• Layout stays put (CLS): a shift of 0.1 or less.

Aim for those on mobile first, for at least three out of four real visits. A page that meets them feels fast to almost everyone, whatever its lab score says.

A website speed test such as Google’s PageSpeed Insights loads your page once, on a simulated mid-range phone with a throttled connection. That is lab data: repeatable enough to debug, but one visit in artificial conditions. The Chrome UX Report collects field data from real Chrome users who opted in, and that is what Google uses.

The two often disagree. A page can score 60 in the lab and pass Core Web Vitals in the field because most visitors use fast phones, or the other way round. Lab tests also cannot measure INP, since nobody interacts with the page; Total Blocking Time is the closest lab stand-in.

LCP is the slowest vital on most sites. Work through the loading chain in order:

1. 1Cut server response time: cache HTML where you can and keep the time to first byte well under a second.
2. 2Make the LCP element small and early: serve the hero image in AVIF or WebP at the size it is displayed, and do not lazy-load it.
3. 3Remove render-blocking resources: inline the critical CSS and defer scripts that are not needed for the first view.
4. 4Avoid rendering the main content in JavaScript when the server could send it as HTML.

INP: keep the main thread free

Slow interactions almost always mean too much JavaScript running at the wrong time. Remove unused scripts, load third-party tags such as chat widgets and trackers later, break long tasks into smaller ones, and avoid heavy work in click handlers. Fewer, lighter scripts help INP more than any single trick.

CLS: reserve the space

Give every image and video width and height attributes, reserve space for banners, ads and embeds before they load, and load web fonts so the fallback has similar dimensions. Content inserted above what the visitor is already reading is the classic cause of a bad CLS.

Speed problems usually live in templates, not individual pages. Test one or two pages of every template: the home page, a category, a product, an article, a landing page. Then fix the templates that carry the most search traffic, which you can read from Google Search Console clicks.

A slow page that nobody visits can wait; a slow product template that brings half of your organic revenue cannot. The Site Audit ranks slow pages together with broken links and indexing problems by the traffic they carry, so speed work competes fairly with everything else.

Speed regresses quietly: a new tracking tag, a larger hero image or a plugin update can undo months of work. Real-user data takes weeks to reflect a change, so by the time a one-off test shows a problem, visitors have felt it for a while. A weekly routine catches it early:

• Re-test your key pages on mobile and desktop every week.
• Watch the 28-day field data of the site and of each key page, and get an alert when a vital turns poor.
• Compare your real-user vitals with your competitors’, since that is the field you are ranked against.
• Check the weekly trend after every release.

Aseoma does all four. It picks your key pages from Search Console clicks and your latest audit, tests them every week with PageSpeed Insights, keeps the Chrome UX Report history of the site and of each page, puts up to five competitors next to you and alerts you when a vital turns poor. Start with the free SEO audit, or see the plans.