How to Run a Website Speed Audit That Leads to Better Decisions

Start with a page map

A single homepage score cannot represent a whole site. Group pages by template—home, article, category, product, checkout, and logged-in views—then choose one high-traffic example from each group. Record device, region, cache state, and test time. This creates a baseline you can reproduce instead of a screenshot you cannot explain later.

Read the three layers separately

Use lab tests to reproduce rendering work, field data to understand actual visitors, and server logs to find backend delays. A slow lab result with healthy field data may be a test-location issue. Healthy server response with poor interaction latency points toward browser work. Keep these layers separate before choosing a fix.

• Representative URL selected
• Mobile and desktop recorded
• Cold and warm cache compared
• Field data checked where available

Prioritize by user impact

Rank issues by affected traffic, severity, and effort. Large hero media, render-blocking resources, excessive client code, and slow uncached responses often deserve attention before tiny compression wins. Write the expected user outcome beside every task so the team does not optimize a score while leaving the experience unchanged.

Retest without moving the goalposts

Use the same URL, location, device profile, and cache condition. Run several samples and compare the median rather than celebrating the best run. Keep a short change log. If the result does not improve, revert or investigate instead of stacking more changes onto an uncertain baseline.