Why Is My Divi Site So Slow? (And How to Fix It)

Measure the Right Things

PageSpeed Insights gives you two kinds of data, and they answer different questions:

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:

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.