Start with the decision, then select the tool
Name the page, audience, and task at risk before running anything: a mobile product page, checkout, or lead form. Then choose the evidence type. Lab data is a controlled test for repeatable debugging. Field data is aggregated real-user experience for prioritizing patterns. A browser trace helps explain local runtime work. These are complementary, not interchangeable.
Ask what prevents a visitor completing one important task, not how to reach a score.
Use one audit, available field data, and one diagnosis tool before adding more products.
A result applies to the tested URL, conditions, or sample; it is not a verdict on every visitor.
Use Lighthouse and PageSpeed Insights for repeatable page-load audits
Lighthouse is an open-source automated audit that runs in Chrome DevTools, from the command line, or in continuous integration. It audits performance, accessibility, SEO, and more. PageSpeed Insights runs Lighthouse diagnostics for a URL and presents real-user data when available. Use either to baseline a representative page, investigate failed audits, and compare a controlled retest after a defined change.
How the audited page behaved in its test setup and which audits merit investigation.
A good Lighthouse score does not necessarily mean real-user experiences are good; Google documents that lab and field results can differ.
Retest the same page and settings after a change; do not use it as a one-time gate.
Use field data to prioritize the experience that users actually had
PageSpeed Insights field data comes from the Chrome User Experience Report and covers a trailing 28-day period. It reports measures including Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Search Console’s Core Web Vitals reporting helps when you need groups of pages rather than one URL. Use field data to decide which template, device group, or issue deserves effort first.
Check whether the result is page-level or origin-level and whether the URL had enough data.
Field data is historical and privacy-aggregated, so it cannot confirm a release’s effect immediately.
Google recommends LCP within 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1.
Use Chrome DevTools when an audit needs an explanation
When an audit or field pattern points to slow loading, delayed interaction, or visual movement, record the journey in Chrome DevTools Performance. It records CPU profiles and can show local LCP, CLS, and, after interaction, INP. Its timeline helps a developer investigate browser work instead of guessing from a recommendation list.
Use a viewport, CPU, and network condition that reasonably resemble the affected audience.
A trace reflects the device, connection, cache state, and journey recorded. Reproduce relevant journeys before generalizing.
Record the suspected cause, change, and expected visitor effect.
Pair automated accessibility checks with knowledgeable human evaluation
Use an accessibility evaluation tool to catch machine-testable problems early and repeatedly. W3C WAI maintains a tool list and selection guidance, but says no tool alone can determine whether a site meets accessibility standards. Use automated findings to create a review queue, then inspect representative pages, keyboard operation, focus behavior, error handling, and content with qualified reviewers.
Faster discovery and prevention of repeatable defects.
It cannot determine full accessibility conformance or substitute for human evaluation.
Do not market an automated result as legal compliance; obtain qualified accessibility and legal review when it matters.
Use focused security tools carefully and within authorization
Mozilla’s HTTP Observatory examines HTTP headers and other key security configurations, giving administrators a starting point for public-facing header hygiene. Validate proposed header changes outside production because policies can affect scripts, embedded services, and user flows. It assesses a slice of security, not every application risk.
OWASP ZAP can passively scan traffic and actively test applications, but only test systems you are authorized to test.
ZAP says active scanning is a real attack that can put targets at risk. Passive scanning can miss authenticated or unvisited areas.
For payment, authentication, sensitive data, or material findings, involve qualified security professionals.
Turn tool output into SIU remediation, not score chasing
Use a durable loop: capture a baseline, identify one plausible cause, make the smallest safe change, retest the same path, and observe the field trend after enough time. Keep the visitor task central. Reducing a blocking asset is valuable only if it improves useful experience without breaking purchase, sign-in, accessibility, consent, or analytics behavior.
Favour changes backed by field impact, a reproducible trace, or a clear user-facing defect.
Use staging, an owner, acceptance criteria, and a rollback plan. SIU prevents avoidable experience degradation.
Keep the metric, test conditions, and completed visitor task in the change record, not only the score.