Which pages should you measure first?
As in a technical SEO review, begin with representative page groups. Home, collection, product, article and enquiry pages use different components. A good result for one does not establish that another performs well. Choose URLs important to organic entry, paid campaigns and purchase or enquiry journeys so the measurement follows the business's actual priorities.
Review mobile and desktop separately. Record the URL, date, device and network conditions, and release version. A returning signed-in customer may experience a different page from a first-time visitor. Campaign parameters, consent banners or personalisation can change the main visible content. Establish a consistent baseline scenario, then add the additional scenarios that matter for your business. Keep the scenario description with the report rather than relying on memory.
Online store
Check collection filters, product variants, the basket and checkout entry. Seeing the page is only part of the experience; selections should respond promptly too.
B2B website
Follow a service or catalogue page into the enquiry form. Record the effect of large PDFs, galleries or third-party forms separately so the responsible component is clear.
Content website
Sample the article template, an image-heavy guide and search results. One lightweight article is not a reliable representative of an entire publication archive.
Separate lab diagnostics from field experience
Your measurement plan should identify the scope of each data source. A lab result is a run under controlled conditions at a particular moment. It helps investigate a bottleneck and compare changes. Field data describes actual visits. The sources answer different questions, so identical values should not be expected. A disagreement is a reason to examine coverage, not simply to choose the more attractive number.
PageSpeed Insights can show page-level or origin-level real-user information when sufficient data is available. Origin-level information covers experiences across that website origin, rather than only the tested URL. A report may have no field information when appropriate samples are insufficient. Absence of field data is not proof that the page is fast or slow. When sharing a report, state whether it describes the URL, the broader origin or only a laboratory run.
FROM READING TO A NEXT STEP
Turn the score into a practical improvement plan
Share your important pages and current performance report. We can clarify data coverage, the actual bottleneck and the development work that deserves attention first.
What do LCP, INP and CLS tell you?
As in web application development, loading, interaction response and visual stability are different concerns. LCP describes when the main visible content appears, INP assesses interaction responsiveness and CLS describes unexpected layout movement. Treating them as a single loading-time number can lead to the wrong change. Investigate the symptom behind the metric and the task customers were trying to perform.
The good field thresholds below follow Google's current PageSpeed documentation. They are not a customer contract or a search-ranking guarantee. The laboratory performance score is a separate calculation. TBT in a loading test is also not the same measurement as real-user INP. Check interactions such as opening navigation, choosing a variant and validating a form as part of actual use, rather than assuming a loading run covers every important task.
| Metric | Good field threshold | First investigation |
|---|---|---|
| LCP | 2.5 seconds or less | Main image, server response and rendering |
| INP | 200 milliseconds or less | Heavy JavaScript and slow interaction work |
| CLS | 0.1 or less | Unreserved image space and inserted content |
Make before-and-after measurements comparable
As with an A/B experiment, record the comparison conditions. Running a speed diagnostic is not itself an A/B test. Before and after a change, use the same page, tool and similar conditions for multiple lab runs. Do not select one favourable run and present it as the entire result. Preserve enough context for another developer to reproduce the observation and challenge the conclusion.
A field report contains past visits, so a released fix will not be fully represented immediately. Lab checks offer an initial technical verification; suitable real-user monitoring subsequently helps assess the experience. Record content, third-party code and campaign changes during the same period. Avoid manufacturing a percentage gain from datasets that represent different audiences or conditions. A useful report explains both the observed change and what remains uncertain.
Baseline record
Note the URL, release, method and represented conditions. Describe the customer task where the problem is visible, not only the dashboard colour.
Technical change
Target the important bottleneck first. Release image, script or caching changes with a traceable version and a practical rollback path.
Verification
Measure under comparable conditions. Review functionality, accessibility and actual customer tasks alongside the performance result before accepting the change.
Turn the report into actionable development work
A useful audit deliverable is more than a copied list of tool recommendations. Each task should identify the affected template, observed symptom, proposed change, owner and acceptance check. Instead of “optimise images,” describe the specific oversized image and the screen where it appears. Set priority using customer impact, implementation risk and the opportunity observed in the report, rather than assuming every warning has the same business value.
Do not remove third-party scripts indiscriminately: they may support payment, consent or customer service. Review which features are needed and where their code should run. Delaying the main visible image can worsen loading instead of improving it. Before accepting a change based on a higher score, check the effect on task completion, form validation and measurement. Keep the technical owner and business owner involved when a performance choice changes an important feature.
Read speed, SEO and conversion together without conflating them
For campaign evaluation, page experience is an important input, but it does not explain all sales outcomes. The offer, price, inventory, traffic quality and tracking errors can change results. If sales improve during a performance release, do not automatically attribute the entire change to speed. The objective is a working customer journey and a traceable technical improvement, with commercial outcomes measured using appropriate methods.
Recheck representative pages after adding a theme, application or campaign component. Include lab checks in the release process for significant changes and review real-user information over time. Google explicitly states that good Core Web Vitals do not guarantee top search rankings. In a Prix review, we can separate performance findings from content, technical SEO and conversion issues, then agree which implementation tasks deserve attention first.
BEFORE YOU DECIDE
Frequently asked questions
Why does my PageSpeed score change between runs?
Network conditions, testing infrastructure, third-party work and device resources can influence a run. Record the conditions and review multiple observations rather than treating one score as a definitive description of the website.
Why is real-user data missing?
A recently published page or insufficient suitable samples can prevent field reporting. The report may use origin-level information or show none. Missing data should not be interpreted as a successful performance assessment.
Is testing the homepage enough?
No. Collection, product, service, article and form templates can have different workloads. Choose representative URLs using traffic and business importance, and review mobile and desktop separately.
Will a score of 100 make the site rank first?
No. Search visibility depends on many signals. Good performance supports the customer experience but does not replace relevant content, indexability or the competitive context of the query.
Will a speed plugin solve the problem?
That depends on the cause. A plugin may simplify some work, while an incorrect caching or loading setting can break important functionality. Verify the actual pages and customer tasks after implementation.
What should we share with Prix?
Send the important URLs, current report, platform and the task where slowness is noticeable. We can clarify access and scope, then turn the findings into a concrete development plan without promising a universal score.
LET’S DEFINE THE SCOPE
Turn the score into a practical improvement plan
Share your important pages and current performance report. We can clarify data coverage, the actual bottleneck and the development work that deserves attention first.
Discuss a speed review