WordPress Speed Audit Checklist (Free Template)

A wordpress speed audit is not a single homepage score. It is a structured check of how a WordPress site actually loads, responds, and stays stable for real visitors, across the pages and journeys that matter most. Use this wordpress performance audit checklist the way a specialist would: record what you find, trace each problem to its cause, fix the bottleneck first, and then retest the same pages under the same conditions.

This post is the template. Work through it in order, keep notes as you go, and do not skip the retest step. A change that looks good in a lab test can still break a checkout, a form, or an admin workflow, so every fix below includes a check for what could break.

What does a speed audit cover?

A complete website speed audit covers the full request journey, not only the visible page. It starts with the server and database, moves through caching, theme and plugins, images and media, scripts and third parties, and ends with the interactions visitors actually perform. If you only test the homepage, you can miss slow category pages, slow product pages, a heavy search, or a checkout that stalls when a visitor tries to pay.

It also separates two kinds of evidence. Lab results come from a controlled test run and are useful for diagnosis. Field data reflects real visitors, on real devices and connections, over time. When the two disagree, trust the pattern: use lab tests to reproduce and explain a problem, and use field data to judge whether it affects enough real visits to be a priority. The WordPress Core Web Vitals guide explains how Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift fit together in that diagnosis.

The WordPress speed audit checklist

Work through this wordpress site audit checklist on a staging copy first when you can, and keep a short note beside each item: pass, fail, or not applicable, plus the page where you saw it. That note is what turns a test result into an audit.

1. Scope and baseline

• List the pages and templates to test: homepage, a key landing page, a blog post, a category or archive page, search results, and the slowest page you already know about.
• For a store, add a product page, a category page, cart, checkout, and account pages.
• Record the baseline for each page before changing anything, so later results can be compared like for like.
• Test logged-out visitors as well as logged-in users, because caching and admin bars change what you see.
• Note the device and connection type for each test, and repeat the key pages rather than relying on one run.

2. Core Web Vitals: field versus lab

• Check field data first to see which pages and interactions real visitors struggle with, then use lab tests to reproduce the problem.
• For Largest Contentful Paint, identify the actual largest element on each template: hero image, headline, video poster, or product image, and check whether it is delayed by a slow server response, a render-blocking resource, or lazy loading applied to the wrong image.
• For Interaction to Next Paint, test real interactions: menu opening, search, filtering, add to cart, variation changes, and form submission, not only page load.
• For Cumulative Layout Shift, watch the page as it loads and as ads, fonts, banners, and late images arrive. Check for missing image dimensions, injected banners, and font swaps that move text.
• Do not judge a fix by a single metric in isolation. A faster-looking load that breaks interaction, or a faster interaction that shifts layout, is not a clean win.

3. Hosting, PHP, and database

• Check the server response time for uncached pages, and whether it varies by time of day or by template.
• Confirm the PHP version is supported and current for the site, and check the PHP and database setup in the site health and hosting panel before changing versions. See the best PHP version for WordPress guide for the safe check-and-upgrade steps.
• Look for slow queries and repeated queries with Query Monitor, especially on archives, search, and WooCommerce pages. The Query Monitor tutorial shows which panels to read first.
• Check for bloated tables, expired transients, post revisions, and autoloaded options that grow on every request.
• Confirm object caching is actually helping where it is used, rather than assuming it is active. See Redis object cache for WordPress for setup and verification checks.

4. Caching and cache exclusions

• Confirm page caching is working for anonymous visitors, and that logged-in users, cart, checkout, and account pages are not served a cached page meant for someone else.
• Check cookie-based exclusions, especially WooCommerce cookies, and confirm cart and checkout behaviour after every caching change.
• Test the site with caching on and off on a staging copy before blaming a plugin or theme for a slow result.
• Check browser caching and asset handling for CSS and JavaScript, and confirm updated files are not stuck behind an old cached version.
• After a cache purge, retest the same pages, because a cold cache will look slower than a warm one.

5. Images and media

