writing/ai workflows/The Website Performance Testing Tools I Actually Use
contents

The Website Performance Testing Tools I Actually Use

No single tool tells you the whole truth about web performance. Here's the working set — pagespeed, webpagetest, crux, RUM — and what each is actually good for.

There's no single tool that tells you the whole truth about your site's performance. Lighthouse will lie to you about field data. Pagespeed insights will lie to you about lab data. Webpagetest will tell you the truth but make you work for it. You need a handful of these, used for the right thing.

Here's the working set I actually open when something feels slow, and what each one is good (and bad) at.

Pagespeed Insights

pagespeed.web.dev

Google's public-facing wrapper around lighthouse plus crux field data. Paste a url, get a score, get core web vitals from real chrome users (if your site has enough traffic to be in the crux dataset).

Use it for: A quick sanity check on a production url, and — more importantly — seeing the 28-day field data for LCP, INP, and CLS. That field data is what actually affects search ranking. The lab score is theater.

Don't use it for: Comparing runs. The lab portion is a single run on google's infra and the variance is brutal. Don't celebrate going from 78 to 84.

Lighthouse in DevTools

Built into chrome devtools, "Lighthouse" tab. Same engine as pagespeed insights but runs locally against your machine and network.

Use it for: Auditing staging environments, localhost, or anything behind auth. The "treemap" view of unused javascript is genuinely useful for finding bundle bloat.

Don't use it for: Absolute numbers. Your m3 max on gigabit fiber is not your user on a pixel 6a on spotty LTE. Always run with throttling on, and run it several times.

WebPageTest

webpagetest.org

The serious tool. Catchpoint owns it now but the free tier is still generous. Real devices, real locations, real browsers, real network conditions. Waterfall view, filmstrip, connection view, the works.

Use it for: Deep dives. When LCP is bad and you don't know why, the waterfall + filmstrip side-by-side will show you exactly which request is blocking the hero image. Also the only one of these tools that does meaningful multi-run statistics out of the box (median of 9 runs, etc).

Don't use it for: Quick checks. There's a queue. Results take a minute or two. The UI is dense. It's not the tool you reach for to confirm a one-line fix.

Chrome DevTools Performance Panel

Not a site, but it belongs on this list. Record a session, get a flame chart, find the long tasks blocking your INP.

Use it for: Diagnosing interactivity problems. INP is now a core web vital and lighthouse can't really tell you why a click feels janky — only the performance panel can, by showing you the actual task that ran for 340ms on the main thread.

Don't use it for: Anything you'd share with a non-engineer. The output is for you.

GTmetrix

gtmetrix.com

Predates pagespeed insights as a public tool. These days it's a hosted lighthouse + their own waterfall, with the option to test from different regions and devices on paid plans.

Use it for: If you like its report format, or if you need historical tracking on a budget and don't want to set up your own. The free tier tests from canada on desktop chrome, which is a fine default.

Don't use it for: Anything pagespeed insights or webpagetest don't already do better. It's fine. It's just not differentiated anymore.

Treo, DebugBear, SpeedCurve

treo.sh, debugbear.com, speedcurve.com

The paid continuous-monitoring tier. You point them at your urls, they run lighthouse/webpagetest on a schedule from multiple locations, and you get charts over time, alerting on regressions, and pr-level diffs if you wire it up.

Use it for: Any site where performance is part of the business. You cannot manage what you don't measure, and running lighthouse by hand once a month is not measuring.

  • SpeedCurve is the most polished, the most expensive, and the one large teams pick.
  • DebugBear is the best price/feature ratio right now — solid waterfall, good github integration, sane pricing.
  • Treo is the lightweight option, basically a nicer webpagetest dashboard.

Don't use it for: One-off audits. These are subscriptions; pay for them when you have something worth protecting.

CrUX Dashboard

Chrome UX Report on Looker Studio

A free looker studio template that pulls the public crux dataset for any origin. Trends for LCP, INP, CLS, FCP, TTFB across desktop and mobile, month over month.

Use it for: Seeing whether your real users' experience is actually getting better over the last 12 months, not just whether your lighthouse score went up. This is the closest thing to ground truth google will give you for free.

Don't use it for: New or low-traffic sites. No crux data means an empty dashboard.

Your Own RUM

web-vitals.js, or vercel speed insights, or cloudflare web analytics, or sentry performance.

Real user monitoring from your actual users. The web-vitals library is ~2kb and you can pipe it to whatever analytics endpoint you already have.

Use it for: The truth. Crux is sampled and 28-day-aggregated. Your own RUM is every session, every device, every network. If your p75 LCP in RUM is 4.2s and lighthouse says 1.8s, the lab is wrong and your users are right.

Don't use it for: Debugging individual sessions, unless you wire up something heavier like sentry that records the actual long tasks and resource timings.

What I Actually Do

A quick mental flowchart for the next time something is slow:

  1. Is it slow for users, or slow in a tool? Check crux / your RUM first. If users are fine, stop. Don't optimize phantom problems.
  2. If users are slow, reproduce it. Webpagetest from a location and device that matches the affected users. Get a waterfall and a filmstrip.
  3. Form a hypothesis, fix it locally. Chrome devtools performance panel + lighthouse on localhost with throttling on.
  4. Verify in staging with webpagetest again. Same config as step 2. Compare medians of 5+ runs.
  5. Watch crux for the next 28 days. Field data is the only score that matters.

The mistake I see most often is step 1 getting skipped. Someone runs pagespeed insights on the homepage, sees a 67, and spends a sprint chasing it — while the actual users on the actual checkout page are fine. Lab scores are a diagnostic, not a goal.

Pick two tools from this list and learn them well. Webpagetest plus your own RUM will cover 90% of real work.

APA

Sze. (2026, May 15). The Website Performance Testing Tools I Actually Use. CTRLSZE. https://ctrlsze.studio/blog/the-website-performance-testing-tools-i-actually-use

URL

https://ctrlsze.studio/blog/the-website-performance-testing-tools-i-actually-use

BibTeX
@misc{ctrlsze-the-website-performance-testing-tools-i-actually-use-2026,
  author = {Sze},
  title  = {The Website Performance Testing Tools I Actually Use},
  year   = {2026},
  month  = {May},
  url    = {https://ctrlsze.studio/blog/the-website-performance-testing-tools-i-actually-use},
  note   = {CTRLSZE}
}