Speed up a Divi site without rebuilding it in another builder

Unanimous, on 23 sites

Most platform pages report shares. This one reports two absolutes, so it is worth stating the denominator first: 23 Divi sites, audited by us, on the snapshot date printed with the figures below. That is not a sample of the web, and 23 is not a large number. It is, however, unanimous.

Every one of those 23 sites shipped scripts that block the parser. Every one shipped a stylesheet chain that blocks the first paint. On plain WordPress the same two defects sit at 79% and 92% of 61 audited sites, which is high and still leaves room for a site to be built otherwise. On Divi we have not yet measured one that was.

That is a property of how the builder assembles a page — not of how carefully your site was built. Sections, rows and modules each carry their own styles and their own behaviour, and the page they compose asks the browser for all of it at once.

What the builder puts in your head

A Divi page arrives as a stack of full-width sections. The visual weight of the first one is usually a background image set in CSS — and that is the part that costs you. A CSS background is invisible in the markup, so the browser discovers your hero only after the stylesheet has been fetched, parsed and applied. On 91% of the sites we audited, the largest image on the first screen was being found that late.

The rest of the head is volume. Divi generates per-module styles, your child theme adds its own, plugins add theirs, and the result is a long list of small files. Small files are cheap in bytes and expensive in round trips. On a phone the round trips are the bill.

None of this is reachable from the Builder. You can remove modules, and you can switch on Divi’s performance settings, but the order in which a browser is allowed to use what it received is a property of the response, not of the page you designed.

The share that does not gain

Across 22 Divi audits with a verified before and after, the mobile score rose and the desktop score held on 64% of them. On 27% the mobile score went down. The median mobile gain was +7 points, and visible loading speed (Speed Index, how quickly the page fills in) came out 1.22× faster.

That spread is not a Divi trait. A larger study across 381 sites found that what a site gains depends far more on where it started than on what it runs: sites in the 30s and 40s gained a median of 11 points, sites already above 70 were a coin flip. If your Divi site is slow, the numbers on this page are the relevant ones. If it is already fast, the honest answer is that there is less here for you.

Three things a proxy cannot reach

A slow server. We can serve a cached copy of a page quickly — but a request that takes your host two seconds to compute still takes two seconds. That is a hosting conversation, and Divi sites on shared hosting have it often.

Requests you asked for. The sites in our audit base load from a median of 12 hosts they don’t own. We defer third-party scripts so they stop competing with your layout. We do not remove them, because which pixels and widgets your business runs is not our call.

A layout that draws itself with JavaScript. A minority of Divi builds paint the first screen after load rather than in the response. Deferring anything there moves the problem instead of solving it, and we switch that optimization off for the domain rather than publish a number that means something else.

What the audit reports back

It measures your site twice — as it is now, and served through WebSpeed — on mobile and desktop, and lists every change that produced the second number. It takes a few minutes and needs only the address. If your site turns out to have little to gain, the report says that too, which was the outcome for about a quarter of the Divi sites we have measured.