GTmetrix vs WebPageTest

Open GTmetrix when you want a page graded and kept under watch: a readable report, a history of runs, and monitoring on its paid plans.

Open WebPageTest when the question is why: a filmstrip of the page painting, a waterfall of every request, the same page over a slower connection, and the second visit with a warm cache.

Both tools load a page and time it. Four criteria separate them in practice.

• Readability: a report you can hand to someone, or a diagnostic surface you interpret.
• Depth: one summary of what to fix, or the request-by-request evidence behind it.
• Repetition: a run you keep and compare, or a run you tune and rerun with different settings.
• Watching: alerts and scheduled runs, or a one-off test whenever you need it.

GTmetrix is a page speed testing service built on Lighthouse. The scores and audits you see come from the same engine as PageSpeed Insights, wrapped in a report with a history, test locations and monitoring on paid plans. You give it a URL and it gives you a verdict and a list.

WebPageTest is a test rig. It runs your page on real browsers in many locations and on many devices, with free tests subject to limits, and returns filmstrips, waterfalls, first and repeat views, and the ability to change one variable and run again. It gives you evidence, not a grade.

• One page, one verdict: a founder can read the report without learning to read a waterfall.
• A history of runs on the same URL, so a change has a before and an after in one place.
• Scheduled runs and alerts on paid plans, which turn speed into something you notice rather than something you remember to check.
• Test locations, so a page can be judged from where your buyers are rather than from where the tool's default server sits.

The practical use: run /pricing on GTmetrix before and after a change, keep both runs, and let the monitoring tell you the week a new script arrives on the page.

• The filmstrip: what the visitor sees at each moment, which shows a page that paints and then reflows better than any number.
• The waterfall: every request with its timing, so the third-party script that blocks the hero image is visible rather than inferred.
• Connection profiles and devices: the same page over a slow connection on a mid-range phone, which is closer to your worst visitor than your laptop is.
• First view against repeat view: how much of the page a returning visitor gets from cache, which caching changes are meant to improve.
• Runs you tune: change the location, the device or the connection and run again to isolate one variable.

The practical use: your largest element paints at 3.5 seconds and you do not know why. The waterfall shows it was requested late because it is a background image in a stylesheet, and the filmstrip shows the page looking finished two seconds before it arrives.

Both are lab tools. They load your page on their machine, on their connection, at a moment you chose. Google's page experience judgement uses field data: the experience of real Chrome users over a rolling window, at the 75th percentile.

That gap explains the most common confusion in speed work: a lab score of 95 with a Core Web Vitals assessment that still fails. The lab machine is faster than your visitors' phones.

• For the judgement: PageSpeed Insights, which shows field data above its Lighthouse run, and the Core Web Vitals report in Search Console for the whole site.
• For the thresholds: about 2.5 seconds for Largest Contentful Paint, 0.1 for Cumulative Layout Shift, 200 milliseconds for Interaction to Next Paint.
• For interaction: neither lab tool can click your page, so neither measures Interaction to Next Paint. They report a lab proxy instead.

1. 1

   Confirm the page is slow for real people

   Open PageSpeed Insights on the URL and read the field section first. If it passes, your lab score is a hobby, not a problem.

2. 2

   Get the verdict and the list

   Run GTmetrix from the location closest to your buyers. Note the largest saving it names and keep the run.

3. 3

   Find the cause

   Run WebPageTest on the same URL with a mid-range phone and a slow connection. Read the filmstrip for when the page looks done, then the waterfall for what arrived after that.

4. 4

   Change one thing

   Fix the single request the waterfall accuses: the lazy-loaded hero, the render-blocking stylesheet, the chat widget loaded before the content.

5. 5

   Prove it

   Rerun both tools with the same settings. Then wait for the field data to catch up before you claim the win, because it is measured over a rolling window of real visits.