Why Is My Divi Site So Slow? Three Answers
The short version
If you are asking why is my Divi site so slow, the first job is to work out which slow you mean, because Divi has three unrelated performance problems and the fixes do not overlap. A slow front end for visitors is usually Divi’s CSS and JavaScript payload plus missing caching, and it is addressed in Divi > Theme Options > Performance. A slow Visual Builder is almost always PHP limits on your server, not Divi. A slow wp-admin is usually not Divi at all.
Everything on this page is drawn from Elegant Themes’ own documentation, help centre and release notes, read on 30 August 2026, with each figure attributed where it appears.

Why is my Divi site so slow? Answer the right question first
Search that phrase and Google hands you a Reddit thread, a Facebook group post and a support forum before it hands you an article. That is not an accident. It happens when a question has several different answers and no editorial page has bothered to separate them, so Google falls back on people talking to each other. The three answers are:
- Visitors wait. The published page takes too long to load in someone else’s browser. This is a payload problem: Divi’s stylesheet and scripts, your images, and whether anything is cached.
- You wait in the builder. The site loads fine for visitors, but the Visual Builder takes forever to open, save or respond. This is nearly always a server configuration problem, and Elegant Themes documents the exact settings.
- The whole dashboard crawls. Every admin screen is slow, Divi pages and non-Divi pages alike. Divi is rarely the cause here, and turning Divi settings on and off will not help you.
Before you change a single setting, load a page as a logged-out visitor in a private window and time it. Then open the Visual Builder and time that. Then open a plain WordPress admin screen such as Settings > General and time that. Whichever one is slow tells you which section below applies to you. If all three are slow, start with the server, because a starved server makes everything else untestable.
The eleven performance settings Divi ships, and what each one does
Divi’s performance options live in Divi > Theme Options > Performance. Elegant Themes documents eleven of them in its Dynamic CSS and frontend performance help article. The table below is that list, restated with what turning each one on actually costs you, because the help article does not say. The claims in the middle column are Elegant Themes’ own published figures.
| Setting | What Elegant Themes claims for it | What it can break |
|---|---|---|
| Dynamic CSS | Stylesheet split into components and assembled per page; ET cites a reduction from 860KB to 54KB in its own testing | Custom CSS that relied on a selector Divi no longer prints on that page |
| Dynamic PHP Framework | Only the logic for modules actually used on a page is processed | Third-party module add-ons that hook a Divi function on every page |
| Dynamic Icons | Icon font loaded on demand; ET cites 90KB down to 6KB | Off by default on child themes and custom modules — see below |
| JavaScript Optimization | Libraries loaded per module; ET says base JavaScript was cut in half | Custom jQuery that assumed a Divi library was always present |
| Critical CSS | Above-the-fold CSS identified, everything else deferred | Visible flash of unstyled content; conflicts with a caching plugin doing the same job |
| Smart Styles | Duplicate styles identified and selectors combined; works with Divi Presets | Little, but the saving depends on you actually using Presets |
| In-Line Stylesheet | Base stylesheet printed inline, removing a render-blocking request | Larger HTML on every page; no browser caching of that CSS between pages |
| jQuery Deferral | jQuery moved asynchronously to the footer when not needed in the header | Silently reverts when a plugin declares jQuery as a dependency — see below |
| Google Fonts Caching | Fonts cached and printed inline in the header, removing render-blocking requests | Nothing meaningful; this one is close to free |
| Gutenberg Stylesheet Deferral | Block editor CSS lazy-loaded on Divi Builder pages | Pages that mix Gutenberg blocks into a Divi layout |
| WordPress Emoji Removal | Native WordPress emoji script and styles removed | Emoji rendering on very old browsers, which in practice means nothing |
Turn them on one at a time, clear every cache after each, and reload the front end as a logged-out visitor. Turning all eleven on in a single click is how people end up with a broken layout and no idea which switch did it.
Two Divi performance settings that quietly do nothing
This is the part that most “speed up Divi” articles miss, and it is written into Elegant Themes’ own documentation rather than hidden anywhere.
Dynamic Icons is disabled by default if you use a child theme or a custom Divi module. That is Elegant Themes’ wording. A very large share of Divi sites run a child theme, because that is the standard advice for adding custom CSS or PHP without losing it on update. If yours does, the setting that Elegant Themes says takes the icon font from 90KB to 6KB is off, and it was off before you opened the Performance tab. Open the tab and look at the toggle rather than assuming.
jQuery deferral reverses itself without telling you. Divi will relocate jQuery back into the header whenever an enqueued script declares it as a dependency. One plugin doing the correct, ordinary thing — declaring jquery in its wp_enqueue_script call — is enough to undo the setting for the whole page. Elegant Themes also notes plainly that the option “can be disabled if it causes problems,” which is a fair warning that it is the option most likely to break something.
The practical consequence: if you switched everything on, saw no improvement and concluded Divi’s performance options are marketing, you may have been looking at two options that were never in effect. Check the front-end source for the icon font file and for where jquery.min.js is loaded before you write them off.
Why is my Divi site so slow in the Visual Builder but fine for visitors
This is a different problem with a different fix, and it is the one people most often misdiagnose as “Divi is bloated.” If your published pages load quickly for a logged-out visitor and only the Visual Builder drags, the payload is not your problem — your server’s PHP configuration is.
Elegant Themes publishes the floor it expects in its builder timeout troubleshooting article. These are minimums, not targets:
| PHP directive | Minimum Elegant Themes lists |
|---|---|
memory_limit |
128M |
post_max_size |
64M |
max_execution_time |
120 |
upload_max_filesize |
64M |
max_input_time |
60 |
max_input_vars |
1000 |
Elegant Themes recommends PHP 8 or later, and at minimum PHP 7.4. You can read your current values in Tools > Site Health > Info > Server without installing anything. If memory_limit reads 64M or max_input_vars reads 1000 on a page with hundreds of modules, you have found your answer, and the fix is a support ticket to your host rather than a settings change.
max_input_vars deserves special attention on long Divi pages. Every module setting is a separate variable on save. A page with several hundred modules can exceed 1000 variables, and what you see is not an error message — it is a save that silently drops the tail of your layout. If you have ever lost the bottom half of a page after saving, this is the likeliest cause.
The other three causes Elegant Themes names for the builder failing or dragging are cache layers conflicting after an update, plugin conflicts, and simply running an outdated Divi. Its Visual Builder troubleshooting page gives the standard elimination method: disable every plugin, confirm the builder behaves, then re-enable one at a time. It is tedious and it works.
When wp-admin crawls, Divi is usually not the cause
If Settings > General is as slow as a Divi page, you are looking at a server or database problem wearing a Divi costume. The usual suspects are shared hosting that throttles CPU when you exceed an allowance you were never shown, a wp_options table full of autoloaded rows left behind by plugins you removed years ago, and PHP 7.x still running because nobody clicked the upgrade button in the hosting panel.
The test that settles it in two minutes: switch temporarily to a default WordPress theme on a staging copy. If wp-admin is still slow, Divi was never the problem, and no amount of Performance-tab tinkering will change that. Our notes on choosing WordPress hosting and the comparison of Kinsta against WP Engine cover what a host actually has to provide before any theme can perform.
What Divi 5 changed about performance, and what it did not
Divi 5 removed shortcodes. In Divi 4, every module was stored in post content as a shortcode, and WordPress parsed that on every page load. Elegant Themes’ article Divi 5 Waves Goodbye To Shortcodes, published 30 September 2024 and updated 4 November 2024, gives four reasons for the change: parsing shortcodes “is less efficient because it doesn’t have a proper hierarchy,” shortcodes were never designed for deep nesting, “one rogue character could crash the whole system,” and shortcodes do not align with WordPress’s own block structure.
Worth stating plainly, because no other page seems to: Elegant Themes gives no numbers for the performance half of that argument. No percentage, no benchmark, no before-and-after. The stability and nesting arguments are concrete and believable. The speed argument is a claim, and until someone publishes a like-for-like measurement it should be treated as one.
Divi 5 also changes what “update Divi” means. The current release at the time of writing is Divi 5.11.1, dated 19 August 2026 in the Elegant Themes Divi 5 update status changelog, and Elegant Themes ships a Migrator system for moving existing Divi 4 sites across. If your slowness started immediately after a major update, roll back on a staging copy before you spend an afternoon on the Performance tab — you are debugging a migration, not a payload.
Where Divi loses
Being straight about this is more useful than another list of toggles.
The baseline is heavy and always will be. A builder that can render fifty-odd module types has to ship the code for the ones you use. Dynamic CSS and dynamic JavaScript reduce that per page; they do not make Divi as light as a block theme with no builder. If you are chasing a sub-one-second load on a shared host, the honest answer is that a lighter theme gets there more easily — see our notes on the fastest WordPress themes, Kadence and Blocksy.
The builder is browser-heavy by design. The Visual Builder renders your actual page and layers an editing interface over it. On a laptop with a dozen tabs open it will feel slow, and there is no setting that fixes that.
Performance settings interact badly with aggressive caching plugins. Divi’s Critical CSS and a caching plugin’s “optimize CSS delivery” are doing the same job. Running both is a common cause of pages that look broken for the first half-second. Pick one layer to do it. Our WP Rocket review and roundup of WordPress cache plugins cover what those plugins take over.
Layout lock-in still shapes your options. Divi 5 replaced shortcodes with a structured format, which is better, but it is still Divi’s format. Leaving the builder still means rebuilding pages. That is true of every page builder, and it is worth knowing before you commit — Beaver Builder compared with Divi and Divi against Themify Ultra both come down to the same trade.
A working order for fixing a slow Divi front end
- Confirm which slow you have using the three-timer test at the top of this page. Do not skip this.
- Check PHP first in Tools > Site Health > Info > Server against the table above. A starved server makes every later step unmeasurable.
- Enable Divi’s performance options one at a time, clearing caches between each, and confirm Dynamic Icons is genuinely on if you run a child theme.
- Fix images before you fix code. On most Divi sites the largest single payload is a full-resolution hero image nobody resized. See our roundup of WordPress image optimizer plugins and notes on whether you still need a lazy load plugin.
- Add one caching layer, not three, and turn off any CSS optimisation in it that duplicates Divi’s Critical CSS.
- Audit your plugins. Divi add-on packs are convenient and they load on every page whether or not you use their modules on that page.
- Reduce module variety per page before you reduce content. Ten instances of three module types is cheaper than one instance of ten.
If you are still on Divi and weighing whether it is the right theme at all, our Divi theme review sets out what you get for the money, and the Elegant Themes discount page covers what a Divi discount actually looks like. Existing Divi sites are worth seeing too — we keep a list of sites built with Divi, a set of Divi blog child themes, and a walkthrough of building a WooCommerce store with the Divi Theme Builder.
See Divi at Elegant Themes
This is an affiliate link. WPNeon earns a commission if you buy through it, at no extra cost to you. It does not change what this page says about where Divi loses.
Frequently asked questions
Is Divi slower than Elementor or Beaver Builder?
There is no independent, current, like-for-like benchmark worth standing behind, so we will not claim a winner. All three ship builder code that a block theme does not. The differences that reliably matter in practice are your host, your images and your caching setup, not the choice between the three builders.
Will turning on every Divi performance option make my site fast?
No. It will reduce Divi’s own payload, which is one part of the problem. If your host is throttling, your hero image is four megabytes or nothing is cached, the Performance tab cannot rescue that. Enable the options one at a time so you can see what each one is worth.
Why is the Divi Visual Builder slow when my site is fast?
Almost always PHP limits. Elegant Themes lists 128M memory, 120 seconds execution time and 1000 input variables as the floor, and long pages exceed the input variable limit routinely. Check Tools > Site Health > Info > Server, then ask your host to raise the values.
Does upgrading to Divi 5 make my site faster?
Elegant Themes says removing shortcodes improves parsing efficiency but has published no figures for it. Divi 5 is worth adopting for stability and structure. Treat any speed gain as unproven, and migrate on a staging copy first using their Migrator rather than in place.
Should I switch away from Divi to fix speed?
Only after you have checked PHP limits, images and caching, because those explain most slow Divi sites and follow you to any theme. If you have fixed all three and still need a lighter baseline, a block theme will get there more easily — but you will be rebuilding every page you have.
Why do forums rank above articles for this question?
Because the question has three unrelated answers and most articles pick one and present it as the whole story. Google surfaces forum threads when it cannot find a page that separates the cases, which is a reasonable signal about the state of the published advice.
Sources read on 30 August 2026: the Elegant Themes help centre articles on Dynamic CSS and frontend performance, the Divi Builder timeout error and the Visual Builder failing to load; the Divi 5 update status changelog; and the Elegant Themes blog post on shortcode removal in Divi 5. Our method is set out at how WPNeon verifies what it publishes. If you are giving an AI assistant access to a WordPress site, start with WordPress MCP security and our breakdown of which WordPress MCP server packages are maintained.