Website speed: why it matters and how to check yours
Speed matters to your visitors first and to Google second. Google measures it with three Core Web Vitals: the main content should appear within 2.5 seconds, the page should respond to a tap within 200 milliseconds, and the layout shouldn't jump (a CLS of 0.1 or less). Check your site for free in PageSpeed Insights and in the Core Web Vitals report in Search Console.
Why does website speed matter?
Because people leave slow pages, and the ones who stay buy less. When Vodafone tested two versions of a landing page, the version with a 31% better Largest Contentful Paint brought 8% more sales (web.dev, March 2021). It's one test at one company. It still shows that a faster page can move real numbers.
Google counts speed too. "Core Web Vitals are used by our ranking systems," says Google Search Central. In the same breath, it says good scores don't guarantee a top spot, and that it will still show the most relevant page even when its page experience is poor (Google, September 2026). So speed won't rank a weak page. It can hold back a good one.
Most sites aren't there yet. In July 2025, only 48% of websites passed all three Core Web Vitals on mobile, and 56% on desktop (Web Almanac 2025, January 2026). If yours passes, you're doing better than about half the web.
What are Core Web Vitals?
Three measurements of how a page feels to a real visitor: how fast the main content shows up, how quickly the page reacts, and how still it stays while it loads.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP · Largest Contentful Paint | When the biggest image or text block on screen has loaded | 2.5 s or less | Up to 4 s | Over 4 s |
| INP · Interaction to Next Paint | How long the page takes to respond to a click, tap or key press | 200 ms or less | Up to 500 ms | Over 500 ms |
| CLS · Cumulative Layout Shift | How much the layout jumps while it loads | 0.1 or less | Up to 0.25 | Over 0.25 |
Thresholds from web.dev and PageSpeed Insights, checked October 2026.
Two details matter. First, a page passes when at least 75% of visits reach "good", measured separately on mobile and desktop (web.dev, October 2024). A fast load on your office Wi-Fi doesn't prove much. Second, INP is new. It replaced First Input Delay as a Core Web Vital in March 2024 (web.dev, March 2024), so older audits may still talk about FID.
LCP is where most sites fall short. On mobile, 62% of sites have a good LCP, against 77% for INP and 81% for CLS (Web Almanac 2025, January 2026).
How do you check your site's speed?
With two free tools from Google. Each takes a few minutes.
PageSpeed Insights. Go to pagespeed.web.dev, paste your address and run it. You get two blocks:
- Real users, at the top. Data from Chrome users who visited in the last 28 days. It tells you whether the page passes the Core Web Vitals assessment, with LCP, INP and CLS each marked good, needs improvement or poor (Google, October 2024).
- A lab test, below. Lighthouse loads the page once in a simulated environment and gives a performance score from 0 to 100: 90 or more is good, 50 to 89 needs improvement, under 50 is poor. Under the score is a list of what to fix.
Check the mobile result first, then desktop. And test more than your home page: your pricing, contact or most visited service page matter just as much.
Search Console. If your site is verified in Search Console, open the Core Web Vitals report. It uses the same real-user data, groups similar pages and rates each group by its worst metric (Search Console Help). You see the whole site at once, not one page at a time. After a fix, start a validation. Google then watches those pages for 28 days.
Small site, no data? PageSpeed Insights may say there isn't enough real-user data. That means too few Chrome visits for Google to report. It then falls back to your whole site, and if that's not enough either, you only get the lab test (Google, October 2024). For many local businesses, that's normal. Use the lab test as your guide.
Which number should you trust?
The real-user data. It's what your visitors actually experienced, and it's the data behind the Search Console report. The lab score is one simulated visit. Google itself says lab data may not capture real-world bottlenecks (Google, October 2024). It's useful for finding causes and checking a fix before it reaches real people.
So don't chase 100. A page with a lab score of 85 that passes on real users is in good shape. A page that scores 98 in the lab and fails on real users has a problem the lab doesn't see: slower phones, weaker connections, or scripts that only load for some visitors.
Fixes also take time to show. Real-user data covers 28 days, so the numbers improve gradually, not the morning after.
What usually makes a site slow?
Mostly weight. The median mobile home page weighed 2.56 MB in July 2025, with about 911 KB of images and 632 KB of JavaScript (Web Almanac 2025, January 2026). The usual suspects:
- Big images. Photos uploaded straight from a camera or a stock site. On 76% of mobile pages, the largest element on screen is an image (Web Almanac 2025), so that one image often decides your LCP.
- A lazy-loaded main image. Lazy loading is meant for images further down the page. On 17% of mobile pages, the main image is lazy-loaded (Web Almanac 2025), which tells the browser to fetch it later than it should.
- Images without dimensions. 62% of mobile pages have at least one image without a set width and height (Web Almanac 2025). The browser doesn't know how much space to keep, so the text jumps when the image arrives. That's CLS.
- Scripts nobody remembers adding. Chat widgets, cookie banners, trackers, testing tools, embedded maps and videos. Each one adds JavaScript the phone has to run before it can react to a tap.
- The theme and plugins. The build matters more than the platform. On mobile, 45% of WordPress sites pass Core Web Vitals, and 74% of Wix sites do (Web Almanac 2025, January 2026). A theme with many plugins and a page builder carries code for features you never use.
What can you fix yourself?
More than you'd think. Start with the list under the lab score in PageSpeed Insights, then:
- Export images at the size they're shown, in WebP or AVIF, not as camera originals.
- Remove what nobody uses. Old tracking codes, a chat widget no one answers, plugins for features you've switched off.
- Replace a heavy video in the hero with a still image or a short, compressed clip.
- Test again on mobile after each change, so you know what helped.
Some fixes need whoever builds your site: giving the main image priority instead of lazy-loading it, setting dimensions on every image, loading fonts and third-party scripts so they don't hold up the page, and serving the right image size to each screen.
And sometimes the honest answer is a rebuild. If the theme itself is the problem, patching it every year can cost more than starting clean. When we build, AI runs the checks for speed, spacing and accessibility on every page. We decide what to fix and how. This site is built with Astro, which sends plain HTML to the browser.
What we'd do
Run your home page and your most important page through PageSpeed Insights on mobile. If the real-user data passes, leave speed alone and spend the time on content. If LCP fails, start with the main image. If the site is slow because of its theme, plugins or platform, a redesign or a move to a new platform can cost less than patching it year after year.
After launch, our Care plan, from €290 a month, watches your platform, backups and uptime, with a monthly SEO and AI-search health check.