Website Performance Audit Checklist

A performance audit that only checks the homepage misses most of what customers actually experience. Choose a small set of pages that represent real traffic and real business value — the homepage, the highest-traffic product or service page, the checkout or enquiry form — rather than every page on the site.

Test those pages on the devices and connection speeds that reflect the actual customer base, not just a fast office laptop on fibre broadband. For most Indian SMB audiences, a mid-range Android phone on a mobile connection is a more representative test condition than the machine sitting on the developer's desk.

"Slow" can mean several different things, and each has a different fix. Loading speed is how long the main content takes to appear. Interaction responsiveness is how quickly the page reacts once a customer actually clicks or taps something. Visual stability is whether the layout jumps around while the page finishes loading — a button that shifts just as a customer is about to tap it, for instance.

Measuring these separately, rather than relying on one combined score, points at a more specific fix. A page that loads fast but reacts sluggishly to clicks has a different underlying issue — usually something running on the browser side — than a page that is simply slow to load in the first place.

Once a page is confirmed slow, inspect the specific likely causes rather than guessing: are images sized and compressed appropriately for how they are actually displayed, or is a phone downloading a full desktop-sized banner? Are scripts — particularly third-party ones like chat widgets, analytics, and ad trackers — blocking the page from becoming usable while they load?

Fonts, caching and server response time round out the usual list of causes: custom fonts that delay text from appearing, a lack of caching that forces the browser to re-download unchanged assets on every visit, and a server that takes noticeably long to respond before the browser even starts building the page. Most real-world slow pages trace back to some combination of these five, rather than to one exotic cause.

Not every finding from an audit deserves the same urgency. Prioritise by where slowness actually affects customers and revenue — a slow checkout or enquiry form costs far more than a slow page that gets little traffic, even if the second page technically scores worse in a raw speed test.

A short list ranked by traffic and business value, next to the specific measured problem on each page, turns an audit into a sequenced plan rather than a long list of technical findings nobody has time to act on all at once.

Lab tests — run from one location, on one simulated device and connection — are useful for isolating a specific cause, but they do not always match what real customers experience across different networks, devices and locations across India. Where available, field data from real visitors is worth checking against the lab results before deciding a fix actually worked.

A fix that improves the lab score but leaves real customer experience unchanged usually means the lab test conditions did not match reality closely enough — a sign to adjust the test setup, not necessarily a sign the fix itself failed. Imagine an online stationery and office-supplies retailer whose lab test, run from a single city on a fast connection, showed a healthy score after a homepage redesign, while field data from actual customers on slower regional networks showed almost no change — the lab test simply was not exercising the conditions most of its customers were browsing under.