Define the audit population and decision
Write the decision the audit must support: which performance changes should enter the next development cycle, on which templates, and with what evidence? Agree whether the scope includes logged-in journeys, international variants, advertising, embedded tools and application transitions. Otherwise a short landing-page test can be mistaken for coverage of an entire service. Record exclusions before collecting results.
Build a URL inventory with template, traffic relevance, content variation and technical ownership. Include common pages and awkward cases: a product with many variations, a category with numerous filters, a long article and a page with third-party embeds. Select examples deliberately rather than using only the homepage. Keep mobile and desktop separate and include journeys after loading. The performance overview helps decide where a broad audit should lead. An audit is a sample-based investigation, so explain what the sample represents and what remains untested. Do not imply that a few URLs certify a whole domain.
Establish the field baseline without mixing scopes
Capture the source, date window, device category and whether each observation describes a URL, a group or an origin. Record field p75 values where available. Good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Missing data means insufficient evidence for that source and scope, not an automatic pass or failure.
Compare templates and journeys before calculating a sitewide story. An origin containing a fast marketing section and a slow catalogue can conceal an important difference. Similarly, an apparent deterioration can reflect more visitors using slower devices. Preserve counts and cohort definitions wherever your telemetry permits. Use field versus laboratory data to resolve tool disagreements before creating tickets. Also annotate promotions and releases that could alter content or traffic. The baseline needs to be repeatable by another analyst, including the exact filters used to produce it.
Create a reproducible test matrix
For every representative URL, define viewport, device or emulation settings, connection conditions, cache state, consent choice and navigation type. Record whether extensions are disabled and whether the browser is authenticated. Repeated runs under the same conditions reveal variability; a solitary run cannot distinguish a stable dependency from temporary network noise. Keep raw traces alongside your notes.
Add a short interaction script for each template. Open navigation, select a filter, expand a panel, scroll to an embed and revisit a previous state where those actions are relevant. Do not force every page through an identical journey. A product configurator and an editorial page have different risks. Separate controlled comparisons from exploratory tests so unusual discoveries do not contaminate the baseline. When a test fails to reproduce a field complaint, retain that result and change one plausible condition at a time. A negative reproduction is useful evidence about the limits of your current hypothesis.
Gather the minimum evidence for each metric
For LCP, save the winning element, resource address where applicable, navigation timing and the interval between resource completion and painting. For INP, capture the exact interaction, preceding main-thread work, event processing and presentation delay. For CLS, preserve the shift timing, displaced elements and the component mutation that preceded movement. Screenshots alone rarely establish those causal sequences.
The evidence checklist should include a healthy comparison, affected template count, release identifier and whether the fault appears in initial HTML or only after scripts run. Use the focused LCP investigation when loading dominates, rather than scattering effort across every audit suggestion. A request waterfall can show a late image discovery; a main-thread profile can show why it remains hidden afterwards. These are complementary observations. Attach the smallest evidence set that allows a developer to challenge or reproduce your finding, and keep the larger raw capture available for detailed review.
Rank hypotheses before ranking recommendations
For each symptom, write at least two credible explanations and the test that separates them. Slow loading might involve server latency, deferred discovery or hidden content. A sluggish control might wait behind unrelated work or execute an expensive handler itself. Layout movement might come from missing image dimensions or an expanding recommendation module. Naming alternatives prevents a familiar tool recommendation becoming an unsupported diagnosis.
Rank proposed work by user exposure, severity, confidence, component reach, effort and operational risk. These are judgement inputs, not precise financial forecasts. Do not attach invented revenue or ranking gains. A low-confidence issue can still deserve a small diagnostic experiment before a larger fix. Use technical issue prioritisation when performance competes with crawling or indexing work. Make dependencies explicit: changing image discovery may require template ownership, while an advertising slot policy may need commercial agreement. A good audit separates decisions ready for implementation from questions that still need evidence.
Illustrative example: audit a category filter
Illustrative example: a category template shows acceptable loading in repeated tests, but field responsiveness is poor. The audit initially considers a large filter handler, third-party background work and a costly product-grid repaint. A scripted interaction on a populated category reveals a small handler followed by extensive style and layout work. An empty category does not reproduce the same delay.
The next experiment updates only changed cards instead of rebuilding the entire grid. Keep sorting rules, item count and connection conditions constant. Record the interaction timeline and verify that the selected filter, result count and keyboard focus remain correct. If rendering cost persists, investigate DOM size and style invalidation rather than declaring the handler fixed. The evidence supports a targeted rendering ticket, not a blanket instruction to remove all third-party scripts. The numbers and outcome would need measuring on the actual implementation. This is an illustrative diagnostic example, not a reported engagement or a claimed benchmark.
Make the audit handover testable
Each developer ticket needs a concise symptom, affected scope, reproduction steps, trace evidence, selected hypothesis, proposed change and acceptance criteria. State what should disappear from the timeline, what must remain functionally equivalent and which cases might break. Include a route for the developer to suggest a different implementation that achieves the same observable result.
Require matched before-and-after tests with repeated runs, followed by post-release field review. Include content visibility, navigation, keyboard use, error reporting and consent behaviour in acceptance where relevant. Performance fixes can change execution order and expose hidden dependencies. A ticket is not ready if its only criterion is a higher aggregate score. Use regression monitoring to agree the future alert and owner. Keep audit severity separate from ticket completion: a deployed experiment may be technically complete while the field outcome remains under observation. That distinction makes progress honest without leaving every task permanently open.
Document limitations, rollback and closure
List the situations your audit could not cover: low-traffic pages without field observations, unsupported telemetry, authenticated states or embedded content you cannot inspect fully. A laboratory failure under extreme throttling is a stress finding, not proof that every visitor has that experience. Conversely, a successful desktop trace cannot dismiss a mobile field problem. Preserve those qualifications beside the finding.
Plan reversal before release. A loading optimisation may break an image fallback; deferred code may delay a necessary consent control; narrower DOM updates may leave stale product details. Define functional stop conditions, keep earlier assets available and identify who can disable the change. Review cache invalidation separately from code rollback. Close the audit finding when the cause has been addressed, acceptance checks pass and the monitoring plan is operating. If field evidence remains inconclusive, record that uncertainty and the next review point instead of converting it into a fabricated success statement.
Frequently asked questions
How many URLs should a performance audit test?
There is no universal number. Choose enough examples to cover distinct templates, component combinations and important variations in content or behaviour. Add exceptions when field evidence points elsewhere. Document the selection logic so a reader understands coverage; a large random list can be less useful than a smaller deliberate sample.
Should every Lighthouse opportunity become a ticket?
No. Treat automated opportunities as leads. Confirm that the suggested resource or behaviour lies on the failing journey and that changing it is likely to address the observed symptom. Combine repeated findings around their shared cause, and leave speculative suggestions as investigation notes until evidence supports implementation.
Can the audit run entirely in staging?
Staging is useful for controlled experiments and functional checks, but production can differ in caching, tags, consent, advertising and real traffic. Establish the original problem in the relevant production context, reproduce safely where possible, then compare the deployed change. Record any staging differences that limit the comparison.
What should the final audit deliverable contain?
Provide a scope statement, baseline, representative test matrix, prioritised findings and evidence-backed developer tickets. Include unresolved hypotheses, limitations, rollback conditions and a field review plan. The deliverable should let an implementation team reproduce the important faults without relying on a presentation or the analyst being present.