Testing website speed: how to measure load time properly

A good speed test looks beyond how long the page takes to load. Three moments matter: how quickly the first visible part appears, how quickly the largest element (usually the hero image or main heading) renders, and how quickly the page responds once you click or scroll. Visual stability counts too: if the layout jumps around while loading, the site feels slow and you misclick.

These moments are standardised in the Core Web Vitals: LCP, INP and CLS. Google explains the thresholds on web.dev. If you know those three values, you almost always know where the problem is: heavy media, too much JavaScript, or a layout that loads without reserved space.

Most owners test their site on a fast laptop with fibre, while the majority of visitors arrive on a phone over a mobile network. So always test with a simulated mobile connection and an average device. A page that loads in 1 second at the office can easily need 5 seconds on 4G.

Also test more than just the homepage. Product, category and contact pages often have different problems: more images, more scripts, different templates. A one-off check via PageSpeed Insights on a single URL is a useful starting point, but says little about the rest of the site. That is why the WebYes scan measures multiple pages per site and includes the result in the speed pillar.

The free WebYes scan (beta) crawls up to six pages of your domain and measures lab data: simulated load times and performance signals aligned with what you see in Lighthouse or PageSpeed Insights. That is deliberately lab, not field data from real visitors. Lab is reproducible and immediately available; field data (the Chrome User Experience Report) is the verdict Google uses for rankings when there is enough traffic.

Speed is one of the four pillars of the report, alongside SEO, security and accessibility. For the keurmerk: average score at least 80, and each pillar separately at least 60. A site that scores high on SEO and security but stays below 60 on speed therefore does not get the keurmerk. More on the metrics themselves is in Core Web Vitals; for mobile context, mobile-friendly website is relevant, because LCP and CLS hit hardest there.

Many testing tools show a total score, and that invites point-chasing. Usually that is wasted effort. A score is a weighted summary; the underlying measurements tell you what a visitor actually notices. A site can climb from 82 to 91 points without anyone feeling a difference, and conversely a half-second improvement in LCP can be immediately noticeable while the score barely moves.

So work from big to small: first the metric that scores worst, and within it the page with the most traffic. A product page that attracts hundreds of visitors a day and loads slowly matters more than a contact page with a perfect score. Use the LCP guide on web.dev to understand which element stops the clock, and combine test results with your visitor statistics to decide where an improvement pays off most.

Almost every slow site has the same three culprits, in this order of impact:

Measure again after every change. Speed optimisation is a cycle of measuring, adjusting and verifying; without a new measurement you do not know whether a fix works. Start with the heaviest page in your scan report, fix one cause, and repeat the test under the same conditions (same tool, same device profile).

Start with one baseline: the same tool, the same device profile, the same URLs. Record LCP, INP and CLS per page before you change anything. Without a baseline you cannot tell whether a CDN, image compression or removing a chat widget brought the real win. The free WebYes scan (beta) gives that baseline on up to six pages; a full audit up to fifteen.

Work in sprints of one cause at a time. Week 1: hero images and LCP. Week 2: third-party scripts and INP. Week 3: layout reserves and CLS. Repeat the lab measurement after each sprint under the same conditions. That prevents three simultaneous changes from muddying the result.

Then schedule a re-audit. With a paid keurmerk WebYes plans fresh full audits when the newest scan is older than about thirty days. In between you can re-scan from your account, with a sixty-minute dedupe window per domain. That rhythm keeps the speed pillar honest: a one-off lab score is not proof the site stays that way.

Testing only on office Wi-Fi with a fast laptop underestimates mobile visitors. Use at least one mobile profile or a real device on 4G. Another pitfall: carrying over cache from a previous run. A hard refresh or clean session stops you from selling a warm cache as a 'fast site'.

Do not compare individual scores from PageSpeed Insights, WebPageTest and WebYes as if they share one scale. Follow trends within one tool. The underlying Core Web Vitals are defined the same everywhere; that is your shared language, not the tool's letter grade.