GTmetrix alternatives for page speed

You want real signals on how fast your page feels on a phone. Start with free tools that show field data, then use lab tests to debug. Here is what to use instead of or alongside GTmetrix, and when to pay for monitoring.

By , founder of Porteur · Updated 13 September 2026 · Markdown

What you can replace from GTmetrix

GTmetrix runs Lighthouse and adds waterfalls, test locations and monitoring on paid plans. You can cover the same jobs for free with two tools most of the time.

  • Field data from real users on mobile: PageSpeed Insights, using the Chrome UX Report on your URL.
  • Quick lab runs as you edit: Lighthouse in Chrome DevTools or PageSpeed Insights.
  • Detailed waterfalls and device profiles: WebPageTest, free tests with limits.
  • Deep diagnosis while coding: the Performance panel in Chrome DevTools.

Keep GTmetrix if you need scheduled monitoring and alerts. If you only test before release and after fixes, you likely do not need a paid monitor yet.

Start with PageSpeed Insights for field data

Use PageSpeed Insights first. It shows real user data when Google has enough visits to your page or origin. This is the simplest way to see if mobile users struggle.

  1. Open PageSpeed Insights

    Go to PageSpeed Insights and paste a full URL, for example https://yourproduct.com/pricing.

  2. Check the Field Data card

    Look for Core Web Vitals on Mobile. If present, it shows real user metrics from the Chrome UX Report.

  3. Read the three vitals

    Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. Note what falls short of the thresholds.

  4. Use the lab report to debug

    Scroll to Opportunities and Diagnostics. These are from a Lighthouse run. Use them to form a fix list.

A fixed page in PSI looks like Mobile field data present, all three vitals in the passing range, and the lab report no longer flags render-blocking files or large LCP images.

Use Lighthouse for fast lab checks while you edit

Lighthouse is the same engine GTmetrix runs under the hood. It is built into Chrome DevTools and PageSpeed Insights. Use it for lab checks as you iterate on code or CMS changes.

  1. Open your page in Chrome

    For example, load /guides/getting-started on your staging site.

  2. Run Lighthouse in DevTools

    Open DevTools, find the Lighthouse panel, choose Mobile, and run an audit.

  3. Compare before and after

    Change one thing, run again. Track LCP element, render-blocking resources and main thread work.

Lighthouse is lab-only. Scores vary between runs. Use it to locate causes, not to claim a final speed number to stakeholders.

Use WebPageTest for waterfalls and devices

When you need a precise waterfall and a realistic device profile, use WebPageTest. It gives you a filmstrip and timing breakdowns, with many locations and devices. Free tests have limits.

  1. Choose a location and mobile device

    Pick a region near your users and a phone profile. Keep it consistent between runs.

  2. Run a single test first

    Check the waterfall for blocking CSS or JS, connection reuse, and third parties delaying LCP.

  3. Inspect the filmstrip

    Confirm when the LCP element appears. Match it to the request in the waterfall.

A fixed page here shows a shorter critical path in the waterfall and the LCP request starting early with good cache and compression headers.

Use Chrome DevTools Performance to find the bottleneck

When Lighthouse says main thread work is high or INP is poor, record a Performance trace in DevTools. It shows long tasks, layout shifts and script costs in detail.

  1. Record a load

    Open the Performance panel and start recording, then reload the page. Stop after it is rendered.

  2. Locate long tasks and shifts

    Look for tasks over 200 ms and layout shift events. Expand the bottom-up view to find the source file or function.

  3. Validate the fix

    Change the code or defer a script. Record again. The long task should be split or gone, and CLS events reduced.

Field data versus lab data, and why it matters

Field data reflects real users, devices, networks and your actual cache headers. Lab data runs a fixed test on a simulated device and network. Both are useful, but for different decisions.

  • Use field data to judge success: are real users passing Core Web Vitals on Mobile.
  • Use lab data to diagnose: which file or script blocks rendering or input.
  • Expect differences: a clean lab run may be faster than a cold mobile user on 4G.

When a paid monitor is worth it

