# Three of the Four Optimization Switches Break Elementor and Divi in 2026, and the Fourth Is Already Switched Off for You

> Elementor ships 342 minified asset files and its own CSS folder. Three of the four optimization switches have a documented builder conflict. The fourth does not.

- Published: 2026-10-04
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: Elementor, Page Builders, Caching, Comparison, Performance, platform:wordpress
- Canonical: https://xspeedcache.com/blog/best-caching-plugin-elementor-page-builders/

---

Updated October 2026

Elementor reported **10,000,000+ active installs** through the wordpress.org Plugin API on 4 October 2026, against **7,000,000+** for LiteSpeed Cache, the largest caching plugin on the same endpoint on the same day. Divi answers `Plugin not found` to that API, because it has never been in the directory at all. The comparison people expect here is which caching plugin is fastest on a builder site. The more useful comparison is which of the four optimization switches each plugin is allowed to leave switched on, because on a builder site three of the four carry a conflict the vendors have already written down. This article maps those four switches against what Elementor and Divi actually ship, counts the protection each plugin has in its source code, and gives you a census to run before you buy anything.

## Quick Summary: Which Plugin for Which Builder Site

Work down this table until a row describes your site. The criteria come first on purpose, because the right answer here depends far more on your server and your budget than on any plugin's feature grid.

