WordPress Page Speed Test: How to Properly Measure Your Site’s Performance

Why most WordPress speed tests are misleading

You run your homepage through PageSpeed Insights, see a green 92, and assume your site is fast. Three months later, your traffic drops 15% and you can’t work out why. The problem? That single test told you almost nothing about how your site actually performs for real visitors.

Most site owners make the same three mistakes when testing speed. They test a single page (usually the homepage, which is often the lightest). They run one test and take the result at face value. And they test on their fast office broadband, not on a throttled mobile connection that mirrors real-world conditions.

Speed testing is a skill. Done properly, it reveals exactly where your site is losing time and what to fix first. Done poorly, it gives you false confidence or sends you chasing the wrong problems. After running performance audits on over 150 WordPress sites, I’ve developed a testing methodology that consistently surfaces the real bottlenecks. Here’s exactly how to replicate it.

Google PageSpeed Insights: your starting point

PageSpeed Insights (PSI) is where most people start, and it’s a reasonable first step — but you need to understand what it’s actually telling you. PSI gives you two distinct data sets: lab data and field data. Most people only look at the overall score. That’s the lab data score, and it can be misleading.

Lab data is generated by running Lighthouse on Google’s servers with a simulated Moto G Power on a throttled 4G connection. It’s consistent and reproducible, which makes it useful for debugging — but it doesn’t reflect what your actual visitors experience. Lab scores can vary by 5–10 points between consecutive runs on the exact same page.

Field data comes from the Chrome User Experience Report (CrUX) — real performance metrics collected from real Chrome users who visited your site over the previous 28 days. If your site has enough traffic (roughly 1,000+ page views per month in Chrome), PSI will show field data at the top of the results. This is the data Google actually uses for ranking.

What to focus on: Look at the three Core Web Vitals metrics in the field data section first. LCP (Largest Contentful Paint) measures loading speed — aim for under 2.5 seconds. INP (Interaction to Next Paint) measures responsiveness — aim for under 200 milliseconds. CLS (Cumulative Layout Shift) measures visual stability — aim for under 0.1. If all three are green in the field data, your site passes Google’s page experience signals regardless of what the lab score says.

How to use it properly: Don’t just test your homepage. Test your five most-visited pages (check Google Analytics), test a blog post, test a category archive, and test your contact or conversion page. The results will often vary dramatically — I’ve seen sites with a homepage scoring 95 and inner pages scoring 40 because of heavy shortcodes or unoptimised featured images.

GTmetrix: the waterfall is everything

GTmetrix runs Lighthouse under the hood, so the performance score will be similar to PSI. The real value is in GTmetrix’s waterfall chart — it shows you every single HTTP request your page makes, in chronological order, with colour-coded bars showing DNS lookup, connection time, TLS handshake, time to first byte, and content download for each request.

How to read the waterfall: Look for three things. First, find the longest bars — these are your biggest bottlenecks. A single slow third-party script (Google Tag Manager, Facebook Pixel, a chat widget) can block everything that loads after it. Second, look for request chains — resources that can’t start loading until another resource finishes. These sequential dependencies destroy load time. Third, count the total requests. If your page makes more than 60 HTTP requests, you have bloat.

The filmstrip view is equally valuable. It shows you screenshots of your page at 500ms intervals during loading. You’ll see exactly when your content becomes visible, when images appear, and whether anything shifts around during loading. If your main content isn’t visible until after 3 seconds, you have a rendering problem even if the page technically “finishes” loading at 4 seconds.

Pro tip: Change the test location to match where your visitors are. If your audience is primarily in the UK, test from London — not the default Vancouver server. GTmetrix’s free tier lets you test from 7 locations.

WebPageTest: the professional’s tool

WebPageTest is the most powerful free testing tool available, but its interface intimidates most people. It’s worth learning because it reveals things no other tool shows you.

Connection throttling: WebPageTest lets you simulate real network conditions — 3G, slow 4G, fast 4G, or cable. Run your test on “Mobile – Regular 4G” to see what your mobile visitors actually experience. The difference between a cable test and a 4G test is often 3–5 seconds of additional load time.

First view vs repeat view: WebPageTest automatically runs two tests — the first visit (empty cache) and a repeat visit (cached resources). If there’s a huge gap between them, your caching strategy needs work. A well-cached WordPress site should load 50–70% faster on repeat visits.

Multi-step tests: You can script WebPageTest to navigate through multiple pages — load the homepage, click a link, fill out a form. This reveals performance issues that only appear during actual user journeys, not just single page loads.

Key metrics to check: Focus on Start Render (when the browser first shows something — anything — on screen), Speed Index (how quickly content is visually populated), and Fully Loaded (when all resources including lazy-loaded images and deferred scripts have completed). A good WordPress site should hit Start Render under 1.5 seconds on 4G and Fully Loaded under 4 seconds.

Chrome Lighthouse: test from your own machine

Lighthouse is built into Chrome DevTools. Press F12, click the Lighthouse tab, select “Mobile” and “Performance”, and hit “Analyze page load”. The advantage over PSI is that Lighthouse runs locally, so you can test staging sites, password-protected pages, and localhost environments.

The six performance metrics Lighthouse measures are: First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT — which correlates with INP in the field), Cumulative Layout Shift (CLS), Speed Index, and Time to Interactive (TTI). Each one measures a different aspect of the loading experience, and each maps to specific optimisations.

Important caveat: Lighthouse scores from your local machine are not directly comparable to PSI scores. Your laptop probably has a faster CPU and SSD than Google’s test servers. Lighthouse scores run locally are typically 10–20 points higher than PSI. If you score 85 locally, expect 65–75 on PSI. Use local Lighthouse for debugging and iterating, but always validate with PSI before declaring victory.

