The short answer: the main content of the page should show up within 2.5 seconds, the page should respond to a tap within 200 milliseconds, and nothing should jump around while someone is reading. Those are Google's Core Web Vitals targets, and they're the same in early 2026 as they were in 2024. What counts is how the site does on phones, for real visitors, not on the laptop in your office.
The three numbers
| What it measures | Name | "Good" target |
|---|---|---|
| how fast the largest element shows up (usually the top image or heading) | LCP | 2.5 seconds or less |
| how fast the page reacts after a tap or click | INP | 200 ms or less |
| how much things move around on screen while loading | CLS | 0.1 or less |
INP replaced the old FID metric on March 12, 2024. If you're reading an older guide that talks about FID, it's out of date. We covered the change in detail when it was announced.
"Good" for 75 out of 100 visits
Here's a detail few people know: Google doesn't look at your fastest visit, or at the average. It looks at the 75th percentile, which means the target has to be met for at least three visits out of four. Mobile and desktop are counted separately. A page passes only if all three numbers are good.
That changes how you test. On office Wi-Fi, on a new phone, almost any site feels fast. The customer looking up your hours from a parking lot, on mobile data and a four-year-old phone, is the one who counts at the 75th percentile.
Does Google care?
Google says it highly recommends good Core Web Vitals for success with Search, and that they line up with what its core ranking systems seek to reward. It doesn't say a fast site automatically beats a slower one with better content. In practice, speed alone won't put you on page one, but a slow site loses people before they see what you sell.
What usually slows a site down
On the small business sites we look at, the causes are almost always the same:
- the big top image, uploaded straight from a phone or camera without resizing or compression;
- a slow server: as a rough guide, Google suggests getting the first byte back within 0.8 seconds (TTFB), even though it isn't one of the three official metrics;
- third-party scripts: chat, maps, ad pixels, review widgets, all loading on the home page;
- too many fonts, each in four weights;
- banners and pop-ups that appear after load and push the text down (that's what hurts CLS).
We've written a practical piece on each of these, for example on images, fonts and scripts on mobile.
How to check in five minutes
- Open PageSpeed Insights and enter your home page URL.
- Look first at the real-user data section, on mobile. If the site gets enough traffic, it tells you whether you pass.
- Only then look at the lab test and the list of suggestions.
- Repeat for your second most visited page (usually the menu, services or contact page).
- Write the numbers down. Compare them a month later, after you change something.
When we build a site, we test it against these targets before handing it over; see what that includes on our services page.
Sources
- Web Vitals, web.devthe LCP 2.5 s, INP 200 ms and CLS 0.1 targets, the 75th percentile, mobile and desktop counted separately, passing only with all three
- Interaction to Next Paint becomes a Core Web Vital on March 12, web.devINP replacing FID on March 12, 2024
- Understanding Core Web Vitals and Google search results, Google Search Centralwhat Google says about Core Web Vitals and ranking
- Time to First Byte (TTFB), web.devthe 0.8 second guideline and TTFB not being a Core Web Vital
Checked: surse Xenia Pușcașu · editare Nora Vlăsceanu · SEO Mihnea Tăbăcaru






