Core Web Vitals for business websites: what actually matters in 2026
Core Web Vitals are three field-measured numbers: loading (LCP within 2.5 seconds), responsiveness (INP within 200 milliseconds) and visual stability (CLS below 0.1), judged for real visitors at the 75th percentile. They rarely win rankings alone, but failing them quietly loses visitors, conversions and crawl budget all at once.
Three numbers, in plain language
Google measures the experience of your real visitors and summarises it as three metrics. Core Web Vitals pass or fail at the 75th percentile, which means the question is not "was it fast for someone" but "was it fast for three out of four of the actual people who came".
LCP, Largest Contentful Paint, within 2.5 seconds. How long before the main thing on the page (usually your headline image or heading block) is visibly there. This is the metric visitors would recognise as "the site loading".
INP, Interaction to Next Paint, within 200 milliseconds. When someone taps a menu, a filter or a button, how long before the screen visibly responds. INP replaced the older FID metric in 2024 and it is far stricter, because it watches every interaction on the page, not just the first. Script-heavy sites fail here most.
CLS, Cumulative Layout Shift, below 0.1. How much the page jumps around while loading: the ad that shoves the paragraph down just as you tap, the font swap that reflows everything. Visitors experience it as clumsiness; the metric just gives it a number.
Field data is the exam; the lab is only revision
This distinction causes more confusion than everything else combined. Tools like PageSpeed Insights show two different things. The lab score is a simulation run on the spot under fixed conditions, useful for diagnosing. The field assessment is aggregated from real Chrome users over the previous 28 days, and it is the only thing Google judges you on.
The gap between them is where Indian businesses get surprised. Your developer tests on fast broadband and a flagship phone; your customers arrive on mid-range Androids over 4G that fluctuates between decent and dreadful. A site that scores 95 in the lab can fail its field assessment comfortably. Test where your buyers live, not where your team works. And note that field data needs traffic: very low-traffic pages may show no field data at all, in which case treat the lab's mobile run, throttled, as your stand-in.
What slow actually costs, in order of pain
The honest hierarchy, because vendors routinely sell it upside down:
- Abandonment comes first. Visitors leave slow pages before anything else gets a chance to matter. Every second added to load time sheds a measurable slice of them, and on mobile connections the slicing is brutal. This loss is invisible in analytics, because the visitor left before the analytics loaded.
- Conversion comes second. The visitors who stay convert less on a sluggish site. Delay and clumsiness read, at some level below argument, as neglect: if the site is this creaky, what is the service like?
- Crawling comes third. Google and the AI retrieval bots allocate finite fetching to your site. A server that answers slowly gets crawled less, which on a large site means pages waiting longer to be indexed or refreshed.
- Rankings come last. A real signal, a light one. Fix speed for the first three reasons and take the fourth as a bonus, not the other way round.
What to fix, in the order that usually pays
Nine times out of ten, a failing business site fails for mundane reasons, and the fixes are the kind nobody shows off in a sales call:
- Hosting and TTFB. If the server takes over half a second to begin responding, everything downstream inherits the delay. Decent hosting and server-side caching come before any front-end heroics.
- Images. The most common LCP killer: a hero image ten times larger than needed. Size images to their display size, serve modern formats, and never lazy-load the main image at the top of the page.
- JavaScript restraint. Every plugin, widget and tracker charges its fee in INP. The question that fixes budgets: what would break if this script were removed? Often the answer is nothing.
- Reserved space. Give images and embeds explicit dimensions so nothing shifts as they arrive. CLS is mostly cured by this one habit.
- Fonts. System fonts, or one well-subsetted font file, loaded so text stays visible during the swap.
The pattern behind all five, and the deeper argument of this whole section: speed is mostly the discipline of not adding things. Which is why the sites that fail worst are often the ones that tried hardest to look impressive, a pattern examined properly in why "SEO-friendly" sites still fail Core Web Vitals.
The site you are reading is the demonstration
SEOtop10 is built the way this article recommends: server-rendered pages, styles inlined, system fonts, no framework, and one small script for the mobile menu. That is a deliberate editorial decision. A publication that lectures about performance should hand you its own numbers rather than its own excuses, so: run this page through PageSpeed Insights or any tool you trust, on mobile, right now. The numbers you see there are the argument, and I do not get to edit them.
Questions founders ask
Do Core Web Vitals directly affect Google rankings?
Modestly. Page experience is a lightweight signal among hundreds, and a fast site will not outrank better content. The real cost of failing is indirect and larger: visitors abandon slow pages before they load, conversion falls with every extra second, and crawlers fetch fewer pages from slow servers.
My PageSpeed Insights score is 95 but the report says I fail Core Web Vitals. How?
The score at the bottom is a lab simulation; the assessment at the top is field data from real Chrome users over 28 days. Real visitors on mid-range phones and patchy 4G are harsher than the lab. Field data is what counts, so fix for it, not for the lab number.
What is a realistic target for an Indian SME website?
Green on all three metrics in field data, on mobile, is achievable for almost any business site without exotic engineering: sensible hosting, optimised images, restrained JavaScript and a theme that was not fighting you to begin with. If a plain content site cannot pass, the build is wrong, not the goal.
Do Core Web Vitals matter for AI visibility too?
Indirectly, yes. AI assistants retrieve pages live while composing answers, and fast, clean pages are easier to fetch and parse. Speed will not earn a citation by itself, but a slow, script-heavy page makes every retrieval less likely to go well.