Site speed test: we measured 10 pages with one method

The method, precisely

Every number below is reproducible with these settings, one cold run per URL, all inside a few minutes on 15 August 2026, from a server in a datacentre:

lighthouse 12.8.2
Chrome for Testing 148.0.7778.96
--form-factor=mobile --screenEmulation.mobile
--throttling-method=simulate
--only-categories=performance

Ten pages

Two rows Lighthouse itself flagged

This belongs in the piece because the report says it. On two of the ten runs Lighthouse returned the warning that the page loaded too slowly to finish within the time limit and results may be incomplete: mizfa.tools and zhaket.com. Read 77 and 35 with that in mind. The direction is right, the precision is lower than the other eight. The remaining runs, ours included, carried no warning.

Reading the rest of the table

The first four Google results for that speed test query, the pages teaching people how to measure site speed, scored 66, 67, 48 and 77.

Two rows that break the obvious reading

Read the table top to bottom and you get a simple message that happens to be wrong. Look at two rows on their own instead.

seo33.ir scored 99 with a server response of 1490 ms. Its server started answering roughly a second and a half later than ours and it still took a full score, because the score is a weighted blend and a light page absorbs a slow server. That second and a half stays in the visitor's pocket regardless; the tool forgives it on its own scale, and the person waiting does not.

rtl-theme.com is the mirror image: an LCP of 11.2 seconds and a score of 65. Nothing went wrong in the measurement. LCP carries 25 percent of the total and the remaining metrics held the number up.

The practical conclusion is to use the score for comparing two versions of one page, never for judging a site. Look at LCP, INP and CLS separately.

Lab numbers and field numbers

All ten figures above are lab data, including our own 99. One run, from a server with a good connection, through a mobile emulation. That is excellent for diagnosis and useless for predicting rank.

Google assesses page experience on field data: the 75th percentile of your real visitors over the previous twenty eight days, split by mobile and desktop. If your site does not draw enough traffic to populate that dataset, you have no field data at all, and no tool will manufacture it for you.

One caution about branded speed testers generally: most of them are a Lighthouse run wearing someone else's interface. That is fine, but do not expect field data from them and do not treat their number as interchangeable with PageSpeed, because the throttling settings are not the same.

How our own page reached 151 KiB

The lightest row is ours and nothing about the route was clever. CSS is injected into the HTML so no request blocks rendering, fonts are subset, and every animation, transition and backdrop filter was stripped from the whole site. That last decision is what took TBT to zero. One exception survived, on the desktop header only.

Did it cost some visual polish? A little. Zero TBT and zero CLS on mobile is not something a caching plugin delivers, though, because caching was never the constraint.

When testing your speed is a waste of an afternoon

If your LCP is 2.5 seconds and traffic is flat, speed is not your problem. Pulling it to 1.9 buys a green tick and almost no ranking, because page experience carries small weight next to how well the content matches the query.

Speed is worth spending on when the number is genuinely bad, like the bottom rows of this table, or when conversion rather than ranking is the goal. We say that while selling speed work, because selling a speed project to a site whose real problem is its content produces an unhappy client two months later.

Questions that come up after a test

What score should I aim for

The score is not the target. Read the three metrics separately: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. A site scoring 75 that clears all three is in better shape than one scoring 90 with broken CLS.

Why does the number change every time I run it

Because a lab run is sensitive to the state of the network and the load on the server at that moment. Run it three times, take the median, and always test from the same place.

My WordPress site is slow, where do I start

Page weight first, server response second. Look at the table again: every page above two megabytes in this set scored below eighty.

Where to go next

If you want to know exactly what the three core metrics measure, a plain explanation of LCP, INP and CLS is the right starting point. If your server response looks like the bottom two rows, the cause usually sits in how hosting configuration drives your speed numbers rather than in the theme.

And if your numbers really are bad and you want to know how much of it is fixable, speed work measured before and after starts from a table like this one rather than from a screenshot. For a site that does not exist yet, the cheapest way to these figures is building without the extra weight from day one, since making a heavy site light always costs more than building it light.

Sources

• The Web Vitals reference page for the thresholds and the definition of the 75th percentile
• How the Lighthouse performance score is calculated for the weight each metric carries

Everything was measured on 15 August 2026. Run the same URLs today and the numbers will differ, because pages change.