Website Performance Audit Checklist

Do not audit only the homepage. Choose a small set of pages that carry real traffic and real value: the homepage, the busiest product or service page, and the checkout or enquiry form. Traffic data settles arguments. Pull the traffic figures from your analytics before choosing, because the pages you assume matter and the pages visitors open are often different lists.

Test them on realistic hardware. A fast office laptop on fibre broadband proves little, so run the same pages on a mid-range Android phone over a mobile connection, the condition many visitors face. Write each test condition down.

“Slow” hides three different problems. Loading is how long the main content takes to appear, responsiveness is how quickly the page reacts to a tap, and stability is whether the layout jumps while loading. Shifting buttons cause mistaken taps. Write the three results in separate columns of the worksheet, because one blended score cannot tell the developer where to start, whichever tool produced it.

Separate scores point to separate fixes. A page that reacts slowly to clicks usually has scripts busy in the browser, while a page that appears slowly usually has heavy assets or a slow server.

Inspect causes before guessing. Check whether a phone is downloading a full desktop banner instead of an image sized for its screen, and whether the file was compressed at all before upload. Then look at scripts. Third-party scripts such as chat widgets, analytics and ad trackers often block the page from becoming usable while they load, so list each one and ask what it earns.

Fonts, caching and server response complete the list. Custom fonts can delay text, missing cache headers force a re-download of unchanged files on every visit, and a slow server keeps the browser waiting before it builds anything. Most slow pages mix several of these causes. Image formats matter too: a modern format such as WebP is often smaller than an older JPEG at similar quality, and minified scripts load faster than unminified ones. Response headers reveal caching settings. Scripts deserve a named owner.

Rank findings by customer impact. A slow checkout or enquiry form costs more than a slow page nobody visits, even when the quiet page scores worse in a raw speed test.

Write the plan as a short list. Put each page next to its measured problem, its traffic and its business value, so the audit becomes a sequenced plan instead of a pile of technical findings. Estimate effort beside impact: replacing a banner image is an afternoon, while replacing a chat widget may need a vendor decision and a word with the sales team.

Lab tests run from one place. They simulate a single device and connection, which makes them good for isolating a cause but poor at representing visitors on different networks, devices and locations. Where field data from real visitors exists, compare it with the lab result before declaring any fix successful, because the two often disagree.

A better lab score alone proves little. If field data barely moves after a homepage redesign, the lab conditions probably did not match how customers browse, so adjust the test setup before concluding the fix failed. Keep every dated worksheet, because a slow drift across many small releases is invisible in any single test and obvious in a year of them.