Performance
Wajih ShaikhUpdated 27 October 2026WordPress performance audit: my practical process
A useful WordPress performance audit explains why a page is slow, which problem matters most and what to fix first. This is the sequence I use to separate hosting, theme, plugin, media and third-party costs.
What does a WordPress performance audit include? It should review representative templates, Core Web Vitals, server response, images, fonts, scripts, plugin output, caching and third-party tools. The result should be a prioritized plan, not a screenshot of one score.
Start with the page users actually visit
I test representative templates rather than only the homepage: a service page, product page, archive and any page with forms or embeds. Different templates often have different bottlenecks.
What a WordPress performance audit should deliver
Before paying for an audit, ask what you will receive. A useful report connects each finding to a real page, explains the likely cause, ranks the work by impact and notes any risk or dependency. It should also separate improvements the developer can control from limits imposed by hosting or third-party software.
- Test scope: the URLs, templates, devices and conditions reviewed.
- Evidence: field data where available, repeatable lab tests and the affected requests or elements.
- Priorities: critical fixes, useful improvements and low-value work that can wait.
- Implementation notes: the likely owner, dependencies and checks required after each change.
A performance audit is worth requesting when slow pages affect leads or sales, Core Web Vitals are failing, a redesign has increased page weight, or the team is adding optimization plugins without knowing the underlying cause. If you need the audit and implementation handled together, see my WordPress speed optimization service or send me the website URL.
Separate field data from lab data
PageSpeed Insights field data describes real Chrome users when enough data exists. Lighthouse is a controlled diagnostic. I use both, but I do not treat a single lab run as proof of the real user experience.
| Metric | What it covers | Good target |
|---|---|---|
| LCP | Loading the largest visible content element | 2.5 seconds or less |
| INP | Responsiveness to user interactions | 200 milliseconds or less |
| CLS | Unexpected layout movement | 0.1 or less |
Assess these at the 75th percentile of real visits, with mobile and desktop considered separately. Google’s Web Vitals guidance explains the thresholds. If a site lacks enough field data, report that limitation rather than presenting lab scores as field results.
Find the largest cost before changing plugins
I review the LCP element, request waterfall, image dimensions, font files, JavaScript execution and layout shifts. The highest-impact issue might be a hero image, a third-party widget or server response time—not the cache plugin.
Change one layer at a time
Image delivery, caching, CSS, JavaScript, fonts and hosting are separate layers. Small controlled changes make it possible to confirm what helped and avoid breaking checkout, forms or tracking.
Verify the result
I retest the same templates and interactions, check responsive layouts, clear relevant caches and watch for delayed layout shifts. Performance work is complete only when the site still behaves correctly.
- Keep a comparison recordRecord the URL, device setup, test conditions and changes made. Compare like with like.
- Try the important interactionsOpen the mobile menu, expand content, submit a test form and run a test checkout where applicable.
- Explain what remainsDocument third-party costs, hosting limits and any feature trade-offs. Don't promise a score that depends on conditions outside the build.
For examples of the types of business websites I work on, explore the portfolio. Those showcases are not before-and-after performance benchmarks.
Start with evidence, address the largest bottleneck, then check both the metrics and the business-critical interactions. A faster page that breaks the inquiry form is not an improvement.