Divi is one of the most capable page builders in the WordPress ecosystem, but its flexibility has historically come at a performance cost. Every module you drop onto a page carries CSS, JavaScript, and (in Divi 4) a nest of shortcodes that the server has to parse on every request. The good news is that a slow Divi site is almost never a lost cause — it is usually a stack of fixable defaults. Here is exactly where the weight comes from and what to do about it, in roughly the order that gives you the biggest wins first.

Start with the Divi Performance panel — most people never open it

Before you install a single plugin, go to Divi → Theme Options → General → Performance. This panel is the most Divi-specific lever you have, and the majority of sites I see have never touched it. The toggles here change what code Divi generates and how it loads:

Dynamic CSS — instead of loading Divi's entire ~700KB stylesheet on every page, Divi generates only the CSS the current page's modules actually use. Leave this on. It is the single highest-impact toggle for render-blocking weight.
Dynamic Module Framework and Dynamic JavaScript Libraries — these load module-specific PHP and JS only when a page uses that module. If a page has no slider, the slider's code never loads. Keep both on.
Critical CSS — inlines the above-the-fold CSS and defers the rest, which directly improves Largest Contentful Paint. This one needs testing: on complex full-width layouts it can occasionally cause a flash of unstyled content or a brief layout shift. Enable it, then walk your key templates on a real device before committing.
Defer jQuery and jQuery Migrate and Load Dynamic Stylesheet In-line — both reduce render-blocking requests. Defer is safe on most sites but can break third-party scripts that expect jQuery to be ready immediately, so check any custom code or older plugins.

Turning these on is free and reversible. On a typical Divi 4 site, enabling Dynamic CSS plus the dynamic frameworks alone can cut a page's CSS payload by half or more.

The biggest lever in 2026: move to Divi 5

Divi 4's deepest performance problem is architectural. It stores page content as deeply nested shortcodes in the post body, which means the server re-parses a wall of shortcode markup on every uncached request, and your wp_postmeta table bloats with builder data. No amount of caching fully hides this on dynamic pages.

Divi 5 — which reached general availability on February 26, 2026 and is on a weekly release cadence (5.3 and beyond by mid-2026) — is a ground-up rewrite of the builder that addresses this head-on. It replaces shortcodes with structured data, ships a modern React-based builder, and produces dramatically leaner front-end output. If you are running Divi 4, upgrading is now the most consequential speed decision you can make, and Elegant Themes built the 5.0 release around backward compatibility and an in-place upgrade path.

One caveat worth stating plainly: Divi 5 is young. The 2026 releases prioritized stability and bug-fixing, but if you depend on niche third-party Divi plugins or heavy custom code, test the upgrade on a copy of your site first and confirm your add-ons declare Divi 5 support. For a brand-new build, start on Divi 5 — there is no reason to inherit the shortcode problem.

Stop Divi from loading Google Fonts remotely

By default, Divi pulls font families from Google's servers, which adds extra DNS lookups and external requests on the critical path — and creates a GDPR headache in the EU. Limit how many font families and weights you actually use (each weight is a separate download), and host the fonts locally. Divi 5 has improved font handling, but for any version you can serve fonts from your own domain with a plugin like OMGF (Optimize My Google Fonts) or by letting an optimization plugin handle local hosting. Self-hosted, preloaded fonts remove a render-blocking third-party dependency and tighten LCP.

Choose a caching stack that actually plays nice with Divi

Caching is where Divi sites are most often broken by good intentions. The page builder injects a lot of inline CSS and depends on specific load order, so aggressive Combine and Minify settings frequently mangle Divi layouts — collapsed sections, broken sliders, gaps where modules should be.

Use a cache plugin that the Divi community has shaken out:

WP Rocket — the safest default for Divi. Enable page caching, then turn on Minify and "Combine CSS/JS" one option at a time, checking the front end after each. Its "Remove Unused CSS" and "Delay JavaScript Execution" features are powerful for INP but are the most likely to need exclusions for Divi scripts.
FlyingPress — excellent modern alternative with strong unused-CSS handling and a Divi-aware reputation.
LiteSpeed Cache — if your host runs LiteSpeed/OpenLiteSpeed (many do), this is free and extremely fast, with server-level caching and image optimization built in.

The rule with all three: introduce optimizations incrementally and test. If a setting breaks a layout, add the offending file to that plugin's exclusion list rather than disabling the whole feature.

Tame images, sliders, and the Google Maps module

Divi makes it trivially easy to build image-heavy pages — full-width hero sliders, gallery modules, parallax backgrounds — and that is often the bulk of a slow page's weight. Run every image through ShortPixel, Imagify, or EWWW and serve next-gen formats (WebP, or AVIF where supported). Make sure native lazy-loading is on so off-screen slider images do not block the initial paint.

Two Divi-specific gotchas: the Map module loads the Google Maps JavaScript API, which is heavy — if you only need a static address, drop the module or use a lightweight static-map alternative. And reconsider auto-rotating sliders; each slide is a full image plus animation JS that hurts both LCP and Interaction to Next Paint.

Reduce module count and nested-div bloat

Every row and module Divi renders adds wrapping <div> elements and a slice of CSS/JS. A page assembled from dozens of stacked single-column rows produces far more DOM than the same design built with a few well-structured multi-column rows. When you audit a slow template, look for sections that could be consolidated, and delete modules that exist only as spacers — use padding and margin settings instead. A leaner DOM improves both layout speed and INP.

Respect that Divi is PHP-heavy — your host matters

Because Divi does more server-side work than a lightweight theme, your Time to First Byte is more sensitive to host quality. Aim for a TTFB under roughly 600ms (ideally well below). Run PHP 8.1 or newer, enable OPcache and persistent object caching (Redis or Memcached), and if you are on budget shared hosting and have already tuned everything above, the next real gain is often a better host — managed WordPress hosts like Kinsta, WP Engine, SiteGround, or a quality LiteSpeed host will move TTFB more than any plugin can.

Measure against the right targets

Optimize toward Google's Core Web Vitals thresholds, because that is what both users and rankings care about: LCP under 2.5 seconds, CLS under 0.1, and INP under 200ms (INP replaced FID as a Core Web Vital in March 2024). On Divi specifically, render-blocking CSS is usually what hurts LCP, and the builder's JavaScript is what hurts INP — which is exactly why the Performance panel toggles and the move to Divi 5 map so directly onto better scores.

Test with field data in Google Search Console and lab data in PageSpeed Insights, change one thing at a time, and re-measure. A Divi site that opens its Performance panel, runs on Divi 5, hosts its own fonts, caches sensibly, and lives on a decent host is no longer a "slow Divi site" — it is just a fast WordPress site that happens to be easy to edit.

How to Speed Up a Divi Website