My WordPress Performance Audit Checklist: What I Test Before Changing Anything

The fastest way to waste an afternoon is to optimize something that was never the problem. My WordPress performance audit checklist starts with evidence: which pages are slow, under which conditions, and what the website must still do when the work is finished.

A WordPress performance audit investigates the causes of slow loading and sluggish interactions before settings or code changes. It should cover business-critical journeys, representative pages, field and lab measurements, server response, caching and CDN behavior, request waterfalls, assets, WordPress configuration, database work, background tasks, and third-party services.
The result should be a prioritized set of testable explanations, with a baseline and functional checks for judging each proposed change.

This is the diagnostic work behind my WordPress speed optimization services. A report full of red warnings is a starting point. It still needs someone to work out which warnings explain the complaint.

WordPress performance audit checklist: the six stages

Work through scope and journeys; field and lab baselines; server and cache behavior; waterfalls and assets; WordPress and database work; then functionality and priorities. Follow the evidence between stages rather than treating them as six unrelated scores.

For example, a slow first screen with fast HTML needs a different investigation from a checkout waiting on a shipping service. Both may be described as “the website is slow.” That description is useful for opening the conversation, less useful for changing a setting.

Start with scope, not PageSpeed

Ask what changed, when the problem occurs, and who experiences it. A complaint from logged-in customers on mobile deserves its own test. It should not disappear behind a fast desktop homepage result.

Choose high-traffic pages and commercially important journeys, including less popular pages whose failure would matter. Sample different templates, languages, and personalization states where they affect behavior. This matrix is a starting point; replace the examples with actual URLs and remove irrelevant rows.

Record the exact steps as well as the URL. “Open a product” and “change its variation after accepting cookies” are different tests. Use safe test accounts and agreed payment test modes; an audit should not produce accidental orders.

Preserve the baseline before touching settings

A screenshot without test conditions is a souvenir. Keep versions, configuration exports, and measurement details in editable notes so the next person can repeat the comparison.

My practical starting method is three comparable lab runs per selected profile, recording the median and checking the spread. That is a working method, not a Google requirement. Investigate noisy results and repeat when the variability prevents a useful conclusion. Never combine cold and warm cache states into a convenient average.

Confirm a current files-and-database backup and how restoration would work. A completed backup job does not prove a successful restore. Use staging for risky experiments, protect copied customer data and account for differences between staging and production. Record how settings, code, and data would be reversed separately; restoring an old store database can overwrite new orders.

Read field and lab data separately

Field data describes measured visits from real people. Lab data describes a controlled test. They answer related questions, but neither should wear the other’s name badge.

PageSpeed Insights documentation explains its two sources: Chrome UX Report field data and Lighthouse lab testing. Check whether the displayed field result covers the tested URL or the wider origin. Its rolling 28-day view will not instantly reflect a change made this morning.

Missing field data is not a pass or a failure. CrUX eligibility depends on factors including public discoverability and enough eligible traffic. An origin-level result also cannot prove that a particular product page or customer journey is healthy.

The current Core Web Vitals are Largest Contentful Paint (LCP), measuring when the largest eligible visible content is rendered; Interaction to Next Paint (INP), measuring responsiveness to interactions; and Cumulative Layout Shift (CLS), measuring unexpected visual movement. Google’s good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile, separately for mobile and desktop.

First Contentful Paint (FCP) marks the first rendered text or image content. Time to First Byte (TTFB) describes the wait for the first response byte. Total Blocking Time (TBT) measures main-thread blocking during a lab measurement window. These are supporting diagnostics, not three more Core Web Vitals. TBT can help investigate responsiveness, but it is not a field INP result.

Lighthouse’s performance score combines weighted metric scores. Keep the underlying metrics and traces. A higher score does not, by itself, establish that the interaction customers complain about became faster.

Check the server path and cache behavior

Before blaming the page builder, separate the trip to the website from the work WordPress performs. DNS locates the server; connection and TLS negotiation establish communication; a CDN may answer near the visitor or pass the request to the origin.

Navigation TTFB can include redirects, connection setup, and response waiting. A tool’s initial server-response diagnostic may cover a narrower interval. Record the definition used rather than relabeling every server timing as full TTFB.

Inspect the HTML response headers alongside timings. Establish which cache layer answered, what was cached, and which cookies or rules cause bypasses. Test a cold request and a subsequent warm request when that distinction matters. A browser-cache hit is not the same evidence as an edge-cache hit, and cached images do not prove cached HTML.

A fast cached landing page says little about uncached PHP execution. Investigate slow administration, REST requests, AJAX actions, and logged-in pages separately. Compare origin and edge behavior through an authorized diagnostic route without casually disabling live protection or purging the whole site.

Where server work is slow, examine resource saturation, PHP workers, expensive application activity, and external waits. Persistent object caching may reduce repeated data retrieval; it does not replace full-page caching or fix every slow query. The question is whether it helps this workload.

This distinction explains why WordPress can stay slow after installing a caching plugin. Plugin selection belongs after diagnosis; my FlyingPress vs WP Rocket comparison covers that separate decision.

Read the waterfall and page weight

A request waterfall shows when resources start, what they wait for, and how long they take. Pair it with transfer sizes and a browser performance trace. Downloading JavaScript and executing it are different costs.

Use the DevTools Network panel to inspect request timing, initiators, and delivery. Look for dependencies that postpone the first screen: a stylesheet revealing an image late, fonts on another origin, or a script that creates content only after more requests finish.

Identify the actual LCP element on each tested viewport. Check its responsive image source, transferred size, discovery time, and loading priority. Do not assume the desktop hero is also mobile LCP. A preload for the wrong resource can compete with the resource the page needs; lazy loading above-the-fold content also deserves investigation.

