PageSpeed Insights gives the URL a passing result. The Core Web Vitals panel is green. Yet opening the menu feels delayed, product filters hesitate and checkout appears to pause between steps.
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.
Interaction to Next Paint can hide behind a green average
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 -I https://example.com/
curl -I https://example.com/checkout/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.