Core Web Vitals explained: why site speed matters for business
Core Web Vitals in plain words — LCP, INP and CLS, why site speed affects sales and SEO, how to test your site for free and what actually makes it slow.
Site speed matters because people don't wait. When a page takes too long to show up, reacts late to a tap or jumps around while loading, visitors leave — often before they've seen your offer. Core Web Vitals are Google's three metrics for exactly these problems: how fast the main content appears, how quickly the page reacts, and how stable it stays. They're part of how Google evaluates page experience, and more importantly, they describe whether your site feels good to use.
No developer jargon below — just what each metric means, what "good" looks like, how to test it and what usually slows a business site down.
Why site speed matters for business
Think of your website like a shop. A slow site is a door that sticks: some people push harder, many just walk to the next shop. Speed affects your business in three ways:
- Conversions. Every extra second of waiting is a chance for the visitor to get distracted, go back to Google and click a competitor. This is especially true for traffic from ads — you pay for the click whether the page loads or not.
- SEO. Google uses page experience signals, including Core Web Vitals, in ranking. They won't beat great content on their own, but between two similar pages, the faster and smoother one has an edge.
- Trust. A site that loads instantly and doesn't jump feels professional. A laggy one feels abandoned, even if the business is great.
Most visitors to small business sites come from phones, often over mobile data. So the question isn't "is it fast on my office laptop?" — it's "is it fast on an average phone in a trolleybus?".
Core Web Vitals explained: the three metrics
Google describes the metrics in detail on web.dev. Here's the plain-language version:
| Metric | What it measures | In human words | Good | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Loading | When does the main content (hero image, headline) appear? | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | Responsiveness | When I tap a button or open a menu, how fast does the page react? | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Visual stability | Does stuff jump around while loading, making me tap the wrong thing? | ≤ 0.1 | > 0.25 |
Anything in between is "needs improvement". Google looks at how real users experience your pages, and a page passes when at least 75% of visits (the 75th percentile) hit the "good" level — separately for mobile and desktop.
LCP: the first impression
LCP is the moment the biggest element on screen — usually the hero photo or main headline — becomes visible. If your homepage opens with a huge uncompressed photo, LCP suffers. Typical fixes: compress and resize images, use modern formats like WebP or AVIF, load the hero image with priority, use fast hosting and a CDN.
INP: does the site respond?
INP replaced the older FID metric in March 2024. It measures the delay between a tap or click and the visible reaction. A menu that opens half a second late or an "Add to cart" button that seems frozen — that's bad INP. The usual cause is too much JavaScript: heavy themes, sliders, chat widgets, several analytics and tracking scripts all fighting for the phone's processor.
CLS: nothing should jump
You start reading, a banner loads above, the text jumps down, and you tap an ad instead of the link. That's layout shift. Fixes: reserve space for images and embeds (set width and height), avoid injecting banners above existing content, load fonts carefully.
How to test your site speed (free)
You don't need special tools to get a first picture:
- PageSpeed Insights (pagespeed.web.dev) — enter your URL. At the top you'll see real-user data (if your site has enough visitors in Chrome's public dataset), below that a lab test with specific recommendations. Check the mobile tab first.
- Google Search Console → Core Web Vitals report — shows which groups of pages are good, need improvement or are poor, based on real visitors.
- Your own phone. Turn off Wi-Fi, open the site over mobile data, and honestly note how it feels. Then try on an older, cheaper phone if you can — your customers have those too.
A tip: don't chase a perfect score of 100 in the lab test. The goal is "good" Core Web Vitals for real users and a site that feels fast. Going from red to green matters much more than going from 92 to 100.
What usually makes a business site slow
From experience, the same suspects show up again and again:
- Huge images. Photos straight from the camera or stock sites, several megabytes each, shown at a fraction of that size.
- Heavy themes and page builders. One theme that "can do everything" loads code for everything, on every page.
- Too many plugins and third-party scripts. Chat widgets, pop-ups, several trackers, social feeds, maps on every page.
- Autoplay video and sliders at the top of the page.
- Cheap or distant hosting without caching or a CDN.
- Web fonts done wrong — many weights and styles, loaded in a way that blocks text.
Quick wins checklist
- Compress images and convert them to WebP/AVIF.
- Set width and height for images and videos to avoid jumps.
- Lazy-load images below the fold, but not the hero image.
- Remove plugins, widgets and scripts you don't truly need.
- Load chats and heavy widgets only after interaction or with a delay.
- Use caching and a CDN.
- Limit fonts to one or two families and a few weights.
- Re-test on mobile after every big change.
Speed is decided at build time
You can optimize a slow site, but it's much easier to build a fast one from the start. The choice of technology, the amount of JavaScript and the way images and fonts are handled all get decided early. When I build a website, performance is a requirement from day one: pre-rendered pages, minimal scripts, optimized images and a mobile-first layout — more on that in mobile-first design.
Speed is one piece of the bigger picture; see why SEO matters for a business website. And if visitors do arrive but still don't buy, check why visitors don't buy.
FAQ
What is a good page load time?
For Core Web Vitals, the main content should appear within about 2.5 seconds (LCP) for most real visitors. In practice, the faster the better — especially on mobile.
Do Core Web Vitals directly affect Google rankings?
They're part of Google's page experience signals, so yes, they play a role — but relevance and content quality matter more. Think of speed as a tie-breaker and a conversion booster, not a replacement for good content.
My PageSpeed score is low but the site feels fast. Should I worry?
Look at the real-user data (field data) and the Search Console report first. The lab score is a diagnostic tool. If real users get "good" Core Web Vitals, you're fine; use the lab recommendations to find easy wins.
Can a slow WordPress site be fixed without rebuilding?
Often it can be improved a lot: images, caching, removing plugins. But if the theme itself is heavy, there's a limit — sometimes a rebuild is cheaper than fighting it forever.
Want a site that's fast by default?
Pick the pages and features you need in the builder and get a rough estimate for a website built for speed from the first line of code — no cap, your mobile visitors will feel the difference.
