Two providers have offered to audit your site’s speed before doing any work. One describes it in a sentence; the other sends a page of questions about your hosting, your plugins and which pages bring in customers. You have no way yet to tell which approach will leave you with something useful, or what “audit” is supposed to mean when the subject is loading time.
This website speed audit checklist answers that. It sets out what a speed audit includes when it is done properly, how its findings should be ranked, and how before-and-after evidence should be recorded, so you can run the checks yourself or judge whether someone else’s review earned its fee.
What a speed audit is for
An audit exists to answer three questions in plain language. Where is the time going? Which causes are worth fixing, in which order? What will each fix cost in effort and risk? A list of tool warnings answers none of these, because tools report symptoms without knowing your site, your visitors or which pages earn your money.
It is also worth being clear about what a speed audit is not. It is not a security review, which looks at updates, users, permissions and malware; that has its own checklist in what a website security audit checks. It is not an SEO audit either, though the two touch at Core Web Vitals. And it is not the fixing itself. Some providers combine the audit with the work, which is fine, as long as the findings are written down before anything changes. Each area the checklist touches is explained on its own in our guide to website performance.
The website speed audit checklist
The sections below follow the order a careful reviewer usually works in, from the widest view to the details. Not every item applies to every site.
1. Scope and baseline
- Agree which pages are in scope. At minimum: the homepage, the top landing pages from search and ads, one example of each page type (service page, blog post, product page, category page), and any form, cart or checkout step.
- Record each page’s current measurements on mobile and desktop, with the date, tool and test location. Several runs per page, not one.
- Note the platform, theme or builder, hosting provider, PHP version, and the list of active plugins or apps.
- Confirm a recent backup exists and whether a staging copy is available for testing.
Our post on how to test website speed properly covers repeat runs and consistent conditions in more depth. Without this step, nobody can later show that anything improved.
2. Real-user data
- Check the field data at the top of PageSpeed Insights, for the page and the whole origin, where Google has enough data.
- Check the Core Web Vitals report in Search Console for groups of failing URLs.
- Note which metric fails, on which device. A site failing on layout shift needs different work from one failing on loading.
Lab tests and real-user figures often disagree; the reasons are explained in field data versus lab data. An audit should say which it is relying on for each finding.
3. Server and hosting
- Time to first byte for cached and uncached pages, measured separately.
- Whether page caching is actually working, checked through response headers rather than assumed.
- PHP version, and whether OPcache and an object cache are available.
- Signs of resource limits: errors in the host panel, slow periods at busy times, or a server that is far from most visitors.
- Compression and HTTP version on the responses.
4. Caching and delivery
- Which caching plugin or host caching is in use, and whether more than one is active.
- What is excluded from the cache, and whether the exclusions are right (cart, checkout, account pages).
- Browser cache lifetimes on static files.
- Whether a CDN is in use, and whether it suits where visitors are.
5. Images and media
- The largest images on key pages, their file size and the size they are displayed at.
- Formats in use, and whether a smaller modern format is being served where supported.
- Which image is the largest element on the first screen, and whether it is lazy-loaded by mistake.
- Sliders, background videos and embedded videos on key pages.
6. CSS, JavaScript and fonts
- Total weight of CSS and JavaScript on each key page, and how much of it is unused there.
- Files that block rendering, and what depends on them.
- Font families and weights loaded, and from where.
- Icon libraries loaded in full for a handful of icons.
7. Third-party scripts
- Every external domain the page contacts, and which tool each one belongs to.
- Duplicated tags, abandoned tools and scripts loading on pages that do not use them.
- Chat widgets, social feeds, review badges, maps and embeds.
8. Platform checks
- On WordPress: plugins that load assets site-wide, the page builder’s own performance settings, autoloaded data size, scheduled tasks and admin-ajax requests on the front end.
- On WooCommerce: cart fragment requests, checkout scripts, product image sizes and whether customer sessions bypass caching more than they need to.
- On hosted platforms such as Shopify: apps that inject scripts, leftover app code in the theme, and theme features that load whether used or not.
9. A real phone
- Load each key page on an ordinary mid-range phone over mobile data, and note anything the tools missed: popups that cover the content, buttons that do not respond at first, text that jumps.
- Submit a form and, on a store, go as far into checkout as is safe.
Turning findings into a plan
The checks are half of it. The other half is writing each finding so that someone can act on it. A useful finding reads something like this invented example: the homepage hero is a large uncompressed photo shown at a fraction of its width; it was spotted in the waterfall of a mobile test, where it is the biggest single download; the same template is used on three service pages, so all four are affected; it delays the largest contentful paint on phones; replacing it is quick and low-risk, so it belongs in the first batch.
That one paragraph carries everything you need: what is wrong, how anyone could check it, where it applies, why it matters, what fixing it involves and when to do it. If a finding in a report you receive is missing the evidence or the pages affected, ask for them.
Findings should then be grouped into an ordered plan: the changes with the biggest likely effect and lowest risk first, then the ones needing more care, such as deferring scripts or changing caching rules, then the structural ones, such as a heavy theme or the wrong hosting. A good report also says what it recommends not doing and why. “Your score would rise if we removed the chat widget, but your team uses it for sales, so we suggest delaying it instead” is the kind of sentence that shows someone has thought about your business rather than the tool.
Before and after evidence
Whoever carries out the fixes, the result should be shown the same way the baseline was recorded: same pages, same tools, same test location, same device settings, several runs each. A single good screenshot after the work proves very little, because scores vary from run to run.
Field data takes longer. Google’s real-user figures cover a rolling period of recent visits, so an improvement shows up gradually over the following weeks rather than the next day. A fair report says so, and suggests a date to look again. You can repeat quick lab checks yourself in the meantime with our free website speed test, as long as you compare like with like.
Ask, too, for a record of what was changed: which settings, which plugins added or removed, which files edited. If something misbehaves a month later, that list saves hours.
Signs the review was not worth paying for
- It reports only the score and the tool’s warnings, in the tool’s order.
- It tested only the homepage.
- It has no mobile results, or no record of how tests were run.
- Every finding is marked high priority.
- It recommends a new theme, a new host and a premium plugin without showing evidence for any of them.
- It promises a particular score once the work is done.
If you are trying to decide whether a speed audit is worth doing at all, start with how slow pages turn into lost sales: the pages that bring customers are the ones that justify the effort.
Frequently asked questions
How many pages should a speed audit test?
Enough to represent the site. That usually means the homepage, the main landing pages, one page of each template type, and any form or checkout step. Testing one page of each template matters because a problem found on one product page usually applies to every product page built the same way.
Can I run this audit myself without technical knowledge?
You can do the baseline, the real-user data checks and the real phone test yourself, and they are often the most revealing parts. The server, caching and script sections need more experience to interpret, and some checks need access to hosting or plugin settings you may prefer not to change.
Should the audit be done on the live site or on staging?
Measurements should come from the live site, because staging often runs on different server settings and has no real traffic. Testing fixes is a different matter: changes to caching, scripts or the theme are safer to try on a staging copy first, then repeat on the live site once they work.
How often should a website have a speed audit?
A full audit makes sense before a redesign, after a migration, or when real-user data starts failing. In between, a short check after major updates or new plugins usually catches problems early, without repeating the whole review.
Our own website speed optimisation work follows the same pattern: a full audit, a prioritised fix list, changes made only with your approval, then a re-test with a before-and-after comparison. Use the checklist above to hold us to the same standard you would expect from anyone else.
Next in this series: Should I Hire Someone to Speed Up My Website?
