How to audit your website's performance

Here's a method you can actually repeat, on any site, with free tools.

Step 1: choose the pages to audit

Don't audit "the website." Audit the pages people actually use. For most sites that's four or five templates: the homepage, a main landing or category page, a typical product or article page, and whatever the conversion step is (checkout, signup, contact). Each template tends to have its own performance personality, so testing only the homepage tells you about the homepage and nothing else.

A common blind spot is the page that makes you money. The homepage is often the fastest page on the site, because it gets the most attention. The product page three clicks in, the one with the third-party reviews widget and the video, is where visits quietly die.

Step 2: get the field data first

Start with how real users experience those pages. PageSpeed Insights shows field data from the Chrome UX Report at the top of its report, the 75th percentile of real Chrome visits over the last 28 days. For a site-wide view grouped by status, use the Core Web Vitals report in Search Console.

Field data is the truth about your users, but it has two limits. Low-traffic pages may not have enough data to appear, and the 28-day window means it reacts slowly. So it tells you where you stand, not why. For the why, you go to the lab.

Step 3: run lab diagnostics

Lab tools load the page in a controlled environment and hand you the details. PageSpeed Insights already ran Lighthouse for you; scroll past the score to the diagnostics, which is the useful part. For a deeper look at exactly what loaded and when, WebPageTest gives you a request waterfall and a filmstrip of the page painting frame by frame.

Ignore the big number for a second. A score out of 100 is a summary, not a diagnosis. The diagnostics underneath are where the work is.

Step 4: read the report properly

The findings that move the needle, in rough order of how often they matter:

• The LCP element and its timing. What's the largest thing, and what's holding it up? (See optimising LCP.)
• Render-blocking resources. CSS and JavaScript delaying the first paint.
• JavaScript cost. Unused script, long tasks, and the Total Blocking Time that stands in for INP in the lab.
• Image weight and sizing. Oversized or wrong-format images are the most common easy win.
• Layout shifts. Media without dimensions and late-injected content, the stuff that drives CLS.

If the metrics themselves are unfamiliar, our guide to Core Web Vitals defines each one.

Step 5: prioritise by impact, mobile first

Lighthouse already estimates time saved per opportunity. Trust that ordering more than your gut. Then weight everything toward mobile: phones have slower processors and worse networks, mobile usually fails first, and it's what Google leans on. A fix that helps desktop but not mobile is often polishing the part that was already fine.

Pick the top two or three. Resist the checklist.

Step 6: fix, then re-measure

Make the changes, then re-run the same pages and compare. Lab numbers update immediately, so you'll see the diagnostic effect right away. Field numbers lag, because CrUX averages a 28-day window, so give those a few weeks. Our guide on improving Core Web Vitals has the specific fixes.

Step 7: from one-off audit to ongoing monitoring

Here's the uncomfortable truth about audits: they go stale the moment you finish. An audit is a photo. Performance is a film. The week after you hand over a clean report, someone adds a marketing tag, swaps a hero image, or ships a framework upgrade, and the page you certified as fast starts slipping. Nobody notices, because nobody's looking, until traffic or sales dip and someone asks why.

The fix is to stop treating performance as a project and start treating it as a vital sign. Check the same pages on a schedule, keep the history so you can see trends, and get told when something regresses instead of finding out by accident.

Which tools to use

All of these are worth knowing. They overlap, but each is good at something different.

The free official tools are excellent for a point-in-time audit. The gap they leave is time: none of them watch the page for you between audits. That's the layer PerfHawk adds.