Running a speed test and not understanding the output is a frustrating exercise. Different tools measure different things, and the number that matters most depends on what you are actually trying to fix. Here is what each tool measures, how to read the results, and what to prioritise when you find a problem.
PageSpeed Insights is the most important tool for WordPress site owners because it measures the metrics Google uses as ranking signals. These are the Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP, which replaced First Input Delay as the responsiveness metric), and Cumulative Layout Shift (CLS). The targets are LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1.
PageSpeed Insights shows two types of data. Lab data is collected by testing from Google's servers on a simulated mobile and desktop device, it is a snapshot of how your site performs in a controlled environment right now. Field data (the Chrome User Experience Report, or CrUX) is aggregated from real Chrome users visiting your site over the past 28 days. Field data requires enough traffic to have data and uses actual user devices and connections. Google uses field data for ranking; lab data is a diagnostic tool to help you understand what to fix.
A PageSpeed score of 90+ is good, but do not optimise for the composite score. A site can score 95 and still have a poor LCP on mobile if one large image is not correctly lazy-loaded. Look at the individual Core Web Vital values and the "Opportunities" and "Diagnostics" sections, which give specific, actionable recommendations like "Eliminate render-blocking resources" or "Properly size images." Each recommendation links to documentation explaining how to fix it.
Test both mobile and desktop tabs. Mobile scores are lower than desktop on almost every site because PageSpeed simulates a slower 4G connection on mobile. Google weights mobile more heavily for ranking. If your mobile LCP is 4.5 seconds and desktop is 1.8 seconds, the mobile number is what needs attention.
GTmetrix provides a waterfall chart, a visual timeline showing every resource the browser requests when loading the page. Each row represents one resource: the HTML document, each CSS file, each JavaScript file, each image, each font, each API call. The horizontal bars show when each request started, how long the connection took, how long the download took, and when the browser processed it. This is the most useful view for diagnosing specific slow resources.
The key metrics in GTmetrix: TTFB (Time to First Byte) appears as the initial wait on the first HTML request, this is your server response time. Fully loaded time is when all resources including deferred and lazy-loaded assets finish. Total page size and request count are shown in the summary, aim for under 1MB total page weight and under 50 requests for a lean, well-optimised page.
The waterfall reveals specific problems that PageSpeed scores alone do not identify. A long yellow bar at the start of the first request is slow TTFB, a server-side problem. A JavaScript file that loads early and has a long orange "executing" bar is blocking page rendering, defer it. Multiple CSS files loading sequentially before any page content appears are render-blocking. A font loading from an external server with a 300ms connection delay would be faster loaded from your own server or preconnected early. GTmetrix lets you run tests from multiple geographic locations, test from the location closest to your actual visitors for the most representative results.
WebPageTest (webpagetest.org) is the most technically comprehensive free testing tool. It runs tests using a real browser on real hardware at specified locations worldwide, which gives more representative results than simulated environments. Configure the test location, browser (Chrome, Firefox, Safari on iOS), connection type (cable, 4G, 3G), and number of test runs. Running three tests and using the median gives you more reliable data than a single test.
The filmstrip view is one of WebPageTest's most useful features. It shows a sequence of screenshots of the page at 100ms intervals, making it easy to see exactly when content first appears visually, when the main content loads, and when the page is fully stable. This visual progression is far more intuitive than millisecond numbers for diagnosing user experience problems. A page that is "loaded" at 2 seconds but visually blank for the first 1.5 seconds has a worse user experience than the load time suggests.
The repeat view test is particularly valuable for evaluating caching. WebPageTest runs the same page twice: once fresh, once with a warm browser cache. Comparing first view to repeat view shows how effective your caching configuration is. A page that loads in 3.2 seconds on first view and 0.4 seconds on repeat view has excellent asset caching. A page where both views are similar indicates that caching is either misconfigured or not working. WebPageTest also includes connection-level waterfall data showing DNS lookup, TCP connection, SSL negotiation, and server response separately, detail that GTmetrix does not expose at this level.
Pingdom Tools (tools.pingdom.com) is the most accessible of the main speed testing tools. It runs a test from a selected location and returns a load time, a performance grade, and a breakdown of content types by size. It is most useful for quick sanity checks, testing whether a change you made improved or worsened load time, rather than deep diagnostic work.
Pingdom's paid monitoring service tests your site on a regular schedule (every minute to every hour, depending on plan) and sends alerts when the site is down or response time exceeds a threshold. This continuous monitoring is where Pingdom's value lies for production sites. For diagnostic work, GTmetrix and WebPageTest provide substantially more actionable data.
Time to First Byte is the time between a browser sending a request for a page and receiving the first byte of the server's response. It measures server-side performance exclusively: how long PHP took to execute, how long database queries took to complete, whether a cached response was served, and the network round-trip time to the server. TTFB is what your hosting directly controls, a slow TTFB cannot be fixed by image compression, CSS minification, or JavaScript deferral.
Target values: under 200ms is good for an uncached page. Under 100ms is excellent. Under 50ms on a cached page is achievable on LiteSpeed hosting with server-level caching enabled. Over 500ms is a server-side problem that requires investigation, slow PHP execution, slow database queries, insufficient server resources, unoptimised WordPress configuration, or significant geographic distance between the test location and the server.
In a waterfall chart, slow TTFB appears as a long yellow "waiting" bar at the start of the first HTML request, before anything else in the waterfall. If this bar is 600ms, you have a server problem. Everything else in the waterfall, image sizes, JavaScript defer settings, font loading, is a secondary concern until TTFB is addressed. No front-end optimisation compensates for a slow server response. Fix TTFB first, then optimise front-end assets.
Start with TTFB. If TTFB is above 300ms on a cached page, the server is slow. Check whether your caching plugin is working, load the same page twice and see if the second request is faster (which indicates a cache hit). If both requests have similar TTFB, caching is not functioning. Verify your caching plugin is configured correctly, there are no cache exclusion rules incorrectly bypassing the cache, and the server supports the caching method you are using.
If TTFB is acceptable but LCP is slow, the problem is front-end: a large hero image that is not compressed or lazy-loaded, render-blocking CSS or JavaScript preventing the browser from painting content, or a Google Font loading slowly from an external server. Run PageSpeed Insights on the specific page with a poor LCP and follow its specific recommendations.
If CLS is poor, elements are shifting position after the page loads. Common causes include images without width and height attributes (the browser does not reserve space for them and they push content when they load), ads that load after page content and push elements down, and web fonts that cause a layout shift when they replace the fallback font. PageSpeed Insights flags these specifically.
One important testing habit: always test pages that are representative of real user experience, not just the homepage. A WordPress homepage may be heavily optimised while category archives and single posts have much worse scores. Test the pages that receive the most traffic from search engines, which are typically post or product pages rather than the homepage.
HostBible's LiteSpeed hosting serves cached WordPress pages with sub-100ms TTFB. Server-level caching is included on all plans, no extra plugin configuration required to get fast response times.
View Hosting Plans