Tools & Experiments

This hub covers how to use free diagnostic tools correctly, and how to avoid treating a single test result as proof of anything. PageSpeed Insights, Chrome DevTools, and Query Monitor each answer a different question, and combining them correctly matters more than trusting any one report in isolation.

PageSpeed Insights: field data and lab data together
PageSpeed Insights combines real-user field data (from the Chrome UX Report) with simulated lab data (from Lighthouse) in one report. These frequently disagree, and that’s expected: field data reflects real visitor experience, while lab data is a single, reproducible test useful for investigating a specific problem.

Chrome DevTools Performance panel
DevTools records a detailed, local trace of network activity, main-thread execution, and rendering work for one specific page load or interaction. It can help identify scripts, tasks, layout work, and request timing associated with a slowdown, but the recording still represents the tested browser, page state, and interaction rather than every visitor.

Query Monitor
Query Monitor is a real-time execution inspector for WordPress’s server side: database queries, PHP errors, hooks, and HTTP requests, attributed to a specific plugin or theme. It identifies and attributes problems; it does not fix them.

Browser diagnostics versus WordPress diagnostics
Chrome DevTools shows what happens in the browser after content arrives; Query Monitor shows what happens on the server before it’s sent. A complete diagnostic picture often needs both, since a slowdown can originate in either place independently.

Server-side versus client-side evidence
A slow database query and a slow front-end script look identical to a visitor, “the page is slow,” but require entirely different fixes. Identifying which side of the request a problem actually originates from is a prerequisite for choosing the right tool and the right fix.

Choose representative test targets
Do not test only the homepage. Select representative articles, archives, landing pages, logged-in screens, and dynamic actions that matter to the site’s users. Record whether the request was cached, which account state was used, and which interaction was performed. A tool can only describe the page and conditions it observed, so a clean result on one template does not clear every other template, plugin path, or administrative workflow.

Field data versus synthetic tests
A synthetic, single-run test reflects one specific scenario. Field data, where sufficient eligible data exists, shows aggregated patterns from real visitor conditions. Neither replaces the other: field data helps establish observed user experience, while controlled tests help investigate causes. A missing field report is not evidence that a problem does not exist.

Controlled experiments, baselines, and repeated testing
Record a documented baseline before making any change, test one variable at a time, and run each test more than once, since normal variance in network and server conditions can make a single result misleading. Testing several changes simultaneously makes it impossible to know which one actually mattered.

Keep evidence that can be compared
Save the URL, timestamp, device or throttling profile, cache state, login state, plugin state, and relevant screenshots or trace files. Repeat the same procedure after the change. This record makes rollback decisions easier and prevents a later test under different conditions from being presented as a direct before-and-after comparison.

Correlation versus causation
A change followed by an apparent improvement is not automatically proof that the change caused it. This is especially relevant when investigating a suspected slow plugin: deactivating one plugin and feeling a difference isn’t the same as confirmed evidence from a documented, repeated test.

Recommended diagnostic workflow
Start with How to Use PageSpeed Insights for WordPress Without Misreading the Results to separate available field evidence from the lab report. Use Chrome DevTools Performance Panel for WordPress for browser-side investigation and Query Monitor for WordPress for WordPress-side attribution. When evidence points to hosting or infrastructure, add server and host-level monitoring rather than forcing a browser tool to answer a server question.

Published guides versus future SitePulse Labs tools
The guides in this category currently cover how to use established, free third-party tools correctly. SitePulse Labs does not currently operate an in-house testing tool or benchmarking service; any future tool developed by this publication will be clearly introduced as such, distinct from the third-party tool guides published today.

Related categories
These diagnostic techniques apply directly to the topics covered in WordPress Speed and Core Web Vitals, and the overall research approach behind these guides is described in Methodology.

A note on scope
This category currently includes three published guides, one for each major free diagnostic tool. As additional tools or techniques are covered, they will be added here following the same standard: explaining how to use an established tool correctly, not claiming an original benchmark.