How to get consistent results: Close all other Chrome tabs. Disable all browser extensions (use an Incognito window). Run the test three times and take the median score. A single Lighthouse run can vary by 5–15 points due to CPU throttling inconsistencies, network fluctuations, and background system processes.

Google Search Console Core Web Vitals: what actually matters for SEO

If you care about rankings — and you should — the Core Web Vitals report in Google Search Console is the most important speed report you’ll ever check. This shows you exactly how Google classifies your pages: Good, Needs Improvement, or Poor.

Navigate to Experience > Core Web Vitals in Search Console. You’ll see separate reports for mobile and desktop. Each page is grouped by similar URL patterns, and each group shows its LCP, INP, and CLS status based on the 75th percentile of real user experiences over the previous 28 days.

Why the 75th percentile matters: Google doesn’t use averages. They use the 75th percentile — meaning 75% of your visitors must experience good performance for a URL group to pass. If 30% of your visitors get an LCP over 2.5 seconds, that URL group fails LCP even if the median is fine. This means you can’t just optimise for the best case. You need to optimise for the slowest realistic scenario — visitors on older phones, slower connections, and further from your server.

What to do with this data: Fix “Poor” URL groups first — these are actively hurting your rankings. Then tackle “Needs Improvement” groups. Click into any group to see which specific URLs are affected and which metric is failing. Cross-reference with PSI to see the lab diagnostics for those pages, then fix the underlying issues.

CrUX: the raw field data behind it all

The Chrome User Experience Report (CrUX) is the dataset that powers both PSI’s field data and Search Console’s Core Web Vitals report. You can access it directly through the CrUX API, CrUX Dashboard (a free Looker Studio template), or BigQuery for advanced analysis.

The CrUX Dashboard is the most accessible option. Enter your domain and it generates a 13-month trend report for every Core Web Vital metric. This is invaluable for tracking progress over time — you can see whether your optimisation efforts are moving the needle in the field, not just in lab tests.

When CrUX doesn’t have data: If your site gets fewer than roughly 1,000 monthly Chrome page views, CrUX won’t have enough data to generate field metrics. In this case, you’re relying entirely on lab data until traffic builds. Focus on getting lab scores as high as possible and trust that good lab performance generally translates to good field performance — though not always, especially if your visitors are on older devices or slower networks.

The right testing methodology

Here’s the exact process I follow for every VeloPress performance audit. It takes about 30 minutes and gives you a comprehensive picture of your site’s real performance.

Step 1: Identify your test pages. Pick at least five: your homepage, your highest-traffic landing page (check Analytics), a blog post with images, a category or archive page, and your most important conversion page (contact form, checkout, pricing). These represent different template types and content weights.

Step 2: Run each page through PSI three times. Take the median score. Note any field data if available. Record LCP, INP, CLS, and TTFB for each page. If scores vary by more than 15 points between runs, something is unstable — possibly a slow third-party script or a server with inconsistent response times.

Step 3: Run your worst-performing page through GTmetrix. Set the location to match your primary audience. Read the waterfall. Identify the top three bottlenecks by request duration and size.

Step 4: Run a WebPageTest on mobile 4G. Compare first view and repeat view. Check Start Render time. Note total request count and page weight.

Step 5: Check Search Console Core Web Vitals. Identify any Poor or Needs Improvement URL groups. Cross-reference failing pages with your PSI results.

Step 6: Document everything. Create a simple spreadsheet: page URL, PSI score (mobile), LCP, INP, CLS, TTFB, total page weight, total requests. This is your baseline. After making changes, re-test the same pages with the same tools to measure improvement.

Common speed testing mistakes

I see these errors constantly. Each one gives you a false picture of your site’s performance and leads to wasted effort on the wrong optimisations.

Testing with an ad blocker enabled. Ad blockers remove third-party scripts, which can improve your score by 20–30 points. If you test with uBlock Origin running and then compare to PSI (which doesn’t use an ad blocker), you’ll wonder why your scores don’t match. Always test in a clean browser profile with no extensions — use Chrome Incognito mode.

Testing from browser cache. If you’ve visited your site recently, many resources will be cached. Your test will show a fast, cached load — not the first-visit experience that most new visitors will have. Always clear cache before testing, or use PSI/GTmetrix which test from a clean state automatically.

Only testing the homepage. Your homepage is usually the lightest, most optimised page on your site. Inner pages — especially blog posts with multiple images, archive pages with 10+ post cards, or WooCommerce product pages — are almost always slower. If you only test the homepage, you’re ignoring where most users actually land.

Ignoring mobile. Over 60% of web traffic is mobile. Google uses mobile-first indexing. If your desktop score is 95 but your mobile score is 55, your mobile score is the one that matters. Always prioritise mobile performance over desktop.

Chasing a perfect 100. A PageSpeed score of 100 is a vanity metric. The difference between 95 and 100 is imperceptible to users. The difference between 40 and 80 is enormous. Focus your effort where it has the biggest impact — getting failing Core Web Vitals into the “Good” range — rather than squeezing out the last 5 points.

Now you know your score — here’s how to improve it

Testing is only useful if you act on the results. Now that you know how to properly measure your site’s performance, the next step is fixing what you’ve found.

If your biggest issue is high TTFB (over 600ms), the problem is your server — read our comprehensive WordPress speed optimisation guide for the full picture. If you’re seeing slow LCP due to heavy images, unoptimised CSS, or render-blocking JavaScript, the fixes are content-delivery and frontend optimisation issues that we cover across our diagnostics guide and server-level fixes guide.

The testing methodology above will tell you exactly which pages need attention and which metrics are failing. Prioritise by impact: fix pages that get the most traffic first, and fix the metric that’s furthest from its target first.