Divi hosting sized for the cache Divi rebuilds.
Divi keeps a stylesheet on disk for every page you have ever published. Change one global setting and it throws all of them away at once.
The cache directory is the workload.
Most of what makes a Divi site feel slow is file writing, not database work.
A theme option change purges everything
Divi stores generated CSS per post. Adjust a global colour and every one of those files is discarded and rebuilt on next view, which on a large site is thousands of writes.
Layouts live in the content, not in meta
Divi writes its builder output as shortcodes inside the post itself. A careless search-and-replace during migration corrupts them, so URL rewrites are done in a way that leaves the markup intact.
Autosave that does not pile up
The builder saves while you work, and each save is a write to the same post. Those requests are given room rather than queueing behind the front-end traffic.
Global modules invalidate widely
Editing one Divi Library layout changes every page that uses it. The purge is handled at the edge so visitors do not sit through the rebuild.
Roll back a layout you broke
A builder session that goes wrong is a content change, not a code one, so a daily backup is what gets the page back.
What happens after you press save.
A Divi save is not one write. It is the post, the revision, the static CSS for that page, and potentially every page sharing a global module.
- Static CSS written to fast local disk
- Shortcode content preserved through migration
- Builder autosaves given their own headroom
- Edge purge on global changes
The page after a purge is the slow one.
A Divi site is quick until something invalidates the CSS cache. The number worth measuring is the first request after that, because that is the one a visitor pays for.
What we change for Divi
Divi's performance model is a directory of generated files, so the tuning is mostly about writing them quickly and invalidating them carefully.
| Setting | What we do | Why |
|---|---|---|
| Static CSS storage | Local NVMe rather than network storage | A single theme option change discards the generated stylesheet for every page, and rebuilding thousands of files over a network mount is where that stalls. |
| Migration search-replace | Serialisation-aware, applied to shortcode content | Divi keeps layouts as shortcodes inside post content, so a plain string replacement across the database breaks the markup rather than the URLs. |
| Admin request headroom | Builder saves given capacity apart from front-end traffic | The builder autosaves continuously while somebody designs, and those writes should not compete with visitors for the same workers. |
| Edge purge scope | Widened when a global module changes | One Divi Library layout can appear on hundreds of pages, and purging only the edited page leaves the rest serving the old design. |
| Revisions | Capped per post | Builder autosaves generate revisions faster than editorial work does, and an uncapped post table is the result nobody notices until search slows. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why does my Divi site get slow after I change a theme option?
Will migrating a Divi site break my layouts?
Can I use Divi with a page cache?
Does the Divi Builder work well over a slow connection?
Make the rebuild the part nobody notices.
Move the Divi site across - migration is free, layouts intact.