The 5 WordPress Plugins That Slow Every Site (Replace These First)

If you only have time to fix three things on a slow WordPress site this week, replace these: Jetpack running at default settings, WPBakery Page Builder, and Slider Revolution. On the baseline test site we use for audits - WordPress 6.7, PHP 8.2, MariaDB 10.6, a 2 vCPU VPS with no object cache - those three alone added roughly 480ms to time-to-first-byte on the home page and pushed query counts from the low thirties into the high seventies. None of them are bad software; they are simply doing far more work than most sites actually need.

The other two on this list - WooCommerce installed on a content site that only sells one or two things, and Yoast SEO Premium with the redirect manager and automatic optimisations turned on - are the ones that quietly eat performance for months before anyone notices, because the symptoms look like generic "WordPress is slow" rather than something a single plugin caused. The good news is that every one of these has a modern replacement that matches the feature set without the bloat, and the swaps are usually a few hours of work each rather than a full rebuild. Below is what we measured, and what to install instead.

How we measured this

All numbers in this article are observational, taken on a single baseline test site as of 28 April 2026. The stack is WordPress 6.7 on PHP 8.2 with OPcache enabled, MariaDB 10.6, no object cache, Cloudflare for DNS only (not full proxy), 1,000 posts, 200 pages, and the Kadence theme. TTFB averages come from k6 running 200 sustained requests; query counts come from Query Monitor on a logged-out front-end request; render and LCP figures come from WebPageTest using the Virginia node and the Cable network profile. Real sites differ - your hosting, theme, and traffic patterns will move these numbers up or down - so treat the figures as directional. The point is the relative shape of the impact, and the fact that the cheaper replacements consistently land closer to the unloaded baseline.

The unloaded baseline (a clean WordPress install with only the Kadence theme active) measured 198ms TTFB and 28 queries on the home page. Every figure below is the delta on top of that.

Jetpack at default settings

Jetpack is the plugin we ask people to look at first, because most sites install it for one feature - usually Stats, sometimes a contact form - and end up running thirty modules they never opened. On the baseline test, activating Jetpack with the default module selection raised TTFB from 210ms to roughly 640ms and pushed home-page query counts from 32 to 71. The biggest individual contributors were Stats firing on every request, Photon rewriting image URLs through a remote CDN handshake, and Related Posts running an additional WP_Query to build its block. The plugin is doing exactly what it advertises; the problem is that the defaults assume you want all of it.

The replacement is not "uninstall Jetpack" - it is "split it apart". Automattic now ships Jetpack Stats as a standalone plugin, and on the same test box that single-purpose plugin averaged 245ms TTFB versus 640ms for the full bundle. Sharing buttons can move into the theme as native HTML and a tiny progressive-enhancement script. Related Posts is better handled by Rank Math's or Yoast's internal-linking suggestions, which run at edit time rather than render time. Contact forms have lighter alternatives - Fluent Forms or a static form-to-email service - that do not pull in the rest of Jetpack with them. If you genuinely use five or more Jetpack modules, keep it; if you use one or two, the standalone version will almost always feel faster.

WPBakery Page Builder

WPBakery (the artist formerly known as Visual Composer) shows up on a huge number of older WordPress sites because so many ThemeForest themes shipped with a bundled licence. The performance cost is twofold: the editor enqueues a roughly 480KB gzipped frontend bundle on every page even when no shortcodes are present, and posts authored inside it are stored as nested [vc_row][vc_column][vc_column_text] shortcode walls that the renderer has to parse with regex on every request. On the baseline test, switching a Gutenberg-built page over to a WPBakery layout with the same visible content added 180ms to TTFB and pushed largest-contentful-paint from 1.8 seconds to 3.4 seconds on the throttled mobile profile, mostly because the builder's stylesheet is render-blocking.

For sites that genuinely need a visual builder, Bricks is the modern replacement we keep recommending: it outputs clean HTML, scopes its CSS, and on the same test box added only 25 to 40ms of TTFB versus the unloaded baseline. For content-led sites, the better answer is to migrate to native Gutenberg with a properly configured theme.json and a small set of custom blocks. Migration is the painful part - shortcode walls do not convert themselves - but you only do it once, and the result is content that survives any future theme change without bringing the builder along.

Slider Revolution

Slider Revolution earns its place on this list less because of what it does on slider pages and more because of what it does on every other page. By default it enqueues jQuery and six of its own scripts plus a custom stylesheet site-wide, even on URLs that contain no slider. On the baseline test, simply activating the plugin and never placing a slider added 120ms of TTFB and 210KB of JavaScript to every page on the site. When a slider is present above the fold, the cumulative-layout-shift score on the home page moved from 0.04 (good) to 0.18 (poor) because the slider initialises after the surrounding layout has already painted.

