Why it’s worth timing your own pages

2 November 2026

Hosts, CDNs and website builders work hard on speed, and most will show you how quickly their side of things runs. Those numbers are real and useful. But your visitors are somewhere else entirely, on a three-year-old phone on a train, or hotel Wi-Fi on the other side of the world.

The only way to know how fast your site really is, is to time it in your visitors’ own browsers. Here’s why that’s worth doing, and what the numbers tend to show.

Why speed matters

People notice slow pages, and they act on it, even when the difference is tiny. In 2019, Deloitte watched more than 30 million mobile sessions on 37 European and American brands’ sites. When pages got just a tenth of a second faster, retail conversions rose 8.4% and travel conversions 10.1%. Shoppers also spent 9.2% more.

Vodafone tested it directly. It made two versions of a landing page that looked and worked the same, but one loaded its main content 31% faster for real visitors. The faster one made 8% more sales.

Search cares too. Google measures pages by three numbers it calls Core Web Vitals, and recommends getting them right “for success with Search”. They’re one of the things Google weighs when it ranks pages, so speed is part of good SEO, and a slow page can cost you visitors before they’ve even arrived.

How fast the web really is

Not as fast as you’d hope. Each year the HTTP Archive looks at millions of sites using timings from real Chrome users. In July 2025, only 48% of sites passed all three Core Web Vitals on phones, and 56% on computers. That’s up from 32% on phones in 2021, so things are getting better, slowly.

The main thing holding sites back is how long the biggest image or block of text takes to appear. Only 62% of sites got that right on phones.

The platform you build on makes a real difference, too. Here’s the share of each one’s sites that passed on phones in 2025, from the same report’s chapter on site builders.

But look at it the other way round. Even on the fastest platform, about one site in seven still fails, and on the slowest, nearly half pass. These figures are for whole platforms. Your own site could be one of the fast ones or one of the slow ones, whichever you build on, and the only way to know is to measure it.

A test isn’t a visitor

Most speed scores come from a lab test, like Google’s Lighthouse. They’re great for finding what to fix. But Google itself explains why lab and real-world numbers often don’t match. A test runs once, from one place, on one kind of device and connection, usually with nothing cached. Your visitors are spread across every phone, network and country you can think of. Google’s advice is to use real-world data to decide what to work on.

Google does publish real-world timings, but only for sites popular enough to make the cut, and only from people using Chrome. If your site is small, or most of your visitors are on iPhones, you may get nothing at all.

Then there are the numbers your host, CDN or site builder gives you. They usually time their own part of the job, such as how quickly their servers answer, from their own network. That’s useful, but it’s their view of their bit. It doesn’t include the fonts, scripts and images your page loads from elsewhere, or the visitor in Sydney on a busy phone network.

How we time your pages

fivebar’s tag, the same one that counts your visitors, times every page load in your visitors’ own browsers. That includes Safari and Firefox, not just Chrome. It needs nothing extra from you, and it works the same whoever hosts your site.

Our Speed page shows the three Core Web Vitals, plus how long your server took to start answering and when the first thing appeared. Each one is rated by Google’s own thresholds, split by phones, tablets and computers, and you can narrow it down by country or browser. The pages with the most slow loads are listed first, so you know where to start.

You can see djangodocs.dev’s Speed page as it is today, too.

The same numbers are there for your coding agent. Connect fivebar’s MCP server to Claude Code, Cursor or another assistant, and it can read your Speed page, and which pages were slowest, while it works on your site. Ask it why your pages are slow on phones, and it can find the pages and the measure that are the problem, look at the code behind them and suggest a fix, such as a smaller image, a font that loads sooner or a script that waits its turn. Once the fix is live, it can check the next week’s numbers to see whether your visitors noticed.

We’re not selling you hosting, so we’ve no reason to make anyone look good. If your pages are fast, you’ll see it. If they’re slow in one country or on one kind of phone, you’ll see that too, and that’s usually the more useful thing to know.