Online Tool Store
· 5 min read
A Practical Page Speed Checklist for Your Site
Manesh Jayawardhana
CIO & Co-founder
Your site “feels slow” and someone has forwarded you a performance report with thirty red items on it. Half of them are the same problem described three different ways, a couple are things you can’t change because they come from a third-party script marketing insists on, and one is genuinely the reason the page takes four seconds to show anything. The report doesn’t tell you which is which.
That’s the real problem with page speed work: it isn’t that the advice is wrong, it’s that it arrives unsorted. A checklist you actually walk through, in order, beats a score you keep refreshing.
What a page speed audit actually involves
Loading a page is a sequence, and each stage can be the bottleneck. The server has to respond. The HTML has to arrive. The browser has to fetch the CSS and fonts before it can paint anything. Then images and scripts land, and the layout may shift while they do.
An audit is just checking each stage in that order and asking a plain question: is anything here blocking the next step longer than it needs to? Fix a bottleneck early in the sequence and everything downstream improves. Fix something late while an early stage is still slow and the number barely moves — which is exactly how people end up convinced performance work is futile.
Why people get stuck here
- Scores are not diagnoses. A number tells you there’s a problem, not where it is. Two sites with the same score can need completely different fixes.
- Lab results don’t match real users. A test run from a datacentre on fast fibre will not reflect a phone on a train.
- Third-party scripts are politically hard. The analytics, chat widget, and consent banner are often the heaviest things on the page, and they’re rarely the developer’s call.
- Fixes get done in the wrong order. Compressing images matters less than an unoptimised font load that blocks first paint.
- Nobody re-checks. A site is fast the week it launches and slow six months later because features accumulated.
What a good checklist looks like
It’s ordered by impact, not by category
Render-blocking resources and server response time come before image formats. A checklist that lists items alphabetically makes you do the cheap work first and the important work last.
Every item is verifiable
“Optimise your images” isn’t actionable. “Is any image served larger than the box it renders into?” is — you can answer it, and you know when you’re done.
It tracks state as you go
An audit takes more than one sitting. Being able to tick items off, leave notes, and come back to a half-finished list is the difference between a checklist you complete and one you abandon at item nine.
| Stage | What To Check | Typical Culprit |
|---|---|---|
| Server response | Time to first byte on a cold, uncached load | Slow database queries or no caching |
| First paint | CSS and font files blocking render | Web fonts loaded without a fallback |
| Content load | Image dimensions vs. displayed size | Full-resolution hero images |
| Interactivity | Long JavaScript tasks on the main thread | Third-party tags and heavy bundles |
| Stability | Elements moving after load | Images and ads without reserved space |
Common mistakes to avoid
- Chasing a perfect score. Going from 60 to 85 is worth real work. Going from 95 to 99 usually isn’t.
- Testing only the homepage. Most traffic lands on article and product pages, which often carry heavier templates.
- Testing only on desktop. Mobile is where the constraint actually bites.
- Lazy-loading the hero image. It’s the one image you want loaded immediately; deferring it makes the page feel slower even as metrics look tidier.
- Deleting a script without checking what depends on it. The consent banner may be heavy, but removing it is not a performance decision.
How to do it with Page Speed Checklist
Online Tool Store’s Page Speed Checklist is an interactive audit list that runs in your browser, so your notes stay on your own machine.
- Open the checklist and read through the full list once before changing anything — it’s worth knowing what’s coming.
- Start at the server-response items and work down in order rather than jumping to whatever looks easiest.
- Tick each item only once you’ve actually verified it on a real page, not just assumed it.
- Note the items you can’t act on yourself — third-party tags, CDN configuration — so they’re visible when you hand the audit to whoever owns them.
- Re-run the same checklist after the fixes ship, and again in a few months, to catch the slow drift back.
Pair it with the HTML Size Analyzer and the Gzip Compression Test for the payload side of the picture.
Frequently asked questions
Does this tool measure my site’s speed?
No — it’s a structured audit checklist, not a measurement tool. It tells you what to check and in what order; you use your browser’s own developer tools or a testing service to get the actual numbers.
How often should I redo a page speed audit?
After any significant template or dependency change, and otherwise a couple of times a year. Performance regresses gradually as features and tags get added, so a periodic pass catches drift before users do.
Is a checklist enough, or do I need a paid monitoring service?
For a small site, a checklist plus your browser’s developer tools is genuinely enough. Continuous monitoring earns its cost once page speed maps directly to revenue and you need to catch regressions the same day they ship.
Final thought
Performance work rewards order over effort. Walk the page load from server to paint to interaction, fix the first thing that’s actually blocking, and re-measure — one deliberate pass beats a week of scattered tweaking.