How fast should your website load? The numbers that actually matter

There's no shortage of general advice about website speed: "faster is better," "optimise your images," "use a CDN." All true. None of it tells you what you actually need to know: what specific numbers should your site hit, what happens if it doesn't, and where do you start fixing it?

Let's go through it properly.

Core Web Vitals — Google's actual benchmarks

Google published its Core Web Vitals framework as an official set of signals that affect search rankings. There are three main metrics, each with clear pass/fail thresholds.

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page to load — usually your hero image, banner, or main heading. This is the metric most closely correlated with how fast a page feels to a visitor.

• Good: 2.5 seconds or under
• Needs improvement: 2.5–4 seconds
• Poor: Over 4 seconds

INP — Interaction to Next Paint

INP replaced the older FID (First Input Delay) metric in March 2024. It measures how responsive your page is to user interactions — clicking a button, opening a menu, submitting a form. If your page is visually loaded but the interface lags when someone tries to interact, your INP will be poor.

• Good: 200 milliseconds or under
• Needs improvement: 200–500 milliseconds
• Poor: Over 500 milliseconds

CLS — Cumulative Layout Shift

CLS measures visual stability — how much the page layout jumps around as it loads. You've experienced bad CLS when you go to click a button and it moves just before you click, landing you on an ad instead. It's infuriating, and Google penalises it.

• Good: 0.1 or under
• Needs improvement: 0.1–0.25
• Poor: Over 0.25

What slow load times actually cost you

The business case for speed is well-documented. Google's own research found that as page load time goes from 1 second to 3 seconds, the probability of a mobile visitor bouncing increases by 32%. Push it to 5 seconds and that bounce probability jumps 90%. These aren't marginal differences — they're the difference between a functioning website and an expensive brochure nobody reads.

Amazon's internal research showed that every 100ms of additional latency cost them 1% in sales. Walmart found that each 1-second improvement in page load time increased conversions by 2%. These are enterprise-scale examples, but the underlying human behaviour is the same at every scale: people are impatient, and they have alternatives one tap away.

For a local NZ service business, a slow website is a direct revenue leak. If 100 people find your site via Google each month, a 3-second LCP might mean 30 of them bounce before they've read a word. You paid for that traffic — through SEO effort or ads — and a slow site is burning it.

How to test your site

Two tools cover everything you need:

Google PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) gives you both lab data (simulated) and field data (real user experiences from Chrome users who've visited your site). Enter your URL and you'll get scores for mobile and desktop, a breakdown of each Core Web Vital, and specific recommendations sorted by impact. Start here. It's free and authoritative.

GTmetrix

GTmetrix is useful alongside PageSpeed Insights because it offers waterfall charts — a visual breakdown of every asset the page loads and how long each one takes. When you're trying to identify which specific image, script, or font is causing the bottleneck, the waterfall is invaluable. The free tier is sufficient for most diagnostic work.

What actually causes slow sites

In order of how often they're responsible for poor performance:

• Unoptimised images. A 3MB hero image on a site that should be serving a 150KB WebP file is the single most common cause of poor LCP. Every image should be sized correctly for its display dimensions, converted to modern formats (WebP, AVIF), and compressed.
• Excessive JavaScript. Bloated themes, unused plugins, and third-party scripts (chat widgets, marketing trackers, social embeds) all contribute to render-blocking JS that delays everything. Every script is a performance cost that needs to justify itself.
• No caching. If your server is generating the page from scratch on every single request, you're wasting processing time that caching would eliminate. Static site generators and CDNs solve this almost entirely.
• Slow server / shared hosting. Cheap shared hosting means your site shares resources with potentially hundreds of other sites. When those sites spike in traffic, yours slows down. Time to First Byte (TTFB) above 600ms almost always points to a hosting problem.
• Render-blocking resources. CSS and JS files loaded in the wrong order — particularly in the document head — prevent the browser from rendering anything until they finish loading. Deferring non-critical scripts and inlining critical CSS eliminates this.

What score should you aim for?

The PageSpeed Insights score (0–100) is a composite. You want:

• Mobile: 70+ is good, 85+ is great
• Desktop: 90+ is expected from a well-built site

More importantly, focus on hitting the "Good" threshold for all three Core Web Vitals in the field data section — that's what Google is actually using to evaluate your pages. A score of 95 in the lab with poor field data is worse than a score of 75 with all three vitals in the green.

Speed is not a technical vanity metric. It's a direct input to rankings, to bounce rate, to conversions, and ultimately to revenue. A site that loads in 1.8 seconds isn't just faster than one that loads in 4 seconds — it converts meaningfully better, ranks higher, and wastes less of the attention of every person who lands on it.