My Practical WordPress Performance Audit Before Adding Another Optimization Plugin

Installing a performance plugin can be useful. Installing one before understanding the page can also hide the actual problem.

My WordPress performance audits begin with evidence: what the browser requests, which resource becomes the Largest Contentful Paint element, what blocks rendering, what executes on the main thread, and which dependencies are present only because a plugin or old feature still exists.

The objective is not merely to make a test score turn green. It is to reduce unnecessary work while preserving the functions the site genuinely needs.

Establish a reproducible baseline

Before changing production behavior, I record the tested URL, device profile, date, major metrics, and active cache state. Lab tools can fluctuate, so a single run should not be treated as an absolute truth.

I use PageSpeed Insights and the Chrome DevTools Performance and Network panels to connect high-level recommendations to actual requests and execution. When available, field data and server monitoring add another perspective.

Identify the LCP element

The Largest Contentful Paint element often determines where to begin.

If it is an image, I check whether the browser discovered it immediately, selected an appropriate responsive source, received a modern encoded response, and downloaded more pixels than the layout displays. If it is text, I inspect font loading, render-blocking styles, and whether a script or animation delays visibility.

An image URL ending in .jpg does not prove that the server delivered JPEG. Content negotiation and optimization layers may return WebP or AVIF while preserving the original URL. The response headers and transferred bytes provide the answer.

Audit JavaScript by responsibility

“Reduce unused JavaScript” is a starting point, not a fix.

I map each significant script to a visible responsibility:

Does it power navigation, forms, analytics, advertising, a carousel, or an editor feature?
Is that feature present on the current template?
Can the browser handle it natively?
Can it load only where the feature appears?
Is an old plugin still enqueueing assets after its final use was removed?

On my portfolio, retiring unused Divi carousel assets, disabling an unnecessary Google Sign-In integration, and limiting advertising to the editorial blog removed work rather than trying to minify work the page did not need.

Check responsive images in context

WordPress produces responsive image candidates, but the browser also needs accurate layout information through the sizes attribute.

I compare the selected resource width with the image’s rendered dimensions at each breakpoint. I also check compression, intrinsic dimensions, loading priority, and whether lazy loading is appropriate for the image’s position.

Above-the-fold candidates require different treatment from gallery images several screens below the initial viewport.

Inspect CSS and visual effects

Render-blocking CSS can matter, but aggressively splitting a small stylesheet is not automatically an improvement. I first remove obsolete rules and dependencies, then evaluate whether critical styles, font declarations, or third-party CSS delay the first render.

Visual effects need special attention. An element can exist in the DOM while still appearing late because an ancestor begins at reduced opacity or under a transform. That affected the accessibility audit of my contact form: Lighthouse evaluated otherwise compliant colors through a translucent animated container.

The final fix required both correcting the animation boundary and invalidating an older stylesheet cached under the same URL.

Treat caching as a system

WordPress caching can exist at several levels:

Browser cache
Page cache
CDN or host cache
Object cache
Asset minification and combination cache
Image optimization and content negotiation

Clearing one layer does not prove that every visitor receives the new file. For important asset changes I use explicit, versioned filenames when query-string versions may be removed by another optimization layer.

Measure third-party cost separately

Forms, analytics, advertising, maps, video embeds, and chat tools often cost more than the custom theme itself.

The correct question is not whether every third party is bad. It is whether each one belongs on every template. Salvadoresc.com retains Gravity Forms where visitors need it and keeps AdSense on blog contexts rather than loading advertising resources on the portfolio homepage and case studies.

Verify accessibility and interaction after optimization

Performance changes can create functional regressions.

After modifying lazy loading, script execution, client navigation, or CSS, I verify keyboard navigation, form submission, focus visibility, reduced motion, browser history, direct URLs, mobile layout, and server-rendered fallbacks.

Fast navigation is not valuable if the contact form disappears after a client-side transition. That particular interaction required a small integration between Gravity Forms and the WordPress Interactivity API router.

A practical order of operations

Record a repeatable baseline.
Identify LCP and critical rendering dependencies.
Remove assets and plugins with no current responsibility.
Correct responsive images and loading priority.
Reduce main-thread JavaScript and template-wide third parties.
Review CSS, fonts, and visibility animations.
Validate every relevant cache layer.
Retest accessibility, forms, navigation, and responsive behavior.
Compare results across several runs and preserve evidence.

This process helped my portfolio reach recorded 100 scores across Performance, Accessibility, Best Practices, and SEO on mobile and desktop. More importantly, it produced a site whose speed comes from understandable architectural decisions rather than an opaque stack of optimizations.

If your WordPress site needs evidence-led performance work or production troubleshooting, contact me through Salvadoresc.com.