A useful performance report tells your team which visitors have a slow experience, which part of the website causes it, and what to change. A single score for the homepage cannot answer those questions for a site with hundreds of templates, campaigns, and regional variations.
This guide covers the measurement process: choose a representative page sample, separate real visitor data from controlled tests, diagnose the cause, and verify the result after release. It replaces the earlier edition of Alba Silvente’s guide, first published in 2022, with current metrics and a workflow for teams maintaining a large website.
Start with three visitor experiences
Ask whether the main content appears promptly, controls respond when someone uses them, and the page stays still while they read or click. Google’s current Core Web Vitals measure these experiences:
| Metric | What it measures | Good at the 75th percentile |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest eligible content element becomes visible | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to clicks, taps, and keyboard interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Unexpected movement of visible elements | 0.1 or less |
Assess mobile and desktop separately. The 75th percentile describes a point in the distribution, not an average: a good result there means at least three quarters of the measured experiences meet the threshold. INP replaced First Input Delay (FID) as a Core Web Vital in 2024; a dashboard that still treats FID as the current responsiveness measure needs updating. See Google’s Web Vitals definitions and thresholds.
Use these as experience targets, not promises of search positions or revenue. Track the business task alongside them: completing an enquiry, finding a product, or publishing a campaign. A fast page with an unusable form still fails its visitor.
Keep field data and lab tests separate
Field data comes from real visits, including the devices, networks, locations, and interactions your audience actually uses. It is the evidence for whether visitors experience an improvement.
Lab data comes from a controlled test. It is useful for reproducing a problem, comparing two implementations, and catching a regression before launch. It describes the tested conditions, not every visitor.
A good lab run and poor field results can both be correct. Real users may encounter a slower device, a different cache state, or an interaction the test did not exercise. A loading-only test also misses layout shifts that happen later. Google’s explanation of lab and field differences is a useful reference when the reports disagree.
Do not average the two datasets together. Record their dates, source, device profile, and scope next to each result.
Build a page sample before testing
Choose pages by the work they do and the templates they share. Include the homepage, a service or product page, a long article, a search or listing page, and the enquiry journey. Add a page with the heaviest media and a translated page with a different content length.
For a multi-brand estate, repeat the sample where a brand has different components, consent settings, or third-party integrations. One brand’s fast landing page says little about another brand’s embedded booking flow.
Keep an inventory with these fields:
| Field | Example |
|---|---|
| URL and template | /services/website-migration, service detail |
| Audience and device | Mobile visitors in the principal customer market |
| Task | Read the service, open contact, submit the form |
| Test state | New visit, consent choice recorded, cold cache |
| Release | Build identifier and test date |
| Field coverage | URL data, origin fallback, or unavailable |
| Owner | Team responsible for the template |
These are example entries, not a report of measurements on this website. Use the same sample before and after a release so changes in page selection do not masquerade as improvements.
Read PageSpeed Insights correctly
Enter a production URL in PageSpeed Insights. Read the real-user section separately from the Lighthouse diagnostics. Check whether the field result describes this URL or the origin. An origin result combines experiences across pages and cannot establish that your individual service page passes.
The CrUX field data shown there covers a rolling 28-day period. A release today will not replace that history tomorrow. Some pages have insufficient data; an unavailable result is not a failure, and an origin fallback is not a page-level pass. Chrome documents these distinctions in its PageSpeed Insights field-data guide.
Save the report URL, collection period, test time, and device setting. For a migration, keep the old site’s results before access disappears. Search Console’s Core Web Vitals report can then help you locate affected URL groups, while individual tests help diagnose the shared templates.
Diagnose the slow part before changing the stack
If main content appears late
Inspect the LCP element and its request path. A large hero image might be discovered late, downloaded slowly, or ready but unable to render. Server response time and render-blocking styles can contribute before the image itself becomes the bottleneck.
Use the network waterfall and a performance trace to identify the delay. For an image that is visible immediately, check its dimensions, responsive sources, discovery in the HTML, and loading priority. Do not lazy-load the page’s LCP image. Reducing file size alone will not fix an image that the browser discovers too late. Follow Chrome’s LCP diagnostic breakdown.
If controls feel unresponsive
Reproduce the actual interaction on a representative device: open navigation, filter a list, change a form field, or submit. Record a performance trace while doing it. Look for long main-thread tasks, expensive event handlers, and rendering work before the next frame appears.
Reduce or split the work responsible for the delay. That may mean removing a script, yielding during a long operation, or reducing the amount of DOM updated by an interaction. A Lighthouse loading score does not measure a real visit’s INP; Total Blocking Time is useful diagnostic evidence, not a replacement field measurement. Use the INP optimization guide to distinguish input delay, processing time, and presentation delay.
If content moves while someone reads
Use a trace or a recording of your own test to locate the shifting elements. Check images without reserved dimensions, embeds injected above existing content, and font changes that alter line wrapping. Exercise the page after loading as well as during navigation.
Reserve space for media and embeds. Avoid inserting new content above the visitor’s current position without an appropriate interaction. Fix the source of the shift rather than hiding the affected content. Chrome’s CLS guide explains common causes and why later shifts can escape a loading-only test.
Set budgets your team can act on
Use field experience targets and implementation budgets for different purposes. The field target describes the outcome. A budget for JavaScript, image transfer size, or a repeated lab measurement catches a likely regression during development.
Establish implementation limits from the current page sample and the agreed improvement, rather than copying an arbitrary universal byte limit. Record the test conditions and repeat runs before deciding a small change is meaningful. Assign each budget to an owner who can change the responsible component or integration.
For example, a marketing team adding a campaign embed should know which template it affects, how to test the enquiry path, and who can remove the embed if it breaks the agreed experience. A dashboard without that responsibility is only a record of the problem.
Verify a migration in stages
Before launch, compare the old and new templates under the same lab conditions. Test navigation, consent, search, and forms with the integrations that will actually ship. A preview with analytics and embeds disabled is useful for development, but incomplete as a production comparison.
At launch, repeat the smoke tests on the production hostname. Check representative pages, interactions, and the successful enquiry path. Record the release time so subsequent monitoring can distinguish traffic before and after the cutover.
After launch, watch field data as the new release enters its collection window. Compare the same device and page groups, and investigate changes in traffic mix before attributing every movement to the rebuild. Keep URL and indexing checks in the separate SEO migration checklist; performance alone does not establish that a migration preserved search visibility.
Make the report part of operating the website
A short weekly review should answer four questions: which page group changed, which visitors it affected, which release or content change might explain it, and who owns the next test. Keep the underlying evidence linked so the next person can reproduce the finding.
Review the sample whenever a new template, market, or major integration ships. The result is a measurement process that survives the rebuild and gives editors and developers a common definition of a working website. If your migration needs that process alongside content, redirects, and editor training, see how we plan and run website migrations.