• Check the largest images on each template, and whether they are oversized, uncompressed, or delivered in a heavier format than needed.
• Confirm the hero or largest image is not lazy-loaded, and that below-the-fold images are lazy-loaded where that helps.
• Check width and height attributes, so images reserve space and do not push content around as they load.
• Review sliders, galleries, background images, and videos, which often load on every page even when they are not the main content.
• Check media in the library for unused or oversized files that were uploaded for one page and reused at full size elsewhere.

6. Scripts and third parties

• List every third-party script: analytics, tag managers, chat widgets, cookie banners, ads, social embeds, and font services.
• Test with third parties disabled on staging to see how much of the problem they explain, then re-enable them one group at a time.
• Check whether scripts block rendering, delay interaction, or load on pages where they are never used.
• Look for duplicate tools doing the same job, such as two analytics setups or two chat widgets.
• Check consent and cookie-banner behaviour, because a banner that blocks interaction or shifts layout is a speed and usability problem, not only a compliance detail.

7. Plugins and theme

• List active plugins and check what each one loads, on which templates, and whether it is still needed.
• Deactivate plugins one at a time on staging, retest, and note the change. Do not deactivate several at once and guess which one mattered.
• Check the theme for heavy page-builder output, unused libraries, and templates that load scripts for blocks or widgets that are not on the page.
• Check for overlapping optimisation plugins, which can conflict, duplicate work, or break delayed scripts and caching.
• After any plugin or theme change, test navigation, search, forms, and the admin area, not only the homepage.

8. WooCommerce cart, checkout, and admin where relevant

• Test add to cart, variation changes, mini-cart updates, cart, and checkout as real journeys, with and without caching.
• Check cart fragments and ajax requests that fire on every page, including pages where the cart is not visible.
• Confirm cart and checkout are excluded from page caching, and that fragments still update correctly after exclusions are changed.
• Test checkout with payment and shipping options in place on staging, and watch for slow or failing ajax calls.
• Check the admin area too: slow order lists, product editing, and reporting often point to the same database or plugin problems that slow the storefront. The WooCommerce speed optimization complete guide is a useful cross-check for store-specific fixes.

Tools you need

You do not need a long tool list. You need a small set of tools you trust, used the same way each time. Start with a speed test tool for repeatable lab results, a field-data source for real visitor experience, and a way to inspect what the server and browser actually do on each page. The best WordPress speed test tools guide compares the options and explains what each result can and cannot prove.

• A speed test tool for repeatable lab runs on the same templates.
• Field data for real visitor experience, checked over time rather than on one day.
• Query Monitor for slow queries, hooks, and requests on the server side.
• Browser developer tools for the waterfall, render-blocking resources, and individual script costs.
• A staging copy for every risky change, so production is never the first test.

Record the tool, the page, and the conditions beside every result. Without that note, two runs that look different may simply be two different tests.

How to prioritize fixes

Prioritization is where most audits fail. Teams fix what is easiest, or what a tool flags most loudly, instead of what is actually slowing the page. Use this order, and retest after each step before moving on.

1. Measure first. Record the baseline for each key template, and identify the bottleneck for that template before changing anything.
2. Fix the bottleneck, not the symptom. If the server response is slow, image work will not fix it. If a third-party script blocks interaction, caching will not fix it.
3. Fix what affects the most important journeys first: homepage and key landing pages, then product and checkout journeys, then archives and the admin area.
4. Fix one thing at a time on staging, and check for breakage in forms, cart, checkout, search, and navigation.
5. Retest the same pages under the same conditions, and keep the fix only if the retest improves the bottleneck without breaking a journey.
6. Repeat the loop. The next bottleneck only becomes clear after the first one is gone.

A useful rule is to ask, for each proposed fix, what page it helps, what journey it could break, and how you will know it worked. If you cannot answer all three, do not ship it yet.

Your next step

Copy this checklist into your audit notes, work through it template by template, and keep the baseline and retest results side by side. If you want help running the audit on your own site, the next step is to request a free speed audit from ProSpeedGuy.

Common Questions

Frequently Asked Questions

Clear, honest answers about running a WordPress speed audit, from scope to retesting.