You almost never need a "slider plugin" in 2026. A CSS-only slider built around scroll-snap-type handles ninety percent of marketing-site carousels in roughly forty lines of CSS and zero JavaScript, with first-class touch support handled by the browser. If you need autoplay or programmatic controls, a 3KB vanilla library such as Splide or Glide.js does the job without the framework tax. The visual result is identical for visitors; the network panel is dramatically quieter.

WooCommerce running on a non-store site

This one is unfair to WooCommerce, because WooCommerce is excellent at the job it was built for - running a real store. The problem is what it does when activated on a content site that sells one or two things and never deactivates the rest of the machinery. Out of the box, WooCommerce loads woocommerce.js, cart-fragments.js, and roughly fifteen cart and session queries on every front-end request, including blog posts, the homepage, and category archives that have nothing to do with commerce. On the baseline test, activating Woo with sample data and no other changes added 95ms of TTFB across all URLs and 18 extra queries on the home page, even though the home page rendered no shop content.

The replacement depends on how much you actually sell. If commerce is a meaningful share of revenue, keep WooCommerce but scope it: dequeue Woo's scripts and styles on non-shop templates with wp_dequeue_script and wp_dequeue_style, disable the cart-fragments AJAX call on pages without an add-to-cart button, and exclude the Woo session cookie on cached URLs. Done well, this brings the per-request overhead on non-store templates back to within a few milliseconds of the unloaded baseline. If you sell one or two products and only sell them occasionally, the more honest answer is to remove Woo entirely and use a Stripe Payment Link, a SureCart embed, or a Lemon Squeezy checkout. Carrying a full e-commerce platform for one digital download is the most common WooCommerce mistake we see, and it shows up in TTFB on every page of the site.

Yoast SEO Premium with the redirect manager and automatic optimisation

Yoast itself is fine. Yoast Premium with the redirect manager turned on and "automatic" optimisation features (internal linking suggestions running on the front end, OpenGraph image regeneration, automatic redirects on slug changes) all enabled is where the cost shows up. The redirect manager hooks into template_redirect and performs a regex match against every stored redirect on every front-end request - which is fine at ten redirects, noticeable at a hundred, and painful at a thousand. On the baseline test with 50 stored redirects, Yoast Premium added 14 queries and between 60 and 90ms of TTFB on individual post pages compared with the same content under Yoast free.

The replacement most of our audit clients land on is Rank Math for the SEO layer (the free version covers what Yoast Premium does for the majority of sites, and the Pro tier is cheaper), combined with redirects handled either at the server level in nginx or .htaccess, or in the standalone Redirection plugin which stores redirects in an indexed database table and runs a single lookup rather than a regex sweep. On the same test content, Rank Math measured 12 to 18ms of TTFB lower than Yoast Premium across post and archive pages, with no loss of SEO functionality that mattered.

The thirty-minute audit you can run today

You do not need a tool subscription to find out which of these five is hurting your site most. Install Query Monitor on a staging copy, load your home page logged out, and look at two numbers: total queries and total page generation time. Then deactivate one suspect plugin at a time and reload. Anything that drops query count by more than ten or page-generation time by more than fifty milliseconds is a candidate for replacement. Cross-check the front-end with WebPageTest on the Cable profile and watch what happens to TTFB and LCP. In thirty minutes you will know which of the five is your worst offender, and from there the replacement is a scoped piece of work rather than a guessing game.

A few things to remember while you do this. Always test logged out and in an incognito window, because the admin bar and logged-in cookies disable a lot of caching and inflate the numbers. Run each measurement at least three times and take the median, because cold-cache and warm-cache requests look very different on shared hosting. If your site sits behind a full-page cache (LiteSpeed, WP Rocket, a Cloudflare APO setup, or your host's built-in cache), purge the cache between deactivations or you will be measuring the cache, not the plugin. And if a deactivation breaks the front end - WPBakery shortcodes leaking through as raw text, for instance - that is itself useful information about how deeply the plugin has crawled into your content, and it tells you the migration is going to be a project rather than a switch flip.

The pattern we see across hundreds of audits is that one plugin is usually responsible for more than half of the avoidable performance cost, and it is almost always one of the five above. Ranking the worst offender, replacing it cleanly, and measuring the delta is a far better use of a week than installing another caching plugin on top of the problem. Caching hides slow plugins from logged-out visitors; it does nothing for the logged-in editor experience, the admin dashboard, the checkout flow, or the first uncached request after a content update. Fixing the underlying plugin choice is the only change that improves all of those at once.

If you would rather have someone else do the audit and hand you a prioritised list with measured before-and-after numbers, that is exactly the engagement we run at WitsCode. We will look at your live site, identify the worst offender of the five (or whichever sixth thing is hiding behind them), and replace it within a week with measurable TTFB and Core Web Vitals deltas in the report. The first audit is free; the swap is fixed-fee. Most clients see their largest gain from a single plugin swap, which is the whole point of starting here.