A business website should load its main content in under 2.5 seconds (LCP), respond to user input in under 200 milliseconds (INP), and avoid layout shifts that surprise the visitor (CLS under 0.1). These three Core Web Vitals are Google's standard for a fast, stable, responsive experience, and they affect both search ranking and whether visitors stay long enough to enquire.
Website speed is one of those topics that gets buried in jargon until business owners stop asking about it. But the underlying question is simple and important: does the site appear and respond quickly enough that a visitor stays, or is it slow enough that they leave before reading the offer?
This guide explains Core Web Vitals in plain language, the thresholds that matter, why a site can look fast but still feel slow, and what to fix first. It is written for South African small business owners, not performance engineers.
What Core Web Vitals actually measure
Core Web Vitals are Google’s three standard measurements of how a real user experiences a web page. They are not abstract technical scores; they are proxies for “did this page feel fast and stable to the person using it.”
The three vitals are:
LCP (Largest Contentful Paint)
LCP measures how long it takes for the largest visible element on the screen to appear. This is usually a hero image, a large heading or a video. LCP is the closest thing to “how long did the page take to show me something meaningful.”
Good: under 2.5 seconds. Needs improvement: 2.5 to 4 seconds. Poor: over 4 seconds.
INP (Interaction to Next Paint)
INP measures how quickly the page responds when the visitor taps, clicks or types. A button that takes half a second to react feels broken, even if the page loaded quickly. INP replaced the older FID measurement in 2024.
Good: under 200 milliseconds. Needs improvement: 200 to 500 milliseconds. Poor: over 500 milliseconds.
CLS (Cumulative Layout Shift)
CLS measures how much the page layout jumps around while loading. A classic CLS failure is reading an article, going to click a link, and having an image load above the link at the last moment so you click the wrong thing. CLS captures that frustration.
Good: under 0.1. Needs improvement: 0.1 to 0.25. Poor: over 0.25.
The official web.dev Core Web Vitals reference is the source for these thresholds and the underlying methodology.
Why Core Web Vitals matter for a business website
The vitals matter for two reasons, one of which is often overstated.
They affect search ranking
Google uses Core Web Vitals as one of many ranking signals. A site with poor vitals can rank lower than an equivalent site with good vitals, particularly in competitive queries. This effect is real but bounded; vitals are a tiebreaker among otherwise comparable pages, not a substitute for useful content.
The Google page experience guidance is the primary source on how page experience fits into ranking.
They affect whether visitors stay
The larger effect is on human behaviour. Visitors leave slow pages. A page whose main content takes four seconds to appear loses a meaningful share of mobile visitors before they ever read the offer. A page that jumps while loading causes accidental clicks and erodes trust.
For a business whose goal is enquiries, the conversion cost of slow vitals usually exceeds the search cost. The article on website conversion problems covers how speed interacts with paid traffic in particular.
Why a site can look fast but still feel slow
A common confusion: a site looks fast on the designer’s desktop, but visitors report it feeling slow. Three causes usually explain the gap.
Desktop versus mobile
Designers often test on fast desktop connections. Most South African visitors arrive on mobile networks that are slower and less stable. A page that loads in one second on desktop may take four on a typical mobile connection. Always test vitals on a real phone on a real network.
Lab data versus field data
Lab tools (like a Lighthouse test) simulate a single device and connection. Field data (Chrome’s real-user CrUX data) shows how the page actually performs across real visitors. A page can score well in a lab test and poorly in the field, particularly on mobile.
Load time versus interaction time
A page can load quickly (good LCP) but respond slowly when tapped (poor INP). The site “feels” slow even though the loading bar finished. This is why LCP alone is not enough; all three vitals have to be considered together.
How to check your site’s Core Web Vitals
You do not need to be an engineer to run a basic check. Several free tools give honest readings.
Free tools
- PageSpeed Insights: the simplest starting point. Enter a URL and get both lab and field data for all three vitals, with specific improvement suggestions.
- Google Search Console: shows Core Web Vitals issues across your whole site, based on real-user data.
- Chrome DevTools (Lighthouse tab): for a more detailed lab test during development.
- web.dev Measure: similar to PageSpeed Insights with additional context.
Run PageSpeed Insights first. It is the most accessible and combines lab and field data. The pattern of which vitals fail tells you what to fix.
What to fix first
Improvement work should follow impact, not novelty. Fix the things that move the vitals for real mobile visitors before the things that polish a desktop score.
LCP fixes (highest impact)
- Compress and properly size the largest image on the page.
- Avoid large hero images that load late.
- Reduce server response time.
- Remove render-blocking scripts that delay the first paint.
- Use modern image formats (WebP or AVIF) where supported.
CLS fixes (high impact, often easy)
- Set explicit width and height on every image and embed.
- Reserve space for ads or banners before they load.
- Avoid injecting content above existing content as the page loads.
INP fixes (more technical)
- Reduce the amount of JavaScript that runs on the page.
- Break up long tasks that block the main thread.
- Defer non-essential third-party scripts.
- Avoid heavy third-party widgets, especially on mobile.
The biggest single LCP win for most small business sites is image handling: properly sized, compressed, modern-format images load far faster than the same images at full camera resolution. This one change moves many sites from “poor” to “good” on LCP.
The relationship between platform and performance
The platform a site is built on shapes its performance ceiling. Heavy platforms with many plugins ship more code than the site needs, which hurts INP and LCP. Lightweight or static platforms ship only what is necessary.
The article on whether WordPress is right for your small business website covers the performance implications of the most common platform choice. The short version: WordPress can perform well with careful configuration, but a default WordPress install with many plugins will usually have poorer vitals than a lightweight or custom build.
What good looks like, and what it does not guarantee
A site with all three vitals in the “good” range is a site that feels fast and stable to visitors. That is worth achieving. But good vitals do not, on their own, produce enquiries. They remove a category of friction; they do not create the offer, the copy or the trust that actually converts.
The right framing is: fix poor vitals because they are silently costing you visitors, then focus on the content and conversion work that turns the visitors you keep into customers.
The conclusion
A business website should load its main content in under 2.5 seconds (LCP), respond to input in under 200 milliseconds (INP), and avoid layout shifts (CLS under 0.1). These three Core Web Vitals are Google’s standard for a fast, stable, responsive experience, and they affect both search ranking and whether visitors stay long enough to enquire.
Check your vitals with PageSpeed Insights, fix image handling first (the highest-impact LCP win for most small sites), and remember that good vitals remove friction but do not replace useful content.
If your site is slow on mobile and you want a clear list of what to fix, describe the situation and we will run the vitals check with you and prioritise the work.