Record the page, device and test conditions
Open the official PageSpeed Insights tool, enter the specific page and select mobile or desktop. Save the report link, capture date, tested URL, device, test conditions and relevant release or change.
Choose pages that represent important journeys: a landing page, product or service page, search results and any relevant transactional flow. A homepage run does not measure every page or interaction. Confirm the result loaded the intended content rather than an error, consent-only state or unexpected redirect.
Open the printable performance-fix record. Use it to keep the observation, suspected cause, proposed change, owner and verification together. Leave results blank until the check actually runs.
Read real-user data separately from the lab test
Google's PSI explanation distinguishes historical Chrome-user data from a controlled Lighthouse test. The field section covers a trailing 28-day period when sufficient data is available. Its displayed metric values use the 75th percentile, rather than an average visit.
This URL, the origin or no data
Check whether the field data describes the entered URL or the origin. Origin data aggregates eligible pages for that origin; it does not prove that the particular product page performs the same way. The Chrome CrUX guide to PSI explains these views and their availability.
If the field block says No Data, record that as unavailable. Do not convert it into a pass, a failure or an invented zero. Use diagnostic tests and, where appropriate, your own real-user monitoring to investigate. A lack of sufficient CrUX data is not a performance measurement.
Understand LCP, INP and CLS in context
The official threshold definitions distinguish loading, responsiveness and visual stability:
| Metric | What it concerns | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint, LCP | Appearance of the main visible content | 2.5 seconds or less | More than 4 seconds |
| Interaction to Next Paint, INP | Responsiveness to user interaction | 200 milliseconds or less | More than 500 milliseconds |
| Cumulative Layout Shift, CLS | Unexpected visual movement | 0.1 or less | More than 0.25 |
Values between the good and poor boundaries need improvement. CLS is a unitless score. Check the displayed assessment and its data scope; do not calculate a field assessment from an isolated lab run.
The measurement guide explains why standard navigation Lighthouse reports Total Blocking Time, TBT, as a diagnostic proxy for INP. A low lab TBT does not establish good real-user INP. Test the actual interactions, including filters, menus and forms, when responsiveness is the concern.
A real Nolixia report: what it shows and what it does not
We ran the homepage through the official PSI interface on 23 October 2026 at 16:04 GMT+1. The saved mobile report used an emulated Moto G Power, slow 4G and Lighthouse 13.5.0 for an initial page load. The separate API attempt had returned a request-limit error; the figures below come from the completed interface report.
| Observed item | Displayed result | Interpretation |
|---|---|---|
| Real-user block | No Data | No field assessment can be inferred |
| Performance score | 81 | A summary of this lab run |
| First Contentful Paint | 0.9 seconds | Initial content appears before the largest content |
| Largest Contentful Paint | 5.1 seconds | Investigate the late largest-content appearance |
| Total Blocking Time | 50 milliseconds | Does not establish field INP |
| Cumulative Layout Shift | 0 | No shift recorded in this load; later interactions remain untested |
| Speed Index | 2.5 seconds | Another lab loading measure, not a substitute for LCP |
This is one dated run of one page. It does not establish site-wide performance, a typical UK visitor's experience or an improvement after changes. No optimisation result is claimed here.
Translate a diagnostic into a reproducible task
In this report, the LCP-discovery detail identified the hero's fashion-ecommerce image and showed it marked for lazy loading. The image-delivery section also listed oversized project previews and an estimated reduction of about 2,828 KiB. One listed preview was 1536×939 pixels while displayed at 630×420 in that run.
Those are useful investigation leads. Estimated savings are not observed time saved, and several opportunities may overlap. Do not add their estimates together and promise that amount of improvement.
| Priority for this investigation | Evidence | Proposed task | Verification |
|---|---|---|---|
| Investigate the LCP image first | LCP5.1s; discovery detail identifies a lazy-loaded hero image | Confirm the actual LCP element and loading path; review whether this above-the-fold image should load earlier | Inspect request timing and rerun the same mobile page; preserve visual behaviour |
| Review project-image delivery | Preview dimensions exceed display size; substantial estimated byte savings | Prepare appropriately sized/responsive assets and review compression | Compare transferred bytes and visual quality at relevant sizes |
| Review blocking resources next | Report estimates240ms from render-blocking requests | Identify the named resources and whether a safe change is possible | Check the request chain and affected rendering after the change |
| Test interaction and later movement separately | Navigation run has no field data | Exercise menus, forms and other important interactions with a trace | Inspect interaction delay and layout movement; confirm functions still work |
These priorities are specific to the observed report, not a universal order for every site. They are proposed work, not changes already applied. Google's Core Web Vitals workflow connects field symptoms, diagnostic evidence and verification; use the appropriate tools for the issue you can reproduce.
Give each task an owner, a measurable check and a recovery route. Avoid removing a required script merely to improve a score. For a contact form or checkout, verify the business function as well as loading behaviour after any change.
Re-test comparable conditions and monitor
After implementing a specific change, rerun the same URL and device under comparable conditions. Record more than one run when variability matters, retain the individual results and compare the relevant metric as well as the overall score. Do not compare a mobile before result with a desktop after result.
Field data reflects its rolling period, so a deployment does not instantly replace the historical experience. Record the release date and watch the appropriate data over time. If field data is unavailable, say which checks were possible and which remain unmeasured.
For broader context, read page speed and Core Web Vitals explained. Add repeated checks to the website maintenance routine. When specifying a shop, agree performance and functional checks as part of the ecommerce development scope.
Common questions
Why do mobile and desktop results differ?
They use different test conditions and can load different page resources or layouts. Compare like-for-like results and inspect the environment shown in each report.
Why is field data missing?
The required dataset may not contain sufficient eligible samples for that URL or origin. Missing data alone does not diagnose speed or prove a search-indexing problem.
Does a good score guarantee rankings?
No. Use the report to improve and verify user experience. A lab score is not a promise of search position, enquiries or revenue.
