How to speed up a Divi site and improve its Core Web Vitals (step by step)

Divi has a reputation for being heavy. It ships a lot of CSS and JavaScript so the visual builder can do everything, and out of the box that weight shows up in your Core Web Vitals. The good news: a Divi site can be fast, and you do not need to gut it to get there.

The trick is to optimize in the right order, and to start with the levers that cannot break anything. That safe-first method is the backbone of this guide. We will go Images, then CSS, then JavaScript, from the safest to the most delicate, and each step builds on a dedicated guide you can dig into.

Step 1: Images (the safest lever)

Images are almost always the biggest weight on a Divi page, and Divi makes it worse in one specific way: it leans on a lot of full-width images and a lot of CSS background images (section and module backgrounds).

The safe moves are the usual ones, and none of them can break anything: compress your images, serve them as WebP or AVIF, and serve them at the right dimensions rather than a huge file shrunk by CSS. Lazy-load the images below the fold, but never the hero image at the top (the LCP), or you slow it down. And set width and height (or an aspect-ratio) so the layout stops jumping (CLS).

Here is the Divi-specific catch. Section and module background images have no srcset at all. The srcset/sizes lever simply cannot touch them, so no tool can right-size them for you. You have to compress and size those upstream, before they are set as backgrounds. This images-without-srcset case is covered in our guide on srcset and sizes.

And for the regular images, the sizes attribute Divi and WordPress generate is often wrong the moment an image sits in a column or a grid, which is most of a Divi layout, so the browser over-downloads. Why that happens, and how to read it in DevTools in thirty seconds, is the subject of that same srcset guide.

Step 2: CSS

Divi has its own performance panel (Theme Options → Performance). Turn on Dynamic CSS: instead of loading Divi’s entire stylesheet, it loads only the CSS of the modules actually used on the page. That is a big, safe gain. Dynamic Module Framework and Dynamic Icons work the same way, loading only what a page needs.

Divi also has a Critical CSS option. If you already run an external critical-CSS tool, do not run both. Turn Divi’s Critical CSS off and let a single engine own the job. Two engines fighting over the same concern is how you get inconsistent, hard-to-debug pages. Call it the golden rule: one engine per concern.

This is where the classic Divi breakage happens. Critical CSS and remove-unused-CSS keep only what is visible at the top of the page on load. Your mobile menu, search overlay and mega-menu are hidden at that moment, so their styles get stripped, and they show up open or unstyled. The durable fix is to inline those interactive rules in a non-optimizable block after wp_head(), so they travel with the theme. The full method, and the traps around per-URL and mobile/desktop caches, is in the critical-CSS guide.

One more Divi habit: after a big change, regenerate Divi’s static CSS. A stale Divi cache can serve a truncated stylesheet, which looks exactly like a broken optimization. Purge and regenerate, then check the real render.

Step 3: JavaScript (and the Divi menu)

Divi loads jQuery, and on most sites it is the menu that forces it. Deferring JavaScript is a big win, but it is also where things break if done carelessly.

The emblematic case is the burger menu that only opens on the second click. Divi even has a setting for it, Defer jQuery And jQuery Migrate, and turning it on naively triggers exactly that bug: the first tap wakes the script loading instead of opening the menu.

The fix, while keeping the Divi menu, is to exclude the whole dependency chain from the delay together: jQuery, jQuery Migrate, and the menu script. Target them by a unique URL fragment (not the internal handle, which can be stripped), and keep a document-state guard so the excluded script tolerates running early. Do that, and the menu responds on the first tap again. If you cannot manage the chain, leave Defer jQuery off rather than ship a two-tap menu. The step-by-step is in the burger-menu guide.

Once the menu is handled, deferring or delaying the rest (sliders, lightboxes, and so on) is fine and gives you the bulk of the JavaScript gain.

Step 4: The order and the method

Put it together with the safe-first method. First, turn on all the safe wins: image compression and dimensions, off-screen lazy-load (never the LCP), minification, server compression, browser caching, font-display. They cannot break anything, so you do not test them one by one.

Then measure your Core Web Vitals to see what is left. Only then tackle the to-test levers, critical CSS and JavaScript deferral, one at a time, checking mobile AND desktop and your key flows (menu, search, cart) after each change. The full rationale is in the safe-optimizations pillar.

With Mantys Core

In summary

• Divi can be fast; optimize in order, Images then CSS then JavaScript, and start with what cannot break.
• Images: compress, WebP, right dimensions, lazy-load off-screen (never the hero); Divi background images have no srcset, so size them upstream.
• CSS: turn on Dynamic CSS; keep one critical-CSS engine, not two; protect hidden-on-load menus and overlays; regenerate Divi’s static CSS after big changes.
• JavaScript: to keep the Divi menu with JS delay on, exclude the whole jQuery chain by URL fragment with a state guard, or leave Defer jQuery off.
• Method: all the safe wins first, measure Core Web Vitals, then the risky levers one at a time, testing mobile and desktop.