Understanding Your Results

The site score

100 minus penalties for findings (critical findings cost more than warnings). Methodology sets out exactly how the numbers are produced. Above 80: healthy. 50-80: real problems worth fixing. Below 50: your visitors are feeling it.

Finding types

• Slow query – one query over 50ms, attributed to a plugin/theme, with its shape classified: wp_postmeta scans, SQL_CALC_FOUND_ROWS, ORDER BY rand(), leading-wildcard LIKE, nested taxonomy joins. The shape drives the recommendation.
• Large result set – a query fetching 200+ rows. Every row is hydrated into PHP memory, so these are the usual cause of high RAM per visit.
• Queries in a loop (N+1) – one component running 50+ queries on a page. The count grows with your content, so this gets worse every month.
• Duplicate queries – the same query byte-for-byte, run repeatedly in one page load. The component is missing basic caching.
• Blocking HTTP call – a plugin calls a remote server while your page renders (licence checks, geo lookups). Every visitor waits for it.
• Ignores the object cache (cache-blind) – from a Cache Impact run: the plugin runs identical queries with Redis on and off. Your caching investment does nothing for it.
• Slow email construction – building an email blocked the request; order status changes and checkout wait on this.
• Sets a cookie for new visitors – a plugin or theme sets a cookie on the response to a visitor who arrived without one (a tracker setting _fbp on init, for example). The finding names the plugin, its version, the hook and the function, and the pages. A page cache that refuses responses carrying Set-Cookie will not store those pages for new visitors, so first visits are never cached while your own browser, which already has the cookie, sees a healthy cache. The finding then says what the Cache performance check actually observed on this site (served from cache or not), because some caches store or strip such responses. The plugin’s row on the Plugins tab carries a “sets a cookie for new visitors” badge.
• Autoloaded options bloat / environment findings – site-level issues: options loaded on every request, outdated PHP, missing object cache on a large database.

Inferred vs measured

Attribution from query backtraces is inferred – accurate, but circumstantial. Plugin Impact Analysis upgrades suspects to measured: the page is re-profiled with the plugin virtually disabled for the test requests only, and the difference is the plugin’s proven cost. Anything below the measurement noise floor is honestly reported as “no measurable impact” – the plugin is not guilty on this site, whatever its reputation.

A measured impact can be negative – shown as “saves Xms” in green. That means the page got slower when the plugin was excluded: the plugin is actively speeding your site up. This is normal for performance plugins that replace a slow core or WooCommerce feature (search, filtering, archives).

The attribution trap (read this before blaming a plugin)

The SQL/query columns credit work to whichever component runs it. A plugin that replaces a slow feature – say a search plugin that takes over product or order search – runs the search query itself. The search time then appears under its name, while the slow native code it replaced does not run at all and is credited to nobody. On the attribution columns alone, the plugin making your search fast can look like your biggest SQL spender.

The Measured impact column is the antidote: it compares the real page with and without the plugin. If a plugin’s attribution looks expensive, click Measure and trust the measured verdict – “adds” means it genuinely costs you time, “saves” means it is earning its keep.

Special pages

• baseline – a near-empty request measuring your server’s noise floor.
• mail-probe – the cost of building (not sending) an email through your mail stack.
• write-save-product / write-order-processing – opt-in: the full save/status-change hook cascade, measured against temporary objects that are deleted immediately after.

Reading AJAX comparisons

The AJAX tab compares requests captured in named Before and After windows. Each point is a retained request; successful-request median and p95 are separate from failed responses. The timing covers server work from MU observer entry to shutdown, not browser elapsed time.

Compare the same scenario, method, authentication context, environment and instrumentation mode. Select a point to inspect the effective plugins, theme and Scalability Pro policy. If a setup changes within a window, the points remain visible but a combined headline reduction is withheld.

Optional activity sampling distinguishes plugin include work, hook registrations, named-action callback execution and I/O attempts. Coverage is partial, and nested inclusive callback times overlap. Do not add those durations together or treat an empty sample as proof a plugin can be unloaded.

Scalability Pro applies only the exact endpoint rules an administrator enables. Performance Analysis collects evidence; it does not select or unload plugins automatically. A successful HTTP response still needs a functional check of its returned data and the resulting workflow.

Further reading