You need monitoring when speed can regress between releases and you must catch it. GTmetrix offers monitoring on paid plans. Many suites also bundle alerts into wider site monitoring.

  • You ship often and cannot manually retest key pages each time.
  • You serve users in multiple regions and want the same test run from each.
  • You report to stakeholders and need consistent, stored runs over time.
  • You rely on many third parties and want alerts when one slows the page.

If you ship weekly or less and have under ten key pages, you can likely get by with PageSpeed Insights and occasional WebPageTest runs. Record your baseline, then retest before and after changes.

A quick comparison of free GTmetrix alternatives

ToolBuilt forField dataWaterfallMobile device profilesMonitoringUse when
PageSpeed InsightsPublic URL checks with Lighthouse plus Chrome UX ReportYes, when available for the URL or originNoNo explicit device pickerNoYou need real-user mobile data and a quick lab report
LighthouseOpen-source lab audits in Chrome and CLINoNoNo explicit device picker in DevTools runNoYou are editing and need fast, repeatable lab runs
WebPageTestDetailed lab tests with filmstrips and many locationsNoYesYes, many device profilesNoYou need to trace the critical path with waterfalls and filmstrips
Chrome DevTools PerformanceIn-depth performance tracing while developingNoTimeline with network detailsNot a device chooser, it profiles the current sessionNoYou must find long tasks, layout shifts and script hot spots

A simple workflow for a small site

  1. Pick your critical pages

    For example, /, /pricing, /signup and your slowest blog template.

  2. Get a baseline

    Run each in PageSpeed Insights. Save screenshots of the Mobile field data and the lab Opportunities list.

  3. Fix the LCP path first

    Optimise the LCP image and remove render-blocking CSS or JS. Validate in Lighthouse and WebPageTest.

  4. Chase layout shift and INP

    Stabilise images and embeds to reduce CLS. Trim main thread work to help INP. Confirm in DevTools Performance.

  5. Recheck field data each month

    Return to PageSpeed Insights and watch Mobile Core Web Vitals. If field data is absent, keep improving and wait for traffic to build.

Side by side

PageSpeed Insights

pagespeed.web.dev

Public URL checks with Lighthouse plus Chrome UX Report field data.

Good at

  • Showing Mobile field data for Core Web Vitals when available
  • Quick lab diagnostics with Opportunities and Diagnostics
  • Simple, shareable reports

Choose it when You want the fastest way to see if real users on mobile pass Core Web Vitals, then get a starter fix list.

Not for Continuous monitoring or deep waterfalls.

Lighthouse

developer.chrome.com/docs/lighthouse/overview

Open-source lab audits in Chrome DevTools, the CLI and PageSpeed Insights.

Good at

  • Repeatable lab testing while developing
  • Highlighting render-blocking resources and main thread work
  • Auditing performance, accessibility and more in one run

Choose it when You are editing code or CMS settings and need tight feedback loops on lab metrics.

Not for Real-user field data or multi-location testing.

WebPageTest

www.webpagetest.org

Detailed lab tests with waterfalls, filmstrips and many locations and devices.

Good at

  • Tracing the critical request path
  • Comparing device profiles and locations
  • Visualising above-the-fold render timing

Choose it when You need to debug LCP, third-party delays or caching using waterfalls and filmstrips.

Not for Field data from real users or integrated monitoring in the free tier.

Chrome DevTools

developer.chrome.com/docs/devtools

In-browser development and profiling with Performance and Lighthouse panels.

Good at

  • Recording long tasks and layout shifts
  • Attributing costs to scripts and styles
  • Debugging interaction delays

Choose it when You must isolate a bottleneck while coding, and validate that a change removed it.

Not for High-level reporting for non-technical stakeholders or field data.

Use PageSpeed Insights first for Mobile field data and a quick lab read. Use Lighthouse in Chrome for fast iteration while you edit. When the numbers do not add up or you need proof of what blocks rendering, run WebPageTest for waterfalls and a filmstrip. Use Chrome DevTools Performance to pinpoint long tasks and layout shifts in code. Add a paid monitor like GTmetrix when you need scheduled runs and alerts across regions that you cannot do manually.

Questions

Sources

Check my site, free

Paste your homepage URL to get a free check in about thirty seconds that reads your site and nearby searches and rivals, and shows three findings you can act on.

  • Free check, no card
  • Read-only, your own accounts
  • Readable by your agent

Read next