1. Define the outcome and boundary
Name one owner and write the outcome before opening an audit tool. State the audience, journey, pages or routes, time window, and decision the work should support. A useful goal describes a task, such as completing a mobile product-to-cart flow, not a vague wish to make the site faster.
List non-negotiables: working purchase or enquiry flow, account access, consent behavior, accessibility, search crawlability, and approved content. A synthetic score gain is not a win if a form fails, content is hidden from search, or keyboard use becomes harder.
Write the start page, user action, and successful end state in one sentence.
Choose an outcome that must not worsen, such as successful submission or no new accessibility blocker.
2. Capture a comparable baseline
Before changing code, content, configuration, or tags, save the URL list, date, test conditions, release version, reports or traces, and manual task result. web.dev recommends recording the site state before changes and testing multiple page types; for single-page applications, include routes, components, and flows rather than only the first load.
Use more than one lens. Lighthouse provides automated performance, accessibility, SEO, and other audits. Test the first load with cleared storage or a clean profile, then complete the target task. Where sufficient real-user data exists, compare important page groups and device classes. Core Web Vitals are field measures: LCP covers loading, INP interactivity, and CLS visual stability.
Field data reflects real visits; lab testing makes a problem easier to reproduce. Use both when available.
A simulated load cannot measure INP because there is no user input; lab Total Blocking Time is a proxy only.
3. Audit the journey end to end
Group findings by journey and mechanism. Review request size, timing, and dependencies for page assets and third parties. Check the mobile viewport, keyboard path, visible focus, labels, errors, headings, link purpose, zoom, and what happens if an image, script, or consent-dependent service is slow or unavailable.
Treat automated accessibility output as triage. W3C says no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is required. For search, make sure important rendered resources remain available to crawlers as well as users. Include redirects, canonicals, internal links, robots directives, sitemaps, and structured data when the change affects them.
List tag managers, analytics, chat, payment, fonts, CDNs, APIs, and consent tools the task relies on.
For payment, authentication, user data, headers, or security controls, obtain qualified security and payment review.
4. Build a ranked backlog
Write a small hypothesis for each item: on this page or flow, change this mechanism because evidence suggests it causes this problem; measure the expected result and protect named guardrails. Keep observation distinct from diagnosis. A saved trace can show a large image delaying content, but the remedy still needs design and content review.
Rank items by Impact, Confidence, Effort, and Risk. Impact is the priority journey affected. Confidence is whether lab, field, and manual evidence agree. Effort includes coordination, not only code. Risk includes dependencies, security, release complexity, and reversibility. Critical functional or security exposure can outrank this model and needs specialist triage.
Keep owner, evidence link, hypothesis, pages, measure, guardrails, dependencies, release method, and rollback trigger.
Do not bundle unrelated refactors into a measured change unless safety requires them.
5. Release safely and retain a way back
Before deployment, record what changes, approver, release window, verification owner, success condition, rollback trigger, and restoration method. Test in a representative non-production environment where possible, including content, permissions, integrations, redirects, consent choices, and common failure paths. Production can still differ because of data, cache, configuration, and third parties.
Use a small rollout, feature flag, versioned asset, or reversible configuration where the platform supports it. Confirm cache and CDN behavior before comparing results. OWASP treats configuration and deployment management as a security-testing area; headers, permissions, file exposure, and domain or cloud settings should not be casual optimization changes.
Define an observable trigger, such as failed checkout, broken navigation, unexpected client error, or accessibility regression.
A rollback plan can reduce recovery time but cannot remove all risk; test restoration before relying on it.
6. Verify, decide, and repeat
After release, repeat the baseline functional checks and comparable lab tests. Recheck relevant devices, browsers, states, and integrations. Compare like with like: URL, cache state, device class, region where feasible, and measurement window. Confirm guardrails as well as the target metric.
Give evidence time to mature. Google notes that search changes may take hours to months to appear and suggests waiting weeks to assess whether they helped. Real-user performance data is aggregate evidence, not an instant release verdict. Record whether to keep, modify, investigate, or roll back, then re-baseline after meaningful template, platform, tag, content, or dependency changes.
The expected journey outcome improves and agreed guardrails remain intact.
Act when field or task evidence conflicts with the lab result, or a critical guardrail regresses.