Solved et-cache folder got too large - what now?

Hi, I'm running into the same problem. How did you solve it? Thanks, Daphne

 

Hey Daphne,

Hopefully curious sees your comment and can let you know how they solved it. But in case not, here's my take on it..

In general, there's no harm in deleting the et-cache folder's contents - Divi doesn't rely on its contents and will just re-create them as needed. If you do delete it, afterwards clear any other caches you are using (e.g. in performance plugins, etc), otherwise you might run into the situation where your pages are still referencing files from the et-cache which no longer exist (which was perhaps the issue that curious had).

The size of the et-cache folder will grow as more pages get cached, and also has tended to grow in size with new updates as they bring performance improvements that cache more aspects of the site. If you can, you're probably best to just make sure that it has the space it needs (perhaps talk you your host about this if you're not sure) and then leave it alone.

But if its size is causing you problems, one option is to disable CSS caching at:

WP Admin > Divi > Theme Options > Builder > Advanced > Static CSS File Generation

That should prevent Divi from storing as much in the et-cache folder, but note that it may have an impact on the performance of the site.

Hope that helps!

 

Thank you for your reply! Nothing seems to help. I've turned off all items under Divi > Theme Options > General > Performance as well as the Static CSS File Generation. It has not made enough of a difference.

I added Pee Aye's Divi Assistant module and set it to flush the cache every hour.

Using Wordfence, I limited all bots to 120 pages/sec thinking that possibly the bots are causing the file generation.

I am now running into this on another woocommerce site converted over to Divi.

Stilling looking for a solution to the root of this but I really appreciate your reply.

 

You're welcome, Daphne! Sorry you're still having trouble with this.

Before trying to offer any other suggestions to reduce the cache size, etc, can I take a step back and ask what problems specifically you're having with the site / as a result of the cache? E.g. are you reaching hosting storage limits, or finding styles not applied to the site, etc?

Since the Divi performance updates a while back introduced additional caching, a 300MB et-cache folder (as the OP reported) isn't particularly unusual. On my site, for example, which has 600 or so posts, the cache folder is around 150MB in size, or 0.25MB per post. My site isn't very heavy in customized (and hence cached) CSS, so it wouldn't surprise me to see a cache size of 1MB per post on sites with more customization. The et_cache folder itself contains a large number of folders, named by the post ID they apply to, so I have around 600 of these when the cache is full. Each folder contains around 6 CSS files. There are a few other folders and files in the folder too.

If you're seeing something similar to that, it's actually a sign that everything is working as it should be.

I'd be very wary of clearing the cache every hour. It means that many, possibly most, visitors (and Google) will visit the site in an uncached state. The site will be slower when uncached and may hurt site experience, conversions and search rankings. In general, you only want to clear the cache when you've made a change to the site that isn't showing up to logged out users. Divi usually manages clearing the necessary parts (and only those parts) of the cache to ensure changes show up without you needing to do anything and with minimal performance impact, but every now and again you may need to manually clear the caches to get your changes to show.

A full et-cache folder is actually a sign that your site is running quickly (relative to it's uncached state), so for many sites the goal would be to ensure that the cache folder can in fact grow to its full size and remain there for as long as possible.

That said, things do go wrong, so if you're either seeing a large amount of content in the et-cache folder in excess of what I've described, or you're in a constrained hosting environment which can't support a normal cache folder size then that would be worth investigating. Likewise, style issues that seem to be cache related.

Apologies for the long reply - my point is that if we can solve whatever symptoms you're experiencing on the site AND keep the normal caching in place, that would be better than trying to prevent caching altogether.

 

Hi,

It is so nice of you to give me your time. Thank you for the excellent reply.

This is a WooCommerce site with over 3000 products. Before the conversion to Divi, it was running at about 600+M with WP Rocket. That includes the database, site files, and logs but not the backups. I keep 14 days of backups. Another difference is that I built it using Divi Extended's BodyCommerce plugin.

I have other sites using WooCommerce, Divi, and WP Rocket. The product counts on those sites range from about 10 to about 100. None are as big as the site in question. The other WooCommerce sites are running about 600+M. After the conversion, the site in question shot up to about 1.5 Gig disk use.

These are my servers, so it is up to me how the space is allocated.

Based on what you are saying, is the 1.5G space what I should plan for?

 

You're very welcome, Daphne.

Each of these products will have its own page and hence associated sub-folder in et-cache, so yes, I think 1.5GB would be a normal cache size in your case, rather than the sign of any problems.

Probably the CSS generated for each of the product pages will be the same, so there'll be a lot of redundancy, but I don't believe Divi has any option to detect / share these cache files. Since you could add custom styles to any of the pages, Divi presumably works on the assumption that each page's styles may differ from those of other pages and stores them separately.

If you can, I'd allocate just go ahead and allocate that space. What you could do instead is exclude the et-cache folder from your backups, if your backup solution allows exclusions. While the production site will benefit from the cache, there's no need to back it up as it will be recreated if the backup if / when the backup is restored.

 

Hi,

Thank you for helping me set realistic expectations and keeping me out of trouble

The suggestion about excluding cache directories from the backup was stunningly simple and pure genius. I have started implementing that on other websites as well. It makes up the difference in the large cache files, nulling the disk space increase.

In the end, I've come out ahead, so thanks again!!!

 

I'm glad I could help, Daphne, and that it has been a net win!

You mentioned that some of your sites use WP Rocket - if you haven't already, you could also exclude its cache dir from the backups as well. I believe its default cache folder is:

/wp-content/cache/

Might save a bit more space, though I'm not sure how much.

Anyway, great to hear that the disk space is under control