PageSpeed Insights tests from wherever Google decides, on a device you cannot choose. GTmetrix gives you a decent report from one test server. Then a customer in London tells you your site is painfully slow, while it seems fine from your office in India, and you need a tool that will load the page from London, on a phone-like connection, several times over, and show you exactly what happened. That tool is WebPageTest.
It has a reputation for being the tool developers use, and the results page is busy. But you do not need most of it. This is a beginner’s guide on how to use WebPageTest for the handful of questions small business owners actually ask: how does my site load from another country, on a slower network, for a first-time visitor compared with a returning one, and did my fix make a visible difference?
What WebPageTest is, briefly
WebPageTest is a long-running website testing tool, now operated by Catchpoint, at webpagetest.org. It loads your page in a real browser on a test machine in a location you choose, records everything that happens, and lets you replay it as a filmstrip or video. Its strength is control: where, which browser, what connection speed, how many runs, and whether to load the page a second time to see the cached experience.
Testing is only half the job, of course; our overview of how to make a website load faster covers what to do with what you find. Access arrangements, such as whether you need to sign in and which features are open to you, have changed over the years, so go by what the site shows when you visit. Busy test locations can also mean a short wait in a queue.
Setting up your first test
On the start page there is a field for your URL and a set of test settings. There is usually a simple configuration with ready-made choices, and an advanced one with more options. Here is what each setting means and what to choose.
Test location
Pick the location closest to the customers you care about, not to yourself. If your buyers are mostly in the UK, choose a UK location. If your site is hosted in the US and you sell mostly to India, choose an Indian location if one is available, or the nearest one. The list of locations changes over time, so choose from what is offered.
This is WebPageTest’s main advantage over most other tools. If you suspect your site is slow abroad because of where it is hosted, testing from the visitor’s region is the only way to see it. Our post on why a website is slow for overseas visitors covers what to do about it once you have the evidence.
Browser and device
You can usually pick a desktop browser, such as Chrome or Firefox, or an emulated mobile device. For a mobile test, pick a mid-range phone profile rather than the latest flagship. Many of your visitors will not have the newest handset.
Connection profile
Connection profiles throttle the network to imitate a typical cable, 4G or 3G link, with fixed download speed, upload speed and latency. A slower profile exposes problems that a fast one hides: heavy images, many separate files, chains of requests that each wait on the last. For mobile tests, choose a mobile profile. Keep the same one every time you compare results.
Number of runs
Set three runs at least, five if the page has ads or lots of third-party scripts. WebPageTest picks the median run and shows it by default, which saves you working it out yourself. A single run is one sample and can mislead.
Repeat view
This option tells WebPageTest to load the page a second time straight after the first, keeping the browser cache. The first view is a new visitor; the repeat view is someone coming back or clicking through to the next page. Keep it switched on. The difference between the two is one of the most useful things the tool tells you.
Labels and video
Give the test a label, such as “home, before image fix”, so you can find it later in your history. Video capture is usually on by default; keep it, because the filmstrip depends on it.
Reading the results without getting lost
The results page is long. Work through it in this order.
1. The summary table
Near the top is a table of key timings for the first view and the repeat view, from the median run. Depending on the version, you will see figures such as time to first byte, start render (when something first appeared), First Contentful Paint, Largest Contentful Paint, layout shift, blocking time, total bytes and number of requests. You do not need all of them. Note first byte, start render, LCP and total bytes for each view.
If the first view is slow but the repeat view is quick, the page relies heavily on files a first-time visitor has not cached yet. Many of your new visitors arriving from search or ads get the slow version. If both views are slow, the problem is not only file downloads: the server, scripts or the page’s structure are involved too.
2. The filmstrip
The filmstrip view shows screenshots of the page at regular intervals as it loaded. This is often the moment it all makes sense. You can see the blank white screen, the point where the header appears, the gap before the hero image, the cookie banner pushing content down, the font changing as it swaps in.
Look for the frame where the page looks usable to a visitor. That moment, not the final “fully loaded” figure, is what people actually feel. You can often adjust the interval between frames to see more detail in the first seconds.
3. The waterfall
Under the summary, each run has a waterfall chart: one row per file, with coloured bars showing when it was requested and how long each stage took. It works much like the waterfall in GTmetrix, and our guide to reading a waterfall chart row by row covers the colours, the phases and the common patterns, so we will not repeat them here. WebPageTest’s version marks key moments with vertical lines and highlights requests that block rendering, which helps you connect a file to a delay in the filmstrip.
4. Web Vitals and extra views
WebPageTest also shows a page focused on Core Web Vitals in the lab: which element was the largest contentful paint, which elements shifted and by how much, and which long tasks blocked the main thread. Seeing the actual element highlighted is often clearer than a line of text in another tool. Newer versions also list suggested opportunities for improvement; treat them as pointers to check, the same way you would treat suggestions in any other tool.
How to use WebPageTest for four common questions
“Is my site slow for customers abroad?”
Run the same page from a location near your server and from the customers’ region, same browser, same connection, same number of runs. Compare first byte and start render. If first byte jumps from one region to the other, distance to the server is part of the problem, and a CDN or different hosting location is worth discussing.
“Why is the first visit so slow when the second is fine?”
Look at the first and repeat views side by side. Count the requests and bytes in each. A big drop in the repeat view means caching is working for returning visitors, and the first-visit weight is what needs trimming.
“Did my change actually help?”
Run a labelled test before the change and an identical one afterwards. Then use the comparison feature in your test history to put the two filmstrips side by side. A visual comparison is often more convincing to a client or business partner than any score, because they can see the page appear sooner.
“Is a third-party script the culprit?”
In the advanced settings, WebPageTest lets you block requests to specific domains for a test. Run the page once normally and once with, say, the chat widget’s domain blocked. If start render or blocking time improves noticeably, you have your answer, without touching the live site.
Mistakes beginners make
- Changing more than one setting between tests. Different location and different connection profile? You cannot tell which caused the change.
- Testing from the nearest location to you rather than to your customers.
- Reading only the fully loaded time. It includes late tracking requests and often overstates what visitors feel.
- Comparing WebPageTest numbers with PageSpeed Insights numbers. Different machines, networks and settings. Compare each tool only with itself.
WebPageTest is one tool in a wider kit. For how it fits alongside the others in a consistent routine, see our website speed test guide. Used that way, a single afternoon of careful tests usually tells you more than months of occasional one-off scores.
Frequently asked questions
Why does the repeat view still download some files?
Files come again when their cache headers tell the browser not to keep them, or to keep them only briefly. Third-party scripts often have short cache lifetimes, the HTML page itself is usually checked again, and some tracking requests are designed to fire on every visit. A long list in the repeat view is worth checking against your own files first.
Which connection profile should I choose for mobile testing?
Choose a mobile profile such as 4G for a typical modern visitor, and try a slower profile occasionally if many of your customers are on patchy mobile data. What matters most is consistency: once you have picked a profile, keep using it for every comparison so differences come from your site, not from the settings.
Why are WebPageTest results slower than PageSpeed Insights?
They often use different test locations, devices and connection settings, and WebPageTest may be loading your page from much further away or on a slower profile. Neither result is wrong. Compare each tool only with its own earlier results, and use WebPageTest specifically for questions about location and repeat visits.
What does start render mean in WebPageTest?
Start render is the moment the first visible change appears on screen during the load, taken from the recorded video. Before it, the visitor sees only a blank page. A late start render usually points to a slow server response or to stylesheets and scripts that block the browser from drawing anything.
Labelled WebPageTest results, such as a slow first visit or a slow load from overseas, make a good starting point for whoever helps with the fixes. Our speed optimisation service can start from those test links and compare against them afterwards.
Next in this series: Check Page Load in Chrome DevTools: The Network Tab
