WordPress plugins we rip out before any performance audit

A client hands you a WordPress site. They want it faster. You open GTmetrix and watch the waterfall paint 312 requests before the hero image starts loading. Twenty-four scripts. Eleven separate CSS files. A "smart" lazy-loader fighting the browser's native one. Before you touch a single image or DNS record, there is real money sitting in the plugins folder.

This is the list we walk through on every WordPress performance engagement, before the actual audit begins. Some of these plugins are well-built. Most are not. All of them earn their removal by a different route.

Triage before tuning

We do not start with metrics. We start with the plugin list, ordered by install date, and we ask a single question per plugin: what would break if we deactivated this right now? About a third of the answers are "nothing visible". Those go first. Another third are doing one specific job badly, and we replace them. The rest stay, sometimes grudgingly.

The first command on every audit is the same one:

wp plugin list --status=active --fields=name,version,update --format=table

You cannot meaningfully measure a site that has fifty plugins running. The signal is buried under the noise. You strip first, you measure second.

Page builders that hold the DOM hostage

Elementor and WPBakery are the two we see most. Both ship a runtime that loads on every page, whether or not the page was built with the builder. Both wrap every paragraph in three nested divs with utility classes the browser cannot cache across pages. WPBakery in particular survives in the database as shortcodes no other tool can read, which is the worst of both worlds: vendor lock and DOM bloat.

Our default move is to migrate to a block theme using core Gutenberg, then delete the builder and its addons (the "Essential Addons", "Ultimate Addons", and "Premium Addons" families are each their own plugin). The HTML output drops by half. The JavaScript payload often falls by 200KB before anything else changes.

If the client genuinely loves a builder, we move them to Breakdance or Bricks, both of which output far less wrapping markup and load their runtime conditionally.

Sliders nobody scrolls

The pattern is consistent across every site we audit: the second slide of a hero slider is seen by a tiny minority of visitors on that page. The third, barely anyone. You are paying the JavaScript and image cost of a carousel for a feature almost nobody uses.

Slider Revolution and LayerSlider come in via theme bundles, often outdated, and they have a long history of security holes. The 2014 local file inclusion in Slider Revolution (tracked in the Patchstack vulnerability database) was still being exploited years after the patch shipped, because bundled-with-theme installs do not auto-update. We pull these out and replace the first slide with a static section. Conversion goes up, not down.

The analytics sediment

WordPress sites accumulate analytics plugins the way old laptops accumulate browser toolbars. Jetpack Stats, WP Statistics, Slimstat Analytics, Matomo for WordPress, Google Site Kit, and a custom GA tag in the header, all running together. Each one writes to the database on every page view. Each one ships its own script.

We pick one. Usually Plausible or a server-side install of Matomo, both of which run without cookies and without bloating wp_options. If the client insists on Google Analytics, we load it through Cloudflare Zaraz or a server-side container, not as another script tag in the head.

WP Statistics in particular has a habit of leaving a multi-million-row visitor table that the host's nightly backup chokes on. That table is often larger than the rest of the database combined.

Caching plugins that fight your host

Hosts like SiteGround, Kinsta, WP Engine, and Hostinger all ship their own server-level caching. Installing W3 Total Cache or WP Super Cache on top creates two cache layers that do not know about each other and invalidate at different times. The symptom is "why is my checkout page showing yesterday's price". The cause is two caches and nobody in charge.

Our rule: if the host caches, use the host's cache. If the host is bare (a cheap VPS, an old shared plan), we install LiteSpeed Cache on LiteSpeed/OpenLiteSpeed, or FlyingPress on anything else. We do not stack them.

SEO suites with the wrong centre of gravity

Yoast SEO works. It also ships an admin UI heavy enough that editors complain, and it stores schema in a way that makes migration painful. On most sites we move to RankMath or SEOPress, both of which output cleaner schema and import Yoast's existing meta during the swap.

The reason this matters for performance is not the front-end (all three are roughly equivalent there). It matters for the editor experience and for what the plugin writes to wp_postmeta. Yoast can balloon postmeta to the point where queries on it become the slowest part of admin page loads. We have rescued sites where deleting orphaned Yoast meta rows cut admin load time in half.

Form plugins that ship a framework

Contact Form 7 is fine, except every addon for it loads on every page, including pages with no form. Add the Conditional Fields addon, the reCAPTCHA addon, the database storage addon, and the email styling addon, and you have shipped four extra script bundles to read the About page.

Our preference is Fluent Forms, which ships one runtime, only loads it on pages with a form, and includes conditional logic, file uploads, and database storage out of the box. Gravity Forms is fine too, particularly for complex multi-step flows, but it is overkill for a contact form.

The leave-alone list

Not every popular plugin gets removed. WooCommerce stays, because the alternative is rebuilding the storefront. WP Mail SMTP stays, because transactional email needs to actually arrive. ACF (Advanced Custom Fields) stays, because removing it removes the content model.

WordFence is a judgement call. On a host with no WAF of its own, it earns its slot. On Cloudflare or behind a managed WAF, it is duplicating work and slowing the admin dashboard. We usually replace it with the host's security module plus Cloudflare's free WAF rules.

The replacement stack we leave behind

After triage, a clean WordPress install for a brochure or content site usually looks like this:

• ACF (custom fields)
• Fluent Forms (forms)
• RankMath (SEO + schema)
• LiteSpeed Cache or the host's cache (caching)
• ShortPixel (image optimisation, run once and disable)
• WP Mail SMTP (transactional email)
• Plausible (analytics)
• Limit Login Attempts Reloaded (brute-force protection)

Eight plugins. We have seen this exact stack take a site from a Lighthouse score in the 30s to the low 90s on mobile, without anyone touching the theme. The biggest gains are not from optimisation. They are from deletion.

For sites that need page-builder functionality, we add Breakdance or stay on Gutenberg with a curated block plugin (GenerateBlocks or Kadence Blocks, not the entire library). For WooCommerce, we add CartFlows or FunnelKit only if the client actually runs funnels, and never speculatively.

What we measure after

Once the plugin list is honest, we run the actual audit. Lighthouse on mobile (not desktop, mobile is where the spend is), Core Web Vitals over the last 28 days from the Chrome UX Report, query monitoring through Query Monitor, and a manual scroll of the slowest five templates. Numbers we did not trust before are now trustworthy, because nothing is fighting nothing.

The replacement stack is not religious. It is just what survived our last fifty audits. If a client has a real use case for Jetpack's CDN, or for Yoast's premium redirect manager, we keep them. We just refuse to keep them by default.

When we rebuilt the marketing site for a Dutch wholesaler last year as a legacy migration off WPBakery onto a block theme, the active plugin count dropped from 47 to 9 and the homepage went from 4.2s to 0.9s on a throttled 4G connection. The biggest unlock was not caching, image optimisation, or a CDN. It was the page builder leaving the building.

Open your own site's plugins page in a new tab. Sort by install date. Ask the question for each one: what breaks if I deactivate this right now? Half your audit work is already done.