Page speed test

How it works

How it works You give a tool a public URL. The tool loads that URL the way a browser would: DNS, TLS, HTML, then the CSS, scripts, fonts, and images that HTML asks for. It records timestamps for those steps and turns the timeline into a report. Some tools run in your own browser. Others run from a remote machine so the result is not tied to your laptop, your extensions, or your warm cache.

A useful report splits three questions. How long until something appears? How long until the page can be used? Did the layout jump while assets arrived? Lab tools answer those on a fixed device profile. Field tools answer them from real visits, which include slow networks and people who bounce. Neither replaces the other. A page speed test is a camera, not a grade you can argue with.

Typical lab runners include browser developer tools, Lighthouse-style audits, and hosted waterfalls such as WebPageTest-style labs. Hosted runs let you pick a location, a connection profile, and a cold cache. Local runs let you click through the page after load. If a test cannot reach the URL, the report is empty: that is a network or robots problem, not a speed score.

Paste the exact URL you care about, including https and the final path. Choose a cold load if you want first-visit cost, or a repeat load if you care about cache. Capture the waterfall, not only a single number at the top of the page. Change one thing, then run the same tool the same way again.

What a speed tool actually records

Waterfalls show request order. A blocking stylesheet at the top of the document holds paint. A huge image without dimensions can shove text after it arrives. A third-party script can sit in the critical path even when your own HTML is small. The tool does not know which of those you meant to ship. It only knows what the browser had to wait on.

Compare like with like. A homepage and a logged-in dashboard are different documents. A test from your office fiber is not a test from a phone on a train. If you switch tools between runs, you are not measuring the page. You are measuring the difference between tools. Keep the URL, the device profile, and the cache policy still, then change the code. A page that feels instant on your machine can still stall on a phone with a cold cache.

Using the report without chasing a trophy

Start with the longest bar on the waterfall, not with a marketing label. If HTML is slow, the origin or the TTFB path is the job. If HTML is fast and paint is late, look at CSS and fonts. If paint is fine and the page still feels stuck, look at JavaScript that blocks input. Compressing an already tiny icon will not fix a 2 MB hero video. The test is there to rank work, not to decorate a slide.

Re-run after each change. A font-display tweak and an image resize can move different metrics. If the second run is worse, you learned something; keep the first artifact. Save the report next to the deploy so you can see whether the live URL matches the lab URL, including query strings and CDN headers. A page speed test on staging that never ships is a rehearsal, not a result.

Test the live host you claim to have improved. Disable your ad blocker when you want the same third parties users get. Watch filmstrips for layout jumps the numbers underplay. Stop when the next change costs more than the delay it removes.