By Sarah Dia, HostDroplet Support
Ask what counts as a good website loading speed and you’ll get “under three seconds” from almost every article you read. It’s a reasonable rule of thumb and it isn’t an actual standard. Google publishes specific thresholds, and they’re more precise and more useful: your main content should appear within 2.5 seconds, your page should respond to clicks and taps within 200 milliseconds, and things shouldn’t jump around as the page loads.
There’s a catch that trips people up, though, and it explains why you can score well on a speed test and still see a failing report in Search Console. More on that shortly.
What Google actually measures
Rather than one overall “speed,” Google grades three separate things — the Core Web Vitals. Its own documentation sets out the targets:
- Largest Contentful Paint (LCP) — how long until the biggest visible thing on screen (usually your hero image or headline) has loaded. Good is under 2.5 seconds. For most sites this is the one that matters and the one that fails.
- Interaction to Next Paint (INP) — how quickly the page responds when someone clicks, taps, or types. Good is under 200 milliseconds. This replaced the older First Input Delay metric in 2024, so older articles quoting FID are out of date.
- Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Good is under 0.1. This is the one where you go to tap a button and an image loads above it, moving the button out from under your finger.
Notice that only the first is really about speed. The other two are about the experience feeling stable and responsive — which is a better way to think about it than a single stopwatch number.
Why your test result isn’t your real score
Here’s the part that causes genuine confusion. When you run your site through a speed tool, it simulates a page load on a test device — useful diagnostics, but a laboratory result.
What Google actually grades you on is field data: measurements collected from real Chrome users visiting your site, on their real devices and real connections. And it takes the 75th percentile, meaning three out of four real visits need to hit the threshold. Not your average visitor — your fourth-slowest one.
That’s why a site can look fine in a test and still fail in Search Console. Your test ran on a simulated connection; your actual audience includes people on older phones and patchy mobile data. If your visitors skew mobile, that gap can be large — our guide on why sites are slower on mobile than desktop explains why phones struggle with pages that feel instant on a laptop.
The practical upshot: use PageSpeed Insights for diagnosis, but trust the Core Web Vitals report in Search Console for your actual standing, since that’s real-visitor data.
What’s good enough for your site
Thresholds aside, “good enough” has a second dimension nobody mentions: it’s relative.
If every site competing for your search terms loads in two seconds and yours takes six, you have a problem regardless of what any threshold says. If they’re all at four and you’re at three, you’re comfortably fine. Worth spending ten minutes running a few competitors through the same test — it’s a more honest benchmark than an abstract number.
Your audience matters too. A local business serving customers on modern connections has more headroom than a site whose visitors are mostly on mobile data. And a slow page costs more on a store than on a personal blog, because you can measure the abandoned carts.
One number worth watching that isn’t on the list
Server response time — how long your server takes to send the first byte of the page — isn’t itself a Core Web Vital, but it sets the floor for everything else. If your server takes a second and a half before it even starts responding, hitting a 2.5-second LCP means doing everything else perfectly in the remaining time.
This is the part your hosting genuinely influences, though usually less than people assume — our honest look at whether web hosting affects SEO covers where the server’s role begins and ends, and why website speed matters in web hosting goes deeper on the relationship. You can measure it with our Website Speed Checker.
If you’re not hitting the targets
The fixes are rarely exotic. Failing LCP usually means an oversized hero image or a slow server response. Failing CLS usually means images without dimensions set, or ads and banners that push content down as they load. Failing INP usually means too much JavaScript, which on WordPress usually means too many plugins or a heavy page builder.
In practice, three things fix most sites: enable caching (see clearing and managing cache in WordPress, and check it’s active with our Cache Header Checker), compress and properly size your images, and cut back heavy plugins. Our guide on speeding up WordPress on shared hosting works through these in order of impact, and why your WordPress site is slow covers diagnosis.
Beyond that, GZIP compression shrinks what gets transferred (verify with our GZIP Compression Checker), and a CDN helps if your visitors are geographically spread. If your dashboard is the slow part rather than your public pages, that’s a separate problem with separate causes.
A sane target to aim at
Don’t chase a perfect score. Passing all three Core Web Vitals on real-visitor data is the genuine goal, and it’s a meaningfully lower bar than a flawless PageSpeed number — plenty of sites score in the eighties and pass comfortably, while others hit high scores in testing and fail in the field.
Get your main content appearing within about two and a half seconds for most real visitors, keep the page from jumping around, and don’t make people wait after they click. That’s a fast site by any definition that matters — and if your numbers stay stubbornly poor after the usual fixes, our guide on the warning signs of slow hosting covers when the server is genuinely the constraint.
