One PageSpeed Insights run scores 91. The next scores 76. Nothing on the WordPress site was deliberately changed.
This does not automatically mean the test is unreliable or the website is unstable. A page load depends on cache state, server work, network conditions, third-party services and the moment at which browser work happens. A single score compresses those events into a convenient summary.
The trustworthy result is not always the highest, lowest or latest. It is the set of measurements that represents the visitor condition you are trying to improve.
Separate the score from the underlying metrics
The performance score is calculated from several laboratory metrics. Two runs can have similar visual behaviour but different scores because one metric crossed a weighting curve.
Record the individual values:
- First Contentful Paint;
- Largest Contentful Paint;
- Total Blocking Time;
- Cumulative Layout Shift;
- Speed Index.
Also record:
- tested URL;
- mobile or desktop;
- test time;
- cache indicators;
- Largest Contentful Paint element;
- diagnostics that changed.
Do not compare only the coloured circle.
Field data and laboratory data should not be mixed
Field data is aggregated from eligible real Chrome experiences over time. Laboratory data is a simulated run performed now.
Field values will not change immediately after you refresh the test. Laboratory values can.
Use field data to understand real-user distribution and trends. Use laboratory data to reproduce a page under controlled conditions and inspect a waterfall. A good lab run does not erase poor historical field data, and field data does not prove that today’s deployment is still slow.
A cache miss can produce a different first byte
The first run may generate the WordPress page while the next receives cached HTML.
Inspect response headers outside the score:
curl -I https://example.com/page/Compare age, cache status and first-byte time. If the score variation follows MISS and HIT, the origin path deserves attention.
Do not purge caches between every public test unless you are deliberately measuring origin generation. That answers a different question from normal visitor performance.
Third-party scripts introduce external variation
Consent managers, analytics, chat, maps, video and advertising do not always respond at the same speed. They may also choose different content or run different auctions.
In the waterfall, check whether the slow run contains:
- a delayed third-party response;
- additional requests;
- a timeout or retry;
- more main-thread work;
- a different consent state.
Do not remove a required service because of one slow response. Measure several runs and decide whether it consistently harms the critical journey.
The Largest Contentful Paint element can change
On one run, the hero image may be the largest element. On another, a late heading, cookie banner or carousel slide can become the LCP candidate.
Record the reported element for every run. If it changes, the LCP numbers may not describe the same visual milestone.
Fix unstable priority and layout first. Comparing “hero image LCP” with “cookie banner LCP” as if they were identical can lead to the wrong optimisation.
Server and database work varies
An uncached WordPress request can overlap with:
- cron;
- backup;
- security scan;
- product import;
- WooCommerce scheduled action;
- high traffic;
- MySQL maintenance;
- external API delay.
If first-byte time varies, align test timestamps with server and job logs. A page-level score cannot identify which background task held the resource.
Test location and route matter
Even with a fixed nominal test location, network routing and CDN edge state can vary. A CDN edge may be warm for one run and cold for another.
Record CDN cache headers. If your visitors are geographically distributed, use more than one representative location rather than trying to eliminate every network difference from a single lab.
Run a small sample and use the median
For a meaningful comparison, run the same URL under the same configuration several times—often five is enough for an initial diagnostic.
Sort each metric and use the middle value. Do not average a failed run into silence, however. Keep the range and inspect outliers.
For example:
| Run | LCP | First byte | Cache |
|---|---|---|---|
| 1 | 3.4 s | 1.6 s | MISS |
| 2 | 1.9 s | 0.3 s | HIT |
| 3 | 2.0 s | 0.3 s | HIT |
| 4 | 2.1 s | 0.4 s | HIT |
| 5 | 2.0 s | 0.3 s | HIT |
The median represents a warm visitor, while the first run reveals an origin/cache problem. Both are useful; they answer different questions.
Keep test conditions written down
A comparison is weak if the configuration is remembered rather than recorded.
Store:
- URL and redirect destination;
- date and timezone;
- mobile/desktop mode;
- tool and version where available;
- consent state;
- login state;
- cache state;
- relevant deployment version.
This prevents a future desktop test from being presented as proof that a previous mobile regression was repaired.
Use a control URL
Test one stable, representative page alongside the page being changed.
If both pages become slower in the same run, the variation may belong to the test route, server or shared third party. If only the changed page moves, inspect its assets and template.
The control should use similar infrastructure but not the feature under investigation.
Do not optimise for the worst isolated run
The lowest score attracts attention, but an outlier needs explanation.
Investigate it when:
- the same failure appears repeatedly;
- it matches real-user reports;
- it represents an important first visit;
- it exposes a timeout or unsafe dependency;
- field data shows a similar tail.
Do not rebuild the site because one run encountered temporary external latency. Conversely, do not discard a recurring slow tail because most runs are fast.
Compare distributions after a change
Before and after optimisation, use the same test method and compare:
- median;
- range;
- cache-miss result;
- cache-hit result;
- affected Core Web Vital;
- page functionality.
A change that improves the median but creates occasional 10-second failures is not necessarily better.
PageSpeed is not a checkout or form monitor
Even stable scores do not verify dynamic business actions. Test forms, WooCommerce cart, checkout, account and administrator actions separately.
If the complaint concerns a click or server request after load, record that journey in browser developer tools. Do not wait for the page-load score to describe it.
A practical decision rule
Trust:
- field data for real-user trends and percentiles;
- the median of controlled lab runs for repeatable comparison;
- cache-miss tests for origin health;
- traces and waterfalls for diagnosis;
- journey timings for forms, checkout and interactions.
No single one replaces the others.
Evidence for a variable-score assessment
Provide several test URLs/results, mobile or desktop mode, timestamps, cache headers and the real visitor symptom. Add a dated note of deployments, configuration changes and third-party additions. Credentials are not part of this evidence pack and should not be submitted through the first contact.
If PageSpeed scores change substantially between runs, we can separate normal variation from cache, server, asset or third-party instability. The repair target will be the recurring condition behind the variation, not a promise to reproduce one attractive number.