Performance impact
Before-and-after page-speed comparison around a change — what it measures, and what it deliberately does not.
When something changes on your site, ChangeTrace can compare how fast your pages loaded before and after it. A plugin that adds 800ms to your largest paint is worth knowing about whether or not it also dented sales.
What is measured
Standard web performance metrics:
| Metric | In plain terms |
|---|---|
| LCP — Largest Contentful Paint | How long until the main content appears |
| INP — Interaction to Next Paint | How quickly the page responds to a click or tap |
| CLS — Cumulative Layout Shift | How much the page jumps around while loading |
| TTFB — Time to First Byte | How long your server takes to start responding |
This is lab data, not your real visitors
ChangeTrace measures your public pages itself, using Google PageSpeed Insights, on a simulated mobile device. It does not run anything in your visitors' browsers — there is no tracking script and no beacon.
That means the numbers are consistent and comparable over time, which is exactly what a before/after comparison needs. It also means they are not what your actual customers experienced on their own phones and networks. Treat a change in the number as a real signal about your site, and the absolute value as an indication rather than a measurement of lived experience.
How the comparison is built
A change happens
A plugin updates, a theme changes.
The window before
Measurements from the 24 hours before the change become the baseline.
A settling period
A short pause after the change, so a half-finished update is not measured mid-flight.
The window after
The next 24 hours of measurements become the comparison.
The verdict
Each metric gets a before value, an after value, a percentage change and a rating — unchanged, minor, moderate or significant. Confidence depends on how many measurements went into it.
Expect about 24 hours
Because it needs a full day of measurements after the change, a performance impact will not appear immediately. A plugin updated this morning is judged tomorrow. Changes older than 30 days are not analysed at all.
Where it appears
- Incident page — as supporting evidence, when a change linked to the incident has one
- Event detail — on the change event itself
Both carry the same footer: "Shown as correlated evidence — not proof this change caused the incident."
Why yours might be empty
You are on the Free plan. Performance impact is a paid feature. Plans and limits →
Not enough time has passed. Roughly 24 hours after the change.
Too few measurements. A comparison with insufficient samples is discarded rather than reported with false confidence.
Your site is not publicly reachable. Pages behind a login or an IP allow-list cannot be measured from outside.
What it will not tell you
- Which page. Measurement targets your public pages, not a specific product or checkout URL.
- Real-visitor experience. Lab data, as above.
- Causation. A slower LCP after a plugin update is correlation. The update is the first thing to test, not a proven culprit.
{ }For developers
Server-side synthetic measurement, opt-in per deployment: PERF_SOURCE=psi plus PSI_API_KEY,
with collection gated on PERF_COLLECT_ENABLED (default off) and PERF_COLLECT_PAID_ONLY
(default on). Defaults: every 6 hours per site, mobile, 25 sites per run, 30 days of raw-sample
retention. Raw samples roll into hourly performance.* metrics, which the impact analyser
compares around each change; a failed or rate-limited measurement stores nothing rather than
guessing. Dashboard routes are gated behind the performance_impact plan feature.