If your PageSpeed field panel passes but a menu, filter or checkout still feels slow, the observations need not contradict each other. Check the report scope and the affected action separately. A green laboratory performance score is also a different result from passing field Core Web Vitals.
Both observations can be true.
A passing result means the measurements represented in that report meet specific thresholds. It does not certify every page, every visitor or every action on the website. PageSpeed is evidence, but it is not a complete acceptance test for a WordPress business journey.
The next step is not to chase a higher score. It is to name the delay the score did not capture.
Understand what the report actually represents
PageSpeed Insights may show field data, laboratory data or both.
Field data comes from eligible real Chrome visits and is aggregated over time. Depending on traffic volume, it may describe the exact URL or the wider origin. Laboratory data is one simulated page load under controlled conditions.
Before reading the colour, check:
- whether field data is available;
- whether it is URL-level or origin-level;
- whether the report is for mobile or desktop;
- the date range represented by the field data;
- the tested URL, including redirects and language;
- whether the problem happens during page load or after it.
If the report contains origin-level data, a healthy collection of simple pages can conceal a slow product, account or checkout template. If it contains a laboratory result only, it says nothing directly about the distribution of real devices and network conditions.
“Feels slow” usually describes a moment, not a score
Ask the person reporting the issue to complete this sentence:
The site feels slow when I…
The end of that sentence is more useful than a screenshot of a score. It might be:
- open the mobile menu;
- change a product variation;
- apply a coupon;
- submit a form;
- move from cart to checkout;
- search the catalogue;
- return to a page using the back button;
- accept the cookie banner;
- scroll through a page with several videos.
Many of these actions occur after the initial page has already satisfied Largest Contentful Paint. They may involve JavaScript work, an Ajax request, a database query or a third-party API. A good loading score cannot rule out those delays.
Test the complete journey, not only the landing page
Build a short sequence that matches what the visitor is trying to achieve. For a service website:
- arrive on the relevant landing page;
- open the navigation or a details panel;
- move to the contact page;
- interact with the form;
- submit a safe test.
For WooCommerce:
- open a representative product;
- choose a variation;
- add it to the cart;
- update the cart;
- load checkout;
- enter the address;
- wait for shipping and payment methods.
Record where the delay begins. If product selection is immediate but shipping recalculation pauses, optimising the hero image will not repair the reported experience.
Do not place a real order or send test leads into a live sales process without agreement. Use a staging route, a designated test product or a clearly labelled internal test where possible.
A good INP result does not describe every interaction
Interaction to Next Paint, or INP, describes how quickly the page provides visual feedback after user interactions. Field data reports a percentile across many visits, not a promise that every click is quick.
One expensive interaction can still matter commercially even if most interactions are fast. Examples include:
- opening a large mobile navigation;
- changing a WooCommerce variation with many options;
- applying a complex product filter;
- opening a consent manager;
- validating a long form;
- recalculating checkout fragments.
In Chrome developer tools, record the affected interaction in the Performance panel. Look for a long main-thread task beginning near the click. Expand the task and identify whether the time belongs to your theme, a plugin, analytics, consent code or browser layout work.
Avoid removing the first script with a large file size. Download size and interaction cost are related but not identical. A small script can trigger expensive DOM work, while a larger file may be cached and inactive during the problem.
Inspect the Network panel during the slow action
Some delays are not browser processing. The interaction may be waiting for WordPress.
Open the Network panel, preserve the log and reproduce the issue. Filter for fetch and xhr. On WordPress, common requests include:
admin-ajax.php;/wp-json/REST endpoints;- WooCommerce checkout or cart-fragment requests;
- plugin-specific API paths;
- requests to payment, mapping, CRM or analytics services.
Select the slow request and inspect its timing. A long “Waiting for server response” phase points toward PHP, MySQL, external calls or hosting capacity. A fast response followed by a frozen interface points back toward JavaScript and rendering.
Record the response status and body before changing anything. A request that returns an HTML warning page with status 200 can be handled badly by JavaScript and look like a performance issue.
A passing homepage does not validate dynamic WordPress pages
Full-page cache can make a public landing page exceptionally fast. It usually cannot serve personalised cart, checkout, account or administrator responses in the same way.
Compare response headers on the passing page and the slow page:
curl -q --silent --show-error --max-time 20 --dump-header - --output /dev/null https://example.com/
curl -q --silent --show-error --max-time 20 --dump-header - --output /dev/null https://example.com/checkout/These are GET headers from two document requests, without redirect following or browser execution. HEAD can follow another server path. Status and cache headers are observations, not proof of why a business journey is slow.
The checkout response should not be made publicly cacheable just to match the homepage. The useful question is whether the uncached request completes within a reasonable time and whether it performs only the work required for that step.
If the dynamic page is slow, inspect:
- PHP worker availability;
- slow MySQL queries;
- WooCommerce session size;
- scheduled actions;
- external payment or shipping calls;
- plugin hooks attached to the request;
- error logging that repeats on every action.
Consent can change the page after the test starts
A laboratory test may load the site without making the same consent choice as a normal visitor. Once analytics, advertising, chat, video or personalisation scripts are allowed, the page can acquire substantial extra work.
Test at least three states:
- before any consent choice;
- after rejecting non-essential scripts;
- after accepting the categories a normal visitor may allow.
Check that essential functions remain available in every lawful state. A form or checkout that waits for an analytics script is both a reliability and performance problem.
Do not “solve” the delay by loading consent-controlled scripts before permission. Performance work must preserve the intended privacy behaviour.
Page transitions may not resemble the first load
The first page load receives close attention because common tools measure it well. Later navigation can behave differently.
Potential causes include:
- a theme transition that holds the old page while JavaScript prepares the next one;
- a cache miss on the destination page;
- repeated downloading of assets with poor cache headers;
- a third-party script that grows in memory after each view;
- WooCommerce fragments refreshed on every page;
- browser back/forward cache being disabled by page behaviour.
Use the Network panel to compare the first navigation with later ones. If a document request is slow, investigate the response path. If there is no new document request but the interface pauses, inspect the JavaScript transition and main-thread work.
Core Web Vitals do not measure every business outcome
The Core Web Vitals are valuable because they focus attention on loading, visual stability and responsiveness. They should remain part of the acceptance criteria.
They do not directly confirm:
- that search results appear quickly;
- that a form submission reaches the server;
- that shipping rates return promptly;
- that a payment callback updates the order;
- that an administrator can process orders efficiently;
- that video playback starts without excessive buffering;
- that every third-party API is healthy.
Add journey-specific measurements. For example:
- time from form submission to visible confirmation;
- time from address change to updated shipping methods;
- time from “Place order” to payment hand-off;
- time from product-filter selection to updated results;
- time from administrator search to order list.
These are not replacements for Core Web Vitals. They cover the parts of the service that a page-load report cannot see.
Check averages for hidden slow groups
Analytics averages can produce the same false reassurance as one PageSpeed run. Segment the affected journey by:
- mobile and desktop;
- browser family;
- country or region;
- landing page;
- new and returning visitors;
- language;
- logged-in and logged-out state, where privacy and analytics design allow it.
Do not collect sensitive data simply to diagnose speed. Use the minimum aggregation needed to locate the slow condition.
A useful discovery might be that mobile visitors from one region are slow only on product pages, or that returning visitors become slow after accepting a chat widget. That is a repairable statement. “Average page time is acceptable” is not.
Do not optimise a metric that already passed without a hypothesis
When a report is green, teams sometimes try to make every number even smaller because the real complaint remains unexplained. This can lead to risky CSS changes, aggressive JavaScript delays and extra cache layers.
Before changing anything, write down:
- the affected action;
- the evidence showing where time is spent;
- the proposed change;
- the expected observable improvement;
- the rollback route;
- the test that will confirm the repair.
If the change cannot be connected to the slow action, it is not yet justified.
What to collect before requesting an assessment
Send:
- the passing PageSpeed URL;
- the exact action that feels slow;
- device, browser and approximate location;
- whether consent was accepted;
- a screen recording if the delay is difficult to describe;
- the slow Network request or Performance trace, if available;
- recent WordPress, plugin, theme, tracking or hosting changes.
Do not send passwords in the initial request. The first assessment should determine the scope and required access.
A useful repair improves the journey and preserves the passing result
The objective is not to prove PageSpeed wrong. It is to fix the experience the report does not represent without damaging what already works.
The repair might involve one slow WordPress request, a JavaScript handler, WooCommerce session work, a consent-controlled script or an external service. Once changed, repeat the full journey and recheck the Core Web Vitals page. A local improvement is not complete if it creates a new loading or layout regression elsewhere.
If PageSpeed passes but your WordPress site still feels slow, request a performance assessment with the affected action and URL. We will reproduce the journey, isolate the waiting layer and explain the smallest safe intervention before requesting access or starting work.
Our observed example: desktop 99, emulated mobile 79, no field data
We checked this English guide in PageSpeed Insights on 25 October 2026, with the capture labelled 01:38 CEST. The desktop report showed performance 99, LCP 0.8 s, FCP 0.7 s, TBT 50 ms and CLS 0.025. The emulated-mobile report showed performance 79, LCP 4.0 s, FCP 3.1 s, TBT 40 ms and CLS 0. The mobile profile was an emulated Moto G Power with slow 4G; both were initial-load laboratory profiles using Lighthouse 13.5.0.
Both field-data panels said no data. Therefore, this is not a passing real-user Core Web Vitals case. It is an observed example of a green desktop laboratory score failing to represent the other tested profile. A subsequent report request displayed the same capture minute and values; we do not count it as independent evidence of repeatability.
No optimisation was applied between these profiles. They do not establish a cause, an improvement, real-phone performance, consent-state performance or measured menu/checkout responsiveness. TBT is the reported laboratory metric, not a measured field INP.
For a reproducible next check, record the URL, release, profile, consent and session state, then capture the affected action separately. The official Lighthouse user-flow documentation distinguishes navigation, timespan and snapshot reports. Select the mode that can observe the question; a snapshot cannot supply the timing of an interaction it did not record.
If your complaint concerns an action rather than initial loading, use our guide to comparing fast and slow visitor conditions, then request a WordPress performance assessment with the exact action and report. Share descriptions first; traces and managed access can be scoped without sending passwords or customer payloads in a public form.
When commissioning the work, the 2027 WordPress speed optimisation quote checklist connects the reported delay with scope, deliverables, validation and additional costs.