Website Performance Testing Checklist for Every Release

A website performance testing checklist must preserve comparable evidence. One PageSpeed Insights score cannot prove a release changed real user experience. Start with scope, lock conditions, trace the cause, and verify production.

For full explanations, use how to test website speed and Core Web Vitals.

1. Define the Performance Contract

• List critical templates and journeys for mobile and desktop.
• Name regions, authentication, consent, and locales.
• Map each synthetic test to its production URL group.
• Record budgets, release owner, and exception evidence.

Good is LCP <= 2.5 seconds, INP <= 200 milliseconds, and CLS <= 0.1. Poor is LCP > 4 seconds, INP > 500 milliseconds, and CLS > 0.25. There is no new 2026 metric.

2. Capture the Field Baseline

• Record exact URL, URL or origin scope, and device class in PageSpeed Insights.
• Capture LCP, INP, and CLS.
• Check CrUX Vis trends and annotate deployments or experiments.
• Treat missing public field data as unavailable evidence, not a pass.

The CrUX Dashboard was deprecated after November 2025. Use CrUX Vis or the CrUX History API.

3. Lock the Lab Conditions

• Record URL, build, browser, device, viewport, network, and cache state.
• Fix authentication, flags, cookies, consent, locale, and data.
• Hold background work constant and repeat comparable runs.
• Keep the report, trace, waterfall, screenshots, and filmstrip.

Lighthouse is lab evidence. A load-only run cannot represent INP, which requires interactions. Total Blocking Time can indicate main-thread pressure but is not INP.

Map the Release Evidence Loop

1. 01 / scope

   Scope

   Pages, journeys, users, and budgets.

   measure

2. 02 / baseline

   Baseline

   Field trend and repeatable lab run.

   trace

3. 03 / diagnose

   Diagnose

   Trace resources, tasks, and shifts.

   compare

4. 04 / gate

   Gate

   Compare budget and risk deltas.

   release

5. 05 / verify

   Verify

   Confirm the production field outcome.

4. Diagnose the Failed User Outcome

• Confirm the LCP element, slow interaction, and shift trigger.
• Inspect priority, redirects, caching, compression, and third parties.
• Tie recommendations to a resource, task, element, or request.
• Change one high-confidence bottleneck where practical.

Use the performance report guide to separate workload problems, regressions, and clues.

5. Check Performance Fix Tradeoffs

• Verify navigation, forms, payments, authentication, consent, and analytics.
• Re-run accessibility checks after UI changes.
• Check images, delayed scripts, error states, and slow networks.
• Compare budgets under the same build conditions.

A higher score is invalid if required behavior breaks. Preserve product assertions and performance artifacts.

6. Apply the Release Gate

• Compare the candidate with a named baseline under identical lab settings.
• Gate critical journeys on agreed budgets and statistically meaningful deltas.
• Review failures by page template, device class, and risk.
• Do not average away one severe page group.
• Require a named owner, reason, mitigation, and expiry for exceptions.
• Keep a needs-review state when data or environment validity is uncertain.

Core Web Vitals thresholds are stable targets. Resource and lab budgets should reflect your product and baseline.

7. Verify in Production

• Confirm the expected build and optimization reached production.
• Run an immediate synthetic smoke check on critical URLs.
• Watch product errors and business outcomes for tradeoffs.
• Annotate the deployment in performance trend views.
• Revisit field LCP, INP, and CLS when enough post-release evidence exists.
• Add a confirmed regression scenario to the permanent suite.

Field data aggregates visits and will not change immediately. Annotate deployments when explaining outcomes.

Frequently Asked Questions

Which Core Web Vitals thresholds belong in the checklist?

Use LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 as good. Poor begins above 4 seconds, above 500 milliseconds, and above 0.25 respectively.

Should performance testing happen before or after release?

Both. Lab checks catch pre-release regressions, while field data verifies real users after deployment. Keep page groups and release annotations consistent.

How many Lighthouse runs should I use?

Use several identical runs and summarize a representative result such as the median. One unusually fast run is not a baseline.

Does a good Lighthouse score prove good Core Web Vitals?

No. Lighthouse is a controlled lab test. Field Core Web Vitals reflect real users, and a load-only run cannot produce representative INP. Use lab data for diagnosis and field data for population outcomes.

What should block a website release?

Block regressions against an agreed performance budget on critical journeys, severe functional tradeoffs introduced by an optimization, and unexplained measurement invalidity. Use risk and baseline deltas, not a generic score alone.

Keep the Checklist Attached to Evidence

A strong checklist preserves scope, field baseline, controlled run, trace, change, decision, and production result beside the build.