| Your situation | Start here | Why this and not the other thing |
|:---|:---|:---|
| Your host runs LiteSpeed | [LiteSpeed Cache](https://wordpress.org/plugins/litespeed-cache/), free | It ships four dedicated page-builder integration files and turns every feature off inside a builder editor |
| Not on LiteSpeed, budget for one licence | WP Rocket, $59.95/yr for one site | Its documentation names the exact Elementor and Divi exclusions, and the delay-JavaScript exclusions are checkboxes |
| Free, any host, and you want the widest editor protection | [Autoptimize](https://wordpress.org/plugins/autoptimize/), free, paired with any page cache | Thirteen query strings stop it optimizing, described in its own code as pagebuilders plus two generic parameters |
| PageSpeed still reports unused JavaScript after all of the above | [Perfmatters](https://perfmatters.io/pricing/) at $29.95/yr, or [Asset CleanUp](https://wordpress.org/plugins/wp-asset-clean-up/) free | Only a per-URL script manager unloads a plugin that the builder page never uses |
| You want the editor guard, safe-minify fallback and page cache in one free plugin | xSpeed Cache, which we build at WPDeveloper | Fourteen builder editor arguments across nine builders, and the fallback is on by default |
| Several builder sites under one roof | xSpeed Hub, also ours, or WP Rocket's multisite licence | A bisect done once on staging has to become the configuration everywhere |

Every price above was confirmed against the vendor's own pricing page on 4 October 2026.

## The Four Switches, and Why Builders Are a Special Case

What people call minification is four separate operations, and they fail in four different ways. Our fix guide on [a theme that looks unstyled after minification](https://xspeedcache.com/blog/layout-breaks-after-minification/) sets out the taxonomy: minify changes the bytes inside one file, combine changes which files exist, async CSS changes when a sheet applies, and delay JavaScript changes when a script runs.

A page builder is a hard case for three of those four, for one structural reason. Elementor 4.3.3 writes a separate stylesheet per page into `wp-content/uploads/elementor/css/`, regenerates it whenever the page is saved, and loads it by a filename that changes. Divi does the same thing into `/et-cache/`, according to Perfmatters' own exclusion guidance. So a builder page carries files that an optimizer cannot treat as static, and every operation that assumes a stable filename has a problem.

The raw payload is large before any of that starts. Elementor 4.3.3, unzipped from the wordpress.org download endpoint on 4 October 2026, ships **187 minified stylesheets and 155 minified scripts** in its `assets` directory, 66 MB in all. The counting rule is `find assets/css -name "*.min.css" | wc -l` and the same for `assets/js`, so you can reproduce both numbers in a terminal. Only a fraction of them load on any one page, which is the point of the per-page CSS folder, and it is also why that folder matters so much to everything below.

![Four rows, one per optimization operation. Minify changes the bytes inside one file and carries a green tick for no documented builder conflict, because two vendors exclude builder CSS by default. Combine, async or defer CSS, and delay JavaScript each carry a red cross marked Conflict, cited to Breeze and Perfmatters, to WP Rocket's Elementor and Divi articles, and to the exclusion lists WP Rocket and Perfmatters both ship.](https://xspeedcache.com/images/blog/b17-four-switches-builder-conflict.webp)

| Operation | What it changes | Safe to leave on for a builder | Who says otherwise |
|:---|:---|:---:|:---|
| Minify | The bytes inside one file | ✅ | Nobody. Two vendors exclude builder CSS by default |
| Combine | Which files exist, and cascade order | ❌ | Breeze and Perfmatters both name it |
| Async or defer CSS | When a sheet applies | ❌ | WP Rocket names Elementor and Divi separately |
| Delay JavaScript | When a script runs | ❌ | WP Rocket's own Elementor and Divi exclusion lists |

The tick is the good outcome here and there is exactly one of them, which is the whole finding rather than a scoreboard. Read on for what each row is based on.

## What the Vendors Themselves Exclude, in Their Own Words

The useful evidence for an article like this is not a benchmark. It is what each vendor has already written down about the builder, because that is a limitation the vendor chose to publish about its own product.

**Minify is the switch nobody needs to warn you about, and the reason is that two vendors turned it off for you.** WP Rocket's documentation on [using Elementor with WP Rocket](https://docs.wp-rocket.me/article/1745-using-elementor-with-wp-rocket) states that "Elementor post CSS files are automatically excluded from Minify CSS files to avoid a situation where the cache would be cleared too frequently." WP Fastest Cache does the same thing in code rather than in a setting: `inc/css-utilities.php` in the current trunk, fetched from the wordpress.org download endpoint on 4 October 2026, matches `/elementor/css/post-\d+\.css` and returns an exclusion, with the comment "to avoid increasing the size of minified sources." Two independent vendors reached the same decision about the same folder.

**Combine has one vendor naming the builder and one shipped bug of our own.** Breeze 2.6.0, released 29 September 2026, ships a compatibility table whose Elementor entry reads, verbatim, "Elementor plugin may conflict with JS Delay and Combine CSS/JS options." That list holds ten entries in total and only three of them describe a content conflict rather than a second caching plugin, so Elementor is one of three things Breeze warns about by name. The second piece of evidence is ours: issue #281 in our own shipped source records Combine JavaScript merging around twenty-one Beaver Builder handles into one dependency-free footer bundle, so `fl-builder.min.js` ran before its dependencies existed and the editor never rendered. Perfmatters makes the wider case rather than the builder-specific one, in its [Remove Unused CSS documentation](https://perfmatters.io/docs/remove-unused-css/): "If you're using Autoptimize, LiteSpeed Cache, WP Rocket, etc., turn off CSS combine," followed by the reason, "Combining CSS is a deprecated optimization technique since HTTP/2 (now HTTP/3) anyways."

**Async CSS is named by WP Rocket twice, once per builder.** Its [Elementor CSS exclusion article](https://docs.wp-rocket.me/article/1499-exclude-uploaded-elementor-css-from-optimize-css-delivery) reports that Load CSS Asynchronously "may conflict with files created dynamically by Elementor in the uploads/elementor/css folder," and that excluding them by hand does not hold "since the filename might change and/or new CSS files might be created." The published remedy is a helper plugin. Its [Divi article](https://docs.wp-rocket.me/article/657-using-divi-with-wp-rocket) is blunter: "The Divi Blog module is not compatible with the Load CSS Asynchronously feature." Google's own web.dev guide to [deferring non-critical CSS](https://web.dev/articles/defer-non-critical-css) warns in general terms that the technique "may lead to bugs if not implemented properly."

**Delay JavaScript is the one with the longest paper trail.** WP Rocket ships one-click exclusion checkboxes for Elementor and for Divi inside the feature itself. Perfmatters publishes a [delay JavaScript exclusion list](https://perfmatters.io/docs/delay-javascript/) that carries fourteen entries under Elementor, four more under Elementor search, three under its table-of-contents widget, four under Divi and eleven under Divi with animations. The same page states the principle plainly: "a site using a heavy page builder like Elementor will most likely need more exclusions than a lightweight site using GeneratePress."

## The Builder-Editor Guard Census

Here is a method for judging builder safety from evidence rather than from a feature grid, and it costs nothing but a download. Builders do not edit inside `wp-admin`. Beaver Builder, Elementor, Divi, Brizy and Oxygen all render their editor over an ordinary front-end URL, flagged by a query argument. An optimizer that cannot see that argument treats the editor like a public page and optimizes it, which is how an editor stops loading.

So the question becomes measurable: how many builder editor arguments does each plugin's shipped PHP actually match?

**Step 1.** Download the current trunk of each plugin from `https://downloads.wordpress.org/plugin/<slug>.zip` and unzip it.

**Step 2.** Count, for nine arguments, how many the plugin matches as a quoted literal string in any PHP file:

```
grep -rlE "['\"](elementor-preview|et_fb|et_bfb|fl_builder|brizy-edit|ct_builder|vcv-editable|siteorigin_panels_live_editor|vc_action)['\"]" --include=*.php <plugin-dir>
```

**Step 3.** Read what the match does. A plugin can match an argument to purge a cache rather than to stop optimizing, and those are different promises.

We ran this against thirteen caching and optimization plugins on 4 October 2026. The counting rule is the one above and nothing else, which matters for how you read the bottom of the table.

![A bar chart of thirteen caching and optimization plugins, scored out of nine page-builder editor query arguments matched in their shipped PHP. xSpeed Cache scores nine, Autoptimize and Asset CleanUp six, WP-Optimize five, SiteGround Speed Optimizer and Hummingbird four, LiteSpeed Cache one in amber, and WP Fastest Cache, W3 Total Cache, Breeze, NitroPack, WP Super Cache and Cache Enabler zero with no bar drawn. An amber callout explains that LiteSpeed detects Elementor by a different argument and is arguably the most thorough plugin in the chart.](https://xspeedcache.com/images/blog/b17-builder-editor-guard-census.webp)

| Plugin | Arguments matched (of 9) | What the guard does |
|:---|---:|:---|
| xSpeed Cache (ours) | 9 | Fourteen arguments across nine builders in one predicate, filterable |
| Autoptimize | 6 | Thirteen query strings stop optimization outright, most of them builder editors |
| Asset CleanUp | 6 | Editor detection across the plugin's own admin paths |
| WP-Optimize | 5 | A dedicated page-builder compatibility class |
| SiteGround Speed Optimizer | 4 | Exclusion list inside the minifier |
| Hummingbird | 4 | A builders integration class that deactivates minify |
| LiteSpeed Cache | 1 | See the caveat below. The raw count badly understates it |
| WP Fastest Cache | 0 | Purges on Elementor maintenance-mode change; excludes builder CSS from minify |
| W3 Total Cache | 0 | Flushes Elementor's own file manager on cache flush |
| Breeze | 0 | Warns about Elementor in its one-click optimizer instead |
| NitroPack | 0 | Syncs the Beaver Builder cache on purge |
| WP Super Cache | 0 | A page cache only, so none of the four switches apply |
| Cache Enabler | 0 | A page cache only, so none of the four switches apply |

### What This Census Cannot Tell You

Stating the limits matters more than the number, because this one is easy to over-read and the bottom of the table is where it misleads.

- 🔍 **It measures one spelling of one mechanism.** LiteSpeed Cache scores 1 and is arguably the most thorough plugin in the table. It ships `thirdparty/elementor.cls.php`, `thirdparty/divi-theme-builder.cls.php`, `thirdparty/beaver-builder.cls.php` and `thirdparty/avada.cls.php`, four of the thirty-one PHP files in [its `thirdparty` directory](https://plugins.svn.wordpress.org/litespeed-cache/trunk/thirdparty/), and each of them fires `litespeed_disable_all`, which defines `LITESPEED_DISABLE_ALL` and switches the whole plugin off for that request. It detects Elementor by the `action=elementor` request field rather than by `elementor-preview`, which is why the grep misses it.
- 📦 **A zero can mean two opposite things.** WP Super Cache and Cache Enabler ship none of the four switches, so there is nothing for a guard to protect. WP Fastest Cache and W3 Total Cache do ship them.
- 🕐 **It reads one release.** Breeze added its compatibility warnings in 2.6.0 on 29 September 2026, five days before this count.
- 🧩 **Matching an argument is not the same as handling it well.** Step 3 exists for that reason, and the right-hand column above is the result of doing it.

## The Builder Share Census: What No Script Manager Can Unload

The standard advice for a heavy WordPress site is a per-URL script manager, and [our own comparison of Perfmatters against a caching plugin](https://xspeedcache.com/blog/perfmatters-vs-caching-plugin/) sets out the census that sizes the opportunity: list every plugin asset on a URL, mark the ones the page does not use, and count the noes. That count is your unload budget.

On a builder site the census returns a surprise, and it runs against the way builders are usually described. We swept eighteen public WordPress-industry sites on 4 October 2026, looking for `/wp-content/plugins/<slug>/<file>.css|js` in the homepage HTML. Two were detectably Elementor-built, and one of those is ours.

| Site | Plugin asset files | Plugin folders | Of which the builder's own |
|:---|---:|---:|---:|
| elementor.com | 25 | 5 | 19 |
| wpdeveloper.com (ours) | 73 | 20 | 24 |
| wpastra.com | 111 | 14 | 0 |
| wptavern.com | 45 | 4 | 0 |
| wpbeginner.com | 25 | 11 | 0 |
| gravityforms.com | 23 | 7 | 0 |
| generatepress.com | 13 | 8 | 0 |
| wp-rocket.me | 7 | 5 | 0 |
| perfmatters.io | 4 | 3 | 0 |
| kinsta.com | 2 | 1 | 0 |

![A bar chart of ten of the eighteen sites swept, showing distinct plugin CSS and JavaScript files on one logged-out homepage. Teal marks the page builder's own files and grey marks everything else. elementor.com has 25 files of which 19 are Elementor's own, wpdeveloper.com has 73 of which 24 are, and the other eight sites show no builder and range from wpastra.com at 111 files down to kinsta.com at 2.](https://xspeedcache.com/images/blog/b17-builder-share-asset-census.webp)

The heaviest page in the sweep is not a builder site at all. That is the first thing to say, because it is the claim this article would most like to make and the data does not support it. The second is the one that does hold: on elementor.com, 19 of 25 plugin asset files are the builder's own, and the homepage additionally loads **19 separate generated stylesheets** from `/uploads/elementor/css/`. On our own site, 24 of 73 are Elementor's, with 5 generated stylesheets.

That folder is enough of a special case that optimizers write rules for it rather than general rules. xSpeed Cache, which we build at WPDeveloper, strips the `?ver=` query string from asset URLs but deliberately leaves it on generated files under `wp-content/uploads`, so that a page-builder edit still reaches a returning visitor instead of a stale copy. WP Rocket and WP Fastest Cache both exclude the same folder from minification, by documentation and by regular expression respectively.

Those files are the problem, and a script manager cannot touch them. Unloading a plugin per URL works when the plugin is unused on that URL. Elementor's frontend runtime is used on every Elementor page by definition, so the unload budget against the builder itself is zero. Whatever is left to win has to come from the four switches, and three of the four are the ones their vendors ask you to restrict. That is the trap, and it is specific to this audience.

### What This Census Cannot Tell You

Eighteen sites is a spread, not a sample, and two builder sites is not a population. These are WordPress-industry sites chosen because they are public and relevant, one of them is ours, the count is of files rather than bytes or execution time, and it reads a logged-out homepage at one moment. Run it on your own three most important URLs and trust that instead. For context on where the bytes actually sit, images rather than scripts carry most of the weight on a typical WordPress page, and no switch in this article touches them.

## Two Optimizers, One Page: Divi Already Owns Four of the Seven Jobs

Elementor and Divi are not passive payloads waiting to be optimized. Both ship their own optimizer, and that is where most builder-site breakage actually starts.

Divi's own documentation, published by Elegant Themes, describes a Performance tab holding a Dynamic PHP Framework, Dynamic CSS, Smart Styles, JavaScript Optimization, Critical CSS and a set of speed boosters covering Google Fonts caching, emoji removal, Gutenberg stylesheet deferral and dynamic icons. The vendor reports its own test site falling "from 860kb all the way down to a mere 54kb" of CSS, which is a vendor measurement on a vendor page and should be read as one. Elementor's side is smaller but real: optimized front-end asset loading, improved media file loading and element caching, per its directory listing.

So a Divi site with a caching plugin is running two critical-CSS implementations, two deferral systems and two sets of font handling. WP Rocket's answer is explicit, and it is the cleanest statement of the problem anyone has published: "it's recommended to use WP Rocket's features only to avoid having duplicated optimizations running on a site." Its Divi article then lists **seven Divi options to switch off**, and its Elementor article lists **three Elementor features** to deactivate, including Element Cache, on the grounds that it "may cause widgets to show incorrect content."

![Seven jobs listed against two columns, Divi and Elementor, with a filled dot where the builder ships that feature itself. Divi ships critical CSS, dynamic CSS, Google Fonts handling and script deferral. Elementor ships dynamic CSS, element caching and image lazy loading. Only the last row, full-page cache, has no dot in either column, and it is highlighted as the one job with a single owner. The right-hand column carries WP Rocket's published advice for each row.](https://xspeedcache.com/images/blog/b17-two-optimizers-one-page.webp)

| Job | Divi ships | Elementor ships | WP Rocket's advice |
|:---|:---:|:---:|:---|
| Critical CSS | ✅ | ❌ | Turn Divi's off |
| Dynamic or per-page CSS | ✅ | ✅ | Leave the builder's on, exclude it from async CSS |
| Google Fonts handling | ✅ | ❌ | Turn Divi's off |
| Script deferral | ✅ | ❌ | Turn Divi's off |
| Element or fragment cache | ❌ | ✅ | Turn Elementor's off |
| Image lazy loading | ❌ | ✅ | Turn Elementor's off |
| Full-page cache | ❌ | ❌ | This is the caching plugin's job alone |

A mark in that table records which product ships a feature, not which one does it better, so the column totals are not a score. The last row is the one worth sitting with. Neither builder caches a page. Everything above it is contested territory, and the bottom row is the only job with exactly one owner.

## Running This Across Twenty-Five Builder Sites

Bisecting a single site by hand is reasonable. Doing it twenty-five times, after every builder update, is not.

Our own plugin keeps each of the four operations behind its own toggle for exactly this reason, and the editor guard counted above is in the free tier rather than behind the paywall. Safe-minify skips files that are already minified and falls back to the original when the output looks wrong, which is the behaviour that matters when a builder update changes what the minifier is handed. The [minification documentation](https://xspeedcache.com/docs/minify/) covers the loading-behaviour settings, and [Free vs Pro](https://xspeedcache.com/free-vs-pro/) shows where the line falls.

Run the free scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/)

### Where we lose on this, specifically

- 🐛 **We shipped this exact bug.** The Beaver Builder failure cited above as evidence for the combine row is ours, logged as issue #281 in our own source. The guard counted in the census exists because we broke the editor first, and the comment above the predicate says so in as many words.
- 💰 **The two features a builder page most needs are Pro for us.** [Remove Unused CSS](https://xspeedcache.com/docs/unused-css/) and Critical CSS both sit behind the paid tier, while Autoptimize's CSS handling is free and LiteSpeed's critical CSS runs through QUIC.cloud's free quota. On a single Elementor site with no budget, that is a real reason to pick one of them over us.
- 📉 **We are the smallest product in this article by three orders of magnitude.** We reported 10,000+ active installs on 4 October 2026 against LiteSpeed Cache's 7,000,000+ and Elementor's own 10,000,000+, and our own marketing site is the heavier of the two builder sites in our own sweep, at 73 plugin asset files from 20 plugin folders.
- 🧰 **We do not ship a per-URL script manager.** Perfmatters and Asset CleanUp do, and on a builder site carrying a lot of non-builder plugins that is the capability that pays.

For agencies, [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) pushes one preset across a fleet, so a bisect done once on staging becomes the configuration everywhere, and the [80-capability comparison](https://xspeedcache.com/comparison/) carries the per-tier marks rather than a yes or no. Hosting is the other half of this, and it is ours too: xCloud is a Startise company, as is WPDeveloper, and a builder page that misses the cache still has to run the builder's PHP on whatever server you gave it.

## Common Mistakes People Make on Builder Sites

- ⚠️ **Turning every switch on at once, then turning every switch off.** The four operations fail differently, so the breakage tells you which one to reach for. Our four-pass bisect runs them in blast-radius order, switching the riskiest operation on last and off first.
- 🔁 **Leaving both optimizers on.** This is the most expensive mistake on a Divi site, and WP Rocket's seven-item disable list is the shortest published fix for it.
- 🧾 **Excluding a file by name when the name changes.** Builder CSS filenames move on every save. Exclude the folder, as [WP Rocket's own helper plugin does](https://docs.wp-rocket.me/article/1499-exclude-uploaded-elementor-css-from-optimize-css-delivery).
- 🧪 **Testing while logged in.** A combined file your browser still holds hides the failure from you and from nobody else.
- 💸 **Buying a script manager first.** On a builder page the builder's own assets are all in use, so measure the unload budget before you spend.
- 🧯 **Blaming the caching plugin for a memory limit.** WP Rocket's own troubleshooting reports that an editor which never finishes loading "is usually not a direct conflict with WP Rocket, but is due to a lack of resources," and Elementor asks for 512 MB of PHP memory in its own requirements.

## Frequently Asked Questions

### My Elementor editor stopped loading right after I enabled minification. What happened?

Your optimizer is treating the editor as a public page. Elementor renders its editor over a front-end URL flagged by `elementor-preview`, and a plugin that does not match that argument will combine and defer the editor's own scripts. Check whether your plugin appears in the census table above, and if it scores zero, exclude the argument by hand.

### I turned on Load CSS Asynchronously and one Divi section lost its styling. Is that a bug?

It is documented behaviour. WP Rocket reports that the Divi Blog module is not compatible with that feature, and recommends Remove Unused CSS instead. Async CSS changes when a sheet applies, so it produces narrow single-component failures rather than a whole unstyled page.

### My site broke only after I cleared the cache, not when I changed a setting. Why?

Builder stylesheets are regenerated on save and on purge, and pages cached beforehand point at the old filename. This is the same pattern as [a purge that appears to do nothing](https://xspeedcache.com/blog/wordpress-cache-plugin-conflicts/), and it is why builder CSS folders get excluded rather than individual files.

### Which caching plugin is actually best for Elementor?

On LiteSpeed hosting, LiteSpeed Cache, because its builder integrations disable the whole plugin inside an editor and it costs nothing. Off LiteSpeed with a budget, WP Rocket, because its documentation is the product here and the delay-JavaScript exclusions are checkboxes rather than regular expressions. Free and off LiteSpeed, Autoptimize beside any page cache. Ours is a fourth option, and the honest reason to pick it is the free editor guard plus a page cache in one plugin.

### Do I need Perfmatters as well on an Elementor site?

Probably less than you would on a plugin-heavy site without a builder. A script manager unloads assets the page does not use, and the builder's own runtime is used on every builder page. Run the census on your three most important URLs first. If the unused count is five or more, [Asset CleanUp](https://wordpress.org/plugins/wp-asset-clean-up/) will tell you for free whether the paid version is worth it.

### I enabled Delay JavaScript and the Elementor sticky header stopped sticking. What do I exclude?

Start with the vendor's own list rather than guessing. Perfmatters publishes fourteen Elementor exclusions and WP Rocket ships one-click checkboxes for the same scripts. Our write-up on [a menu that broke under delayed JavaScript](https://xspeedcache.com/blog/delay-javascript-broke-menu/) explains why the script runs after the event it was waiting for.

### Should I turn off Divi's own performance options?

If you run a caching plugin alongside it, yes for the overlapping ones. WP Rocket names seven. The test is whether two products are doing the same job on the same page, because the second one usually works on output the first has already changed.

### Is combining CSS still worth the risk in 2026?

Less than it was. Perfmatters calls it "a deprecated optimization technique since HTTP/2 (now HTTP/3)" and asks you to turn it off in whichever plugin is doing it. On a builder site it is also the operation with the most documented failures, so it is the first thing to leave off and the last thing to try.

### My PageSpeed score barely moved after I fixed all of this. Why?

Because the four switches address render blocking, not page weight. If a builder page ships several megabytes of images and fonts, the switches cannot reach that. [Removing unused CSS](https://xspeedcache.com/blog/remove-unused-css-wordpress/) has a measured ceiling too, and Lighthouse skips every stylesheet under 10 KiB when it reports the opportunity.

### Can I compare the plugins on something other than builder safety?

Yes, and you should. [We scored eleven caching plugins twice](https://xspeedcache.com/blog/best-wordpress-caching-plugin/) and one criterion moved us from first to fourth, which is the clearest illustration available of how much a ranking depends on what it weighs. The [nine WP Rocket alternatives](https://xspeedcache.com/blog/wp-rocket-alternatives-2026/) piece ranks on field data instead.

### Why is there no install count for Divi here?

Because none exists. Divi is sold by Elegant Themes and has never been in the wordpress.org directory, so the Plugin API returns `Plugin not found` for every spelling of the slug, and its source cannot be read the way Elementor's can. Every Divi claim in this article comes from Elegant Themes' own documentation or from a caching vendor's documentation about Divi, and that asymmetry is worth knowing when you read any Divi comparison.

### Does any of this change if I move to a faster host?

It changes the ceiling, not the switches. A builder page that misses the cache runs the builder's PHP every time, and that cost is the server's. Host caching also rarely touches the asset layer, which is the layer this whole article is about.

## Conclusion: Pick the Switch Policy First, Then the Plugin

The plugin matters less here than the policy. On a builder site, minify can stay on because two vendors have already excluded the files that would break, and the other three need a decision rather than a default.

| If you want… | Do this | Why |
|:---|:---|:---|
| The safest free setup | Minify on, combine off, async CSS off, delay JS with the vendor's exclusion list | Three of four switches have documented builder conflicts |
| The least work | WP Rocket, and work through its Elementor and Divi articles once | The exclusions are checkboxes and the lists are maintained |
| The best free option on LiteSpeed hosting | LiteSpeed Cache with its builder integrations left alone | Four dedicated integration files, whole-plugin disable in the editor |
| An editor guard that covers nine builders at no cost | xSpeed Cache free tier | Fourteen arguments in one filterable predicate |
| Evidence before a purchase | The two censuses above | Ten minutes, no account, no plugin |

**What to do this week:**

1. Download your caching plugin's trunk and run the one-line grep above. If it matches nothing, exclude your builder's editor argument by hand today.
2. Open your builder's own performance tab and write down which of the seven jobs in the ownership table above it is already doing.
3. Turn combine off, leave minify on, and re-test in a private window.
4. Run the asset census on your three most important URLs and count the unused plugins before you buy a script manager.
5. Re-check from outside your own browser with the [free xSpeed Scan](https://xspeedcache.com/scan/), then read the [page-builder use case](https://xspeedcache.com/use-cases/page-builder-sites/) for the settings that match what you found.

If you only have budget for one licence and you are not on LiteSpeed hosting, WP Rocket at $59.95 a year is the honest pick for a builder site, because the documentation is doing most of the work. xSpeed Cache starts free, with paid plans from $29 a year and a 14-day money-back guarantee on the [pricing page](https://xspeedcache.com/pricing/), and the [migration guide](https://xspeedcache.com/docs/migration/) imports settings from whichever of these you are leaving.