A slow website is not one problem. The server may take too long to answer, the main image may start downloading late, a script may block an interaction, or a banner may move the button just as someone taps it. Each failure needs different evidence and a different repair.
Begin with the page, device and user action that matter. A fast desktop home page does not establish that the mobile product page or checkout is fast. Comparing unlike tests can make a release look better or worse for the wrong reason.
What this audit covers
What can be measured
- Hosted public-site performance through PageSpeed Insights, Lighthouse lab results and CrUX field metrics when the provider supplies them.
- Selected mobile or desktop strategy, measured URL, available opportunities, diagnostics and per-metric evidence.
What it cannot prove
- A lab run is a controlled sample, not every visitor’s experience. Field data can be absent or cover an origin rather than the exact page.
- Local Agent performance uses a separate limited local measurement; it is not a hosted Lighthouse or CrUX run.
Performance access follows the current plan and provider availability. Missing provider data is reported as unavailable rather than being replaced with invented measurements.
1. Read lab and field measurements differently
Lighthouse runs a repeatable laboratory scenario that helps diagnose a page. CrUX aggregates eligible real-user experiences, where enough data exists. The measurements can disagree because the audiences, devices, network conditions and time windows differ. PageSpeed Insights documentation explains both sources.
Read the source next to each metric. A report can contain field data for one value and a lab fallback for another. Check whether field evidence describes the exact URL or the whole origin. No field data is a missing sample, not a failed Core Web Vitals assessment and not evidence that the site has no visitors.
2. Understand the three Core Web Vitals
| Metric | What it describes | Good reference boundary |
|---|---|---|
| LCP | When the largest visible content element is rendered | 2.5 seconds or less |
| INP | Responsiveness across user interactions | 200 milliseconds or less |
| CLS | Unexpected visual layout movement | 0.1 or less |
For field evaluation, these boundaries are assessed at the 75th percentile of visits, with device categories considered separately. See Web Vitals. A single lab number should not be labeled a field pass. Time to First Byte and First Contentful Paint are useful diagnostics, but they are not additional Core Web Vitals.
3. Match the symptom to the evidence
The following priorities are illustrative. Impact on a key task matters more than a diagnostic title alone.
| Symptom | Priority in context | Evidence to inspect |
|---|---|---|
| Main content appears late | High when users wait to understand the offer | LCP element, response delay and request timing |
| Buy button reacts slowly | High for the purchase journey | Interaction trace and long main-thread tasks |
| Content shifts under the pointer | High if it causes accidental actions | Shifted elements and reserved dimensions |
| Large unused script | Medium until its actual cost is measured | Transferred bytes, execution time and page usage |
An opportunity estimate is not a guaranteed saving. Two suggestions may overlap, and a heavy-looking resource may be necessary. Confirm the bottleneck before deleting features or replacing infrastructure.
4. Fix the component that creates the delay
For late main content: identify the LCP element first. If the server response is late, inspect backend work and caching. If a hero image is discovered late, make it available early in the document; avoid lazy-loading the initial prominent image. Deliver an appropriately sized image. LCP optimization guidance breaks down the loading phases.
For slow interaction: inspect expensive handlers, synchronous rendering and third-party work. Split long tasks and reduce unnecessary work around the action. Total Blocking Time can help diagnose lab behavior, but it is not the same metric as INP. Use INP guidance and an actual interaction recording.
For movement: reserve space for images, embeds and banners before they arrive. The correct repair depends on which element moves and why.
5. Run a controlled before-and-after comparison
- Record the exact URL, device strategy, test time and data source.
- Make one coherent change tied to the observed bottleneck.
- Repeat several comparable lab runs and inspect the trend, not the most flattering run.
- Check the page visually and complete its primary interaction.
- Confirm that a shared component did not regress another template.
- Observe field data later; an aggregate window will not immediately reflect a new deployment.
Keep the diagnostic evidence, not only screenshots of the score. If an image repair improves loading but introduces layout movement, the work is incomplete. Recheck narrow viewports and delayed content such as cookie notices, fonts and embedded widgets.
6. Know what the test cannot tell you
A single navigation does not exercise every state of a complex application. A page can load quickly and still respond badly after a long editing session. A lab test may not encounter the same consent state, account or content as a real customer.
Sitelemetry’s hosted report identifies the selected strategy and available measurement source. Its Local Agent checks local delivery through a separate limited method; do not compare that result numerically with a public Lighthouse score. If PageSpeed is unavailable, resolve or retry the missing measurement rather than interpreting a blank metric as zero. Performance evidence should stay explicit about what ran.
7. Make speed part of the product workflow
Set a budget for the templates and interactions you actually own: image payloads, third-party scripts and expensive client work are useful review targets. When adding a chat widget, analytics tool or animation, test the affected page before and after instead of assuming the vendor has no cost.
Keep correctness, accessibility and speed together. A visually stable form that communicates progress is more useful than a high score achieved by hiding content. Prioritize your most important mobile landing or conversion page, run the available performance audit, then write one repair ticket with a measurable acceptance condition. Pair it with the accessibility review and integration audit when the same component affects all three.
Common questions
Why do two performance runs give different scores?
Network, server load, cache state and laboratory variability can change a run. Compare the same URL and device over several comparable tests, and inspect the underlying metrics.
Does missing CrUX data mean our website is slow?
No. It means eligible field data was not available for that scope. Use the lab result for diagnosis and avoid claiming a field pass or failure.
Is Total Blocking Time the same as INP?
No. They describe different measurements. TBT is a useful lab diagnostic for blocking work; INP describes responsiveness across user interactions.
Sources & further reading
- Google: About PageSpeed Insightsdevelopers.google.com
- web.dev: Web Vitalsweb.dev
- web.dev: optimize Largest Contentful Paintweb.dev
- web.dev: optimize Interaction to Next Paintweb.dev
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
