Website speed test

What the website speed test measures

The website speed test runs from a server in Stockholm, inside the EU, so you see how your site answers a visitor in Europe rather than one next to a data centre in Virginia. For a company outside Europe with European customers, that is the number that counts: a site hosted far away can feel fast at the office and slow in Amsterdam, Munich or Milan.

The test measures the time to first byte, the moment your server starts answering. It weighs your HTML on the wire and unpacked, checks compression, counts what the page loads and weighs up to five of your own heaviest files. It checks whether your first image loads at once, whether your images have a fixed size, how many scripts come from other servers, which platform your site runs on and whether a CDN sits in front. On top it shows what that weight costs on slow 4G; below, what to fix first and roughly what it takes. How fast Belgian business sites load on average, per sector and platform, is in our page speed statistics for Belgium.

The sum behind the load time

The load time on top is a sum in three parts: the weight in bits divided by 1.6 megabits a second, plus 0.15 seconds per request, plus the server time. Those are Lighthouse's slow 4G values, roughly the slowest quarter of 4G connections. A worked example: a page with 40 kB of HTML, a 1.4 MB hero photo and a 230 kB script weighs 1,704 kB together. That is 8.7 seconds to fetch, plus three requests of 0.15 seconds, plus 0.3 seconds of server time: 9.5 seconds. Convert the photo to WebP at the size it is shown, say 250 kB, and the total drops to 3.4 seconds. Same page, same photo on screen.

The yardstick of the test, and who sets each limit:

What the test does not measure: how fast your page paints in a browser, how quickly it responds to a tap and whether anything jumps. Those are the Core Web Vitals, and Google measures them with real visitors. The test opens no browser and does not weigh files from other servers; it counts them without fetching them.

Core Web Vitals: lab data and field data

Google judges speed with three Core Web Vitals, each at the 75th percentile of visits, separately for phones and desktops. Three out of four visits have to meet the limit.

48 percent of mobile sites pass all three. Field data comes from Chrome users over 28 days: you see it on top in PageSpeed Insights and in the Core Web Vitals report in Search Console. With too few visitors on a page, PageSpeed Insights falls back to your whole domain, or shows nothing. Lab data is one Lighthouse run on a simulated mid-tier phone on a mobile network. Lighthouse cannot measure INP, because nobody taps; it shows Total Blocking Time instead. The 0 to 100 score is a lab score: 90 and up is good, under 50 poor. Google ranks on the field data, not on that score.

Does speed count in Google? Google writes that its ranking systems use the Core Web Vitals. Relevance comes first, though: the page that answers best can win while slower, and good scores guarantee no top spot. Speed mostly decides between pages that answer equally well, which is why this test belongs next to the SEO checker, not instead of it. A page that does not show at all is a different problem: run the findability check.

Where the weight sits

The median mobile page weighed 2,164 kB in 2025, over 72 requests, with 911 kB of images and 646 kB of JavaScript. One mobile page in ten weighs more than 8,337 kB. The causes come from the same five corners.

Images. On 76 percent of mobile pages an image is the largest element, the one LCP waits for. WebP is 25 to 34 percent lighter than JPEG at the same quality, and an image at the size it is shown often saves more than the format. Never lazy-load that first image: 16 to 17 percent of pages do, and the largest element then waits for a scroll that does not come. Give it fetchpriority=high; only 17 percent do.

Fonts. Every font from another server is one more connection before text can show. Host them yourself, load only the weights you use and set font-display to swap.

Third-party scripts. Chat widgets, trackers, video and map embeds, consent banners: each is code you do not control. The test counts them; from six on, check per script whether it still earns its place.

Hosting and distance. If the server answers slowly, nothing else helps. In 2025 only 44 percent of mobile sites had a good time to first byte. A page cache, or a CDN close to your visitors, usually solves it. A site that serves Europe from a single server on another continent pays that distance on every first request. Moving it is less risky than it sounds when the addresses stay the same: see moving a website to a new host.

The platform. A page builder with dozens of plugins puts code on every page, also where it does nothing. Why that happens so often on WordPress is in why WordPress is so slow.

What to do per finding, and what it takes

The test lists findings in the order they cost your visitor most, and says roughly what the first one takes. The times below are our estimate for an ordinary business site, not a quote.

Three buyers, three routes. A small firm on shared WordPress hosting: the server usually tops the list; a page cache first, the images second, an afternoon in total. A store on Shopify or WooCommerce: the server is fine or not yours to change; the gain sits in product photos and in apps that each add a script, so test a product page, not only the homepage. Building or rebuilding a store is webshop development. A company of ten selling into several EU countries: test what your customers in the Netherlands or Germany get, on each language version; every extra language is a set of pages that has to be light too, which is what multilingual website development is about. A static export on a CDN takes the server time almost out of the equation, wherever they sit; that is how we work as a web development agency in Europe, with Next.js, which you can also hire us for inside your own team.