Review CSS, JavaScript, fonts, duplicate resources, ads, chat, consent tools, and analytics. Ask which features require each file and when. A lower request count alone is not a diagnosis: a small essential request can be inexpensive, while one large script can occupy the main thread long after downloading.

Coverage records CSS and JavaScript usage during the session you exercise. “Unused” while staring at a page does not mean unnecessary after opening its menu, submitting a form, or changing a variation. Asset unloading, delayed JavaScript, and unused-CSS removal need that functional context before implementation.

Inspect the WordPress application layer

Browser measurements cannot explain every database query or scheduled job. Review WordPress, PHP, the active theme, builder, plugins, and custom code together. Record optimization responsibilities so two components are not unknowingly processing the same files.

Plugin count is a poor substitute for profiling. A single integration that waits on a remote API can matter more than several small plugins. Identify slow queries, repeated work, and external requests, then reproduce the relevant route under controlled conditions.

Inspect autoloaded options by total volume and large individual entries. Establish who owns an option and why it is loaded before considering a change. Likewise, a large database table is an investigation target, not permission to delete it. Cleanup needs a backup, an ownership check, and a rollback path; “delete all transients” is not my audit method.

Review scheduled events, overdue or failed tasks, and Action Scheduler queues where present. WordPress Cron checks scheduled tasks on page loads rather than running continuously like a system scheduler. Record whether the site uses the default trigger or a server-managed arrangement before diagnosing timing problems.

Connect background work to the complaint’s timing. Imports, backups, email queues, and synchronization can compete with visitor requests. Observe queue behavior and server evidence before changing schedules; a backlog may be a symptom of failing work rather than insufficient frequency.

Site Health adds environment signals. Review persistent object-cache availability and evidence of its usefulness, plus errors and warnings in relevant logs. Keep logs and exported diagnostics private, redact sensitive data, and avoid displaying debugging output to visitors.

Test the functions that pay the bills

A cached page can look excellent while the buying journey remains slow. Test navigation, search, filters, forms, and consent, then the account, membership, and multilingual states the site actually supports.

For WooCommerce, follow variation selection, cart updates, shipping calculation, and the agreed checkout flow. Record the request that waits, the visible feedback, and whether the operation completes. A shipping integration delay calls for different evidence from a delayed button handler.

Check agreed tracking in the appropriate consent state. Successful page rendering does not establish that lead submission, payment handoff, or analytics still works. Establish these functional expectations before optimization so the after-test has something concrete to compare.

A change that wins a lab point by disabling a required function has failed the brief. The website does not get paid for looking fast in a screenshot.

Use tools as evidence

PageSpeed Insights supplies field context and Lighthouse diagnostics. DevTools contributes request, coverage, and main-thread investigation. Query Monitor can expose database queries, PHP errors, and HTTP API requests, including component attribution where available. Its diagnostic view is not automatically a measurement of a cached anonymous visit.

For a broader comparison, see my WordPress speed test tools guide. Choose tools for the question you need answered, then retain the settings and results. Installing five diagnostics without a question mostly creates five places to look confused.

I created Speed Analyzer to bring useful checks into WordPress. Its documented modules cover server TTFB, page assets, autoloaded options, object caching, PageSpeed performance and diagnostics, recommendations, and a PDF report. Those results support an audit; they do not establish every cause, inspect every customer journey, or replace request-level investigation.

I also created Dr. Speed — AI Assets Scanner and Code Unloader. The former identifies and verifies page-level CSS/JavaScript unloading opportunities; the latter applies unloading rules. Automated checks reduce uncertainty within their coverage. They do not eliminate the need to test the functions and states important to your website.

Turn observations into testable explanations

Write down what you observed separately from what you suspect. The examples below are illustrative, not results from a client audit. Risk depends on the proposed change and the website.

Prioritize repeatable problems by user impact, expected benefit, implementation risk, and effort. A modest improvement to a frequently used checkout can deserve more attention than an alarming warning on an obsolete page. “Collect more evidence” is a valid next action.

Change one meaningful variable at a time where practical, retain the previous configuration, and define the comparison in advance. If the expected improvement does not appear, revisit the explanation rather than keeping the change because the setting sounds sensible.

The final pre-change checklist

Before implementation, confirm each item in this WordPress performance audit checklist:

☐ Representative URLs, templates, devices, and user states are recorded.

☐ Business-critical journeys and required functionality are agreed.

☐ Field and lab baselines are separated, with dates and test conditions.

☐ Server, cache, and CDN evidence identifies the tested delivery path.

☐ Waterfalls, assets, and relevant main-thread work are documented.

☐ WordPress, database, and background-task evidence supports the diagnosis.

☐ Current versions, settings, and relevant custom code are recorded.

☐ Backup, staging needs, and a practical rollback route are confirmed.

☐ Hypotheses are prioritized, with verification steps and risks.

☐ Success criteria and functional retests are agreed before changes begin.

Keep the evidence references next to the findings. The next developer should be able to understand why a change was proposed without reverse-engineering your afternoon.

My verdict

A useful audit narrows the problem enough to justify the next change. Its value is not proportional to the number of pages in the report. Every so often the right result is a small, well-supported fix. Occasionally it is evidence that a more in-depth investigation is needed.

A site owner can use this checklist to establish scope and a reliable baseline. Complex stores, private account areas, and persistent server issues often merit professional investigation. Read my guide to choosing a WordPress speed optimization expert and the explanation of WordPress speed optimization cost when deciding on that scope.

If you would like help, discuss your website’s performance. Bring the symptoms and the pages that matter. Before spending an afternoon optimizing something, let us establish that it is actually the problem.

Frequently asked questions