When someone tells me their Divi site is slow, they usually expect me to blame Divi. It's rarely Divi. Most slow Divi sites are slow for the same reasons any WordPress site is slow: the server takes too long to answer, nothing is cached, the images are far bigger than they need to be, or a pile of plugins and third-party scripts load on every page. This guide walks through how I find the real cause, in the order I check things, and what to do about each one.
Don't change anything until you've measured. Run the page through Google PageSpeed Insights and keep a copy of the results: print the report to PDF from your browser, or take a screenshot. Test a real inner page, not just the homepage, and test mobile, because that's the score Google leans on. Without a before number you can't tell whether a fix helped or just moved the problem.
Measure the Right Things
PageSpeed Insights gives you two kinds of data, and they answer different questions:
| What you see | What it means |
|---|---|
| Real-user data ("Discover what your real users are experiencing") | How the page actually performed for visitors over the last 28 days. Only shows up once the page has enough traffic. This is what Google uses. |
| Lab data (the Performance score) | One simulated load on a throttled phone. Good for finding causes and testing fixes, but it moves around from run to run. |
The number that tells you the most about a slow site is the server response time. In the lab report, look for "Reduce initial server response time" or a long "Time to First Byte". If the server takes more than about 600ms just to start sending the page, no amount of image or CSS work will make the site feel fast. Start at Phase 2.
Hosting and Page Caching
If the first byte is slow, the problem is the server doing too much work on every visit, or doing it on underpowered hardware. Divi builds each page from your layout every time it's requested, like any WordPress page. Page caching saves the finished page and hands that copy to the next visitor instead.
- Check you have page caching at all. Many hosts include it. If yours doesn't, a caching plugin does the same job. Load the page twice while logged out: if the second load isn't clearly faster, nothing is caching it.
- Test logged out. Most caching skips logged-in users, so the site always feels slower to you than to your visitors.
- Cheap shared hosting has a ceiling. If response times stay slow with caching on, the server is the bottleneck. That's a hosting decision, not a Divi setting. If you're disappointed with your current provider, I offer private, secure and fast WordPress hosting.
Check Divi's Own Performance Settings
Divi has a set of performance features under Divi → Theme Options → General → Performance. They're on by default, and they're the first thing that gets switched off while someone is troubleshooting something else and then forgotten. Open the tab and check them:
| Setting | What it does |
|---|---|
| Dynamic Module Framework | Loads only the code for the modules a page actually uses. |
| Dynamic CSS | Generates only the styles each page needs instead of one large stylesheet. |
| Dynamic Icons | Loads only the icons in use instead of the full icon font. |
| Critical CSS and Critical Threshold Height | Loads the styles for the top of the page first and defers the rest, so the page appears sooner. |
| Dynamic JavaScript Libraries | Loads scripts only on pages that need them. |
| Defer jQuery And jQuery Migrate, Defer Gutenberg Block CSS, Defer Additional Third Party Scripts | Stops those files from blocking the page while it renders. |
| Improve Google Fonts Loading, Limit Google Fonts Support For Legacy Browsers | Loads Google Fonts more efficiently. |
| Disable WordPress Emojis | Removes WordPress's emoji script, which almost no business site needs. |
Divi and a caching or optimization plugin will both try to combine, minify and defer CSS and JavaScript. Running both is a common cause of broken layouts and no speed gain. Pick one to own each job. If you keep Divi's Critical CSS on, turn off the plugin's version of the same thing. I've found it works best not to use any "performance" plugins with Divi at all, and to use caching features only. I recommend the free version of Super Page Cache, which also integrates with Cloudflare.
Images and Fonts
After the server, images are the most common cause I see. A single photo uploaded straight from a phone or a stock site can be several megabytes, and a Divi page with a slider and a gallery can easily carry a dozen of them.
- Resize before you upload. An image never needs to be wider than the largest space it fills on the page. A full-width hero rarely needs more than about 2,000 pixels wide.
- Use a modern format. WebP is usually much smaller than JPEG or PNG at the same visible quality, and every current browser supports it.
- Let a plugin do the work. The free version of WPMasterToolKit converts images to WebP and optimizes and resizes large images on upload. I recommend not keeping the original JPEG and PNG files. They're unnecessary and only use up storage. Every current browser supports WebP, so your site serves the converted images correctly without any extra setup.
- Watch the top of the page. The first large image a visitor sees is usually what PageSpeed reports as the Largest Contentful Paint. Make that one small and fast before anything else.
- Cut font weights. Every font weight and style is a separate file. Two families in two or three weights each is plenty for most sites.
Plugins, Scripts and Page Weight
Plugins aren't slow because there are many of them. They're slow when they load code on every page whether it's needed or not. The same goes for third-party scripts: chat widgets, booking tools, embedded maps, social feeds, tracking pixels and video embeds each add their own downloads.
- Find what's heavy. In PageSpeed, the "Reduce the impact of third-party code" and "Reduce unused JavaScript" items name the worst offenders.
- Remove what you don't use. Deactivate and delete plugins you tried once and forgot. Deactivated plugins don't slow the front end, but deleting them is cleaner and safer.
- Load embeds only where they're needed. A map or booking widget belongs on the contact page, not in the footer of every page.
- Go easy on motion. Sliders, video backgrounds and entrance animations on every section all cost something. Keep the ones that earn their place.
- Check what loads where. Look at the render-blocking items in the PageSpeed report and check whether plugins that only belong on certain pages are loading on every page. Many plugins load their scripts sitewide even though they're only needed in one area. A learning management (LMS) plugin, for example, usually only needs to load on your course pages, not on your homepage or unrelated pages. A plugin such as Freesoul Deactivate Plugins lets you turn those plugins off on the pages that don't need them. WPTuts has a good video walkthrough of how to set it up.
Test Again, and Keep It Fast
Run the same page through PageSpeed Insights after each change and compare it with your before number. Make one change at a time where you can, so you know which fix actually helped. Real-user data takes weeks to catch up, so judge individual fixes by the lab numbers and the overall result by the real-user data a month later.
Speed also slips back over time. New plugins get added, bigger images get uploaded, and settings get changed during troubleshooting. A quick check every few months catches it before visitors notice.
Things That Will Save You an Afternoon
- Always test logged out. Logged-in pages skip caching and load the builder's extra tools.
- Clear every cache after a change. That means Divi's, your caching plugin's and your host's. Otherwise you're testing the old page.
- One PageSpeed run is not a result. Scores vary from run to run. Run it three times and look at the middle score.
- A perfect score isn't the goal. A page that loads quickly for real visitors and passes the real-user checks is. Chasing the last few points often costs more than it's worth.
- Don't disable Divi's performance settings to fix a display problem without writing down what you changed. That's how sites end up slow months later.
Quick Reference: Where to Look
If you've worked through this and the site is still slow, or you'd rather not spend the afternoon on it, that's the kind of work I do every day. I can find what's slowing your site down and fix it, and my Webcare plans keep it fast after that. You'll find more Divi 5 guides on my Divi specialist page.
