Guide Speed & Performance

How to test your website speed properly

How to run a speed test that gives you a real answer, and the common mistakes that produce a misleading one.

iFastHosting Support Team Updated 26 August 2026 8 min read Beginner

A speed test is only useful if it produces a number you can compare against something — an earlier test, a threshold, or another page on the same site. Run one badly and you get a number that looks precise and means almost nothing: today's mobile signal, a warm browser cache, or a test server on the wrong continent, dressed up as a verdict on your website.

This is how to run one properly, what the results are actually telling you, and which parts to ignore.

Pick a tool that tests from outside your own connection

Never judge speed from your own browser. You are probably close to the server, your browser has cached large parts of the page already, and your own broadband has nothing in common with a visitor on a mobile connection three time zones away. Use a tool that fetches the page fresh from a server elsewhere and reports back — that is the only way to see what an actual visitor experiences.

The two categories worth knowing:

Type	What it tells you	Limitation
Lab tools	A detailed, repeatable test run from a fixed location and connection speed, with a full breakdown of every request	One simulated visit — not what real visitors on real devices and connections actually see
Field data	Real measurements collected from actual visitors' browsers over time	Needs enough traffic to be meaningful, and reflects the past rather than the change you just made

Use a lab tool while you are actively working on speed — it gives you an immediate answer to "did that change help?" Use field data, where it is available, to see what real visitors on real networks and devices are actually getting, which a lab test on a fast office connection cannot show you.

What the report is actually measuring

Most modern tools centre their results on Google's Core Web Vitals, three measurements aimed at what a visitor actually perceives rather than at internal server metrics:

Largest Contentful Paint (LCP) — how long until the biggest visible element has rendered. Google's published threshold for "good" is under 2.5 seconds.
Cumulative Layout Shift (CLS) — how much visible content jumps around while the page is loading. Google's published threshold for "good" is under 0.1.
Interaction to Next Paint (INP) — how long the page takes to respond once a visitor actually clicks or taps something. Google's published threshold for "good" is under 200 milliseconds.

These matter for two separate reasons: they roughly track what makes a page feel fast or slow to a real person, and they are also used as a ranking input, covered in does site speed affect search rankings. What Core Web Vitals actually measure goes through all three in more depth.

Read the waterfall, not just the headline score

A single score is a summary. The waterfall chart underneath it is the actual evidence, showing every request the page made, in order, with how long each one took. That is where you find out whether the problem is one enormous image, a font file blocking rendering, a slow server response before anything else could start, or forty small requests each adding a little delay. How to read a waterfall chart covers this properly — it is the single most useful skill in this whole section.

Mistakes that produce a false reading

Common ways to test wrong

Testing while logged in to your own site, testing a cached page and calling it typical, testing once and treating the result as fixed rather than as one sample among several, and testing from a server on the wrong continent to your actual visitors — all of these produce a number that is technically accurate and practically misleading.

Logged-in testing. Content management systems often show extra scripts and skip caching for logged-in users. Always test as a normal, signed-out visitor.
Testing once. Server response time varies run to run. Run a test three or four times and look at the typical result, not whichever one happened to be fastest.
Ignoring location. A test run near your server will always look better than the experience of a visitor further away. If you know where most of your visitors are, test from somewhere close to them.
Confusing mobile and desktop results. Mobile tests usually simulate a slower processor and a slower connection on purpose, since that is what a meaningful share of visitors are actually using. A page that scores well on desktop and poorly on mobile has a real problem, not a test artefact.
Testing the homepage only. The homepage is often the most heavily optimised page on a site. A product page, blog post or checkout page can tell a very different story.

Build a baseline, then re-test the same way

Pick two or three representative pages
The homepage, plus one content-heavy page and one page a visitor completes an action on, such as a contact form or checkout.
Run each test three times and record the typical figure
Use the middle of three runs rather than the best or the first.
Save the report or the numbers somewhere
You need something to compare against once you have made a change — a screenshot or a saved link is enough.
Make one change at a time
Compressing images and minifying scripts in the same afternoon means you cannot tell which one actually mattered.
Re-test the same pages the same way
Same tool, same device setting, ideally the same time of day, so the only thing that changed is the site.

Test after every real change, not just once

Speed testing is only useful as a before-and-after comparison. A single test tells you where you stand today; testing again after each change is what actually tells you whether the change did anything.

Once you know your genuine baseline and where the time in a page load is going, the rest of this section covers the fixes themselves — starting with why your website is slow if you have not already narrowed down the cause, or straight to compressing images if the breakdown already points there.