The Real Problem: Conflicting Caching Layers
Let’s break down where caching happens in a typical Divi site:
Browser Cache
This is the cache stored on a visitor’s local computer. Web browsers like Chrome and Firefox save static assets such as images, CSS stylesheets, and JavaScript files to avoid re-downloading them on subsequent visits, which speeds up browsing. While clearing the browser cache is a necessary first step in troubleshooting, it often only resolves the issue for the individual user and does not fix the underlying problem for other visitors. It is a diagnostic tool, not a root cause solution.
Plugin Cache (Page & Asset Caching)
This is the most powerful and configurable layer, managed by popular caching plugins like WP Fastest Cache. These plugins perform two primary functions:
Page Caching: They create static HTML files of your dynamic WordPress pages.
Asset Optimization: They minify, combine, and optimize the loading of CSS and JavaScript files. This is the most common source of direct conflict with Divi’s internal performance features.
Divi’s Theme Cache (et-cache)
Divi contains its own caching mechanism, primarily associated with the “Static CSS File Generation” feature. This system compiles the design styles from the Divi Builder, Theme Options, and Theme Customizer into static CSS files, which are stored in a dedicated directory: /wp-content/et-cache/. The goal is to serve these pre-built files for better performance. However, this cache is notoriously prone to becoming stale or corrupted, especially after updates, leading to a sudden loss of all custom styling.
Server-Side Cache
Many managed WordPress hosting providers (such as Cloudways) implement their own caching systems at the server level. This can include page caching, object caching, or other proprietary optimizations. This layer is often “invisible” to the user within the WordPress dashboard but can be highly aggressive. It can serve stale content even after a plugin’s cache has been cleared, causing significant confusion and
Content Delivery Network (CDN) Cache
A CDN, such as Cloudflare is a network of servers distributed globally. It stores copies of your site’s static assets (images, CSS, JS) and serves them to visitors from the server geographically closest to them, reducing latency. A CDN introduces another caching layer that must be managed. If the CDN cache is not purged, it can continue to serve old, broken files even after all other caches have been cleared. Misconfigurations at the CDN level can also lead to issues like mixed content errors (HTTP vs. HTTPS) if not handled correctly.
The catch? These layers can all serve stale or broken files if they’re not cleared, or worse, if two layers try to optimize the same file differently. That’s when your site looks fine to you but totally broken to your visitors.
Common Problems and What They Really Mean
1. Broken Styles or Layouts (CSS Conflict)
Symptoms: Fonts revert to defaults, your custom header turns blue, layout shifts everywhere.
Likely Cause: WP Fastest Cache is serving an outdated or minified version of Divi’s static CSS file. If Static CSS File Generation is enabled, Divi stores page-specific styles in /wp-content/et-cache/, which caching plugins can freeze in time.
2. Sliders, Menus, or Animations Not Working (JS Conflict)
Symptoms: Mobile menu won’t open. Sliders don’t slide. Accordions stay stuck.
Likely Cause: JS combine/minify or deferral in WP Fastest Cache is breaking script order. Divi’s scripts (like et-builder-front-end.min.js) depend on jQuery and a specific load order. Combine or defer those incorrectly, and scripts silently fail.
jquery.js and et-builder-front-end.min.js.3. Divi Builder Doesn’t Load (Infinite Spinner)
Symptoms: You click “Enable Visual Builder” and it just… spins.

Likely Causes: Cached backend scripts. Low server memory. JS conflicts. If WPFC caches or minifies admin requests or delays AJAX, the builder may never load. Worse, builder data might be stuck in your browser or Divi’s own transient cache.
Fix: Use Safe Mode (Divi > Support Center), then increase WP_MEMORY_LIMIT to 512M+, exclude all URLs with ?et_fb=1 from cache, and clear every layer.
How to Properly Configure WP Fastest Cache for Divi
- Disable Static CSS File Generation in Divi (Theme Options > Builder > Advanced)
- (either) Let Divi Handle CSS: Keep Dynamic CSS + Critical CSS ON. Turn OFF CSS minify/combine in WPFC
- (or) Let WPFC Handle CSS: Turn OFF Divi’s Dynamic and Critical CSS. Turn ON CSS minify/combine in WPFC
- Don’t cache logged-in users: Crucial for working in the Visual Builder
- Exclude Divi Builder URLs: Use wildcard rules like
*et_fb=1*and*et_builder* - Exclude Scripts: Exclude jQuery and Divi frontend scripts from JS optimization (premium feature)
Best Practices for Development vs Live Sites
- During Development: Disable ALL caching (WPFC, Divi Performance, server, CDN). You want instant feedback.
- Before Launch: Re-enable WPFC, disable redundant Divi features, purge every cache layer.
- After Updates: Always purge Divi, WPFC, hosting, and CDN caches after updating Divi or plugins.
Bonus: Use Divi Nitro to Complement Your Caching Setup
Divi Nitro is our in-house performance plugin designed specifically for Divi sites. It’s not a caching plugin like WP Fastest Cache, and it doesn’t duplicate Divi’s performance settings either. Instead, Nitro fills in the gaps letting you surgically remove code from specific pages, defer heavy scripts, and lazy-load with precision.
This means Nitro works alongside either WP Fastest Cache or Divi’s own performance suite without conflict. You’re not choosing one or the other, you’re using Nitro to do what neither of them can.
Exclude Scripts on Specific Pages (One of Nitro’s Killer Features)
Want to load a script only on one page and remove it everywhere else? Divi Nitro makes that possible without writing functions or touching functions.php. This is ideal for heavy third-party plugins or form libraries that load everywhere even when you don’t use them.
This goes well beyond simple exclusions in caching plugins or theme settings. It gives you precise control on a per-page level without needing advanced dev tools.
Nitro Works With WP Fastest Cache or Divi Performance
Because Nitro isn’t doing full-page caching or global minification, it doesn’t conflict with WPFC or Divi’s performance suite. Use it to:
- Remove unneeded styles/scripts on specific pages
- Defer or delay third-party scripts that aren’t needed right away
- Lazy-load images with advanced options
- Improve Google PageSpeed scores by targeting bottlenecks caching plugins can’t touch
Learn more about Nitro’s page-level controls in our Divi Nitro documentation.
What Changes in Divi 5?
Divi 5 is ditching shortcodes, static CSS bloat, and builder lag. Its class-based CSS system and rebuilt engine will reduce reliance on caching altogether. But for now, if you’re using Divi 4.x or on the transition path, this guide still applies.
Divi 5 is also expected to resolve conflicts with object caching (Redis, Memcached) that used to mess with dynamic layouts and styles. Until then, object caching should be tested carefully if you rely on it.
Final Thoughts
Divi + WP Fastest Cache is a killer combo…when you use it properly. Set each system to do its own job and avoid duplication. Disable Divi’s Static CSS, pick one CSS optimizer, and exclude the builder from caching. That’s it. Stick to this playbook, and you’ll enjoy a Divi site that’s fast, stable, and easy to update.

0 Comments