You keep marking my posts as “resolved”, so here is my 3rd post.
you can set the old post to “not resolved” š
I consider it “resolved” as I can only point to possible solutions and these pointers should allow you to resolve your problem really.
Why are there 20,000 files? I only have 1,500 posts on my site, so shouldn’t that match the maximum possible number of files in the Autoptimize cache?
because you have code (in your theme or more likely one or more plugins) that inserts new code (CSS or JS) in your HTML, which results in the cached autoptimized files not to be reused. the problem is not AO, but the fact that the JS or CSS changes, invalidating AO’s cache for that request.
possible solutions:
* either don’t aggregate inline CSS & JS
* or exclude the changing CSS or JS code from optimization
hope this clarifies,
frank
Thread Starter
qaws
(@qaws)
Okay I found something: Jetpack’s “Sharing” module puts the URL of the post into the javascript file (into the window.WPCOM_Sharing_counts variable), so Autoptimize is generating a different .js file for each post. This should still only generate a maxiumum of 1500 .js files if I only have 1500 posts?
Thread Starter
qaws
(@qaws)
I’ve added the string “window.WPCOM_Sharing_counts” to “Exclude scripts from Autoptimize” and when I view 3 posts in the Inspect view of Chrome, Autoptimize is using the same 2 CSS files and the same 1 js file across all 3 posts. This looks very promising.
I used the process on this page to identify which was the variable I needed. It was an inline variable generated by Jetpack, and has a different value in the js for every post.
OK, that should help. I’ll not mark this as resolved just yet š
Thread Starter
qaws
(@qaws)
Thanks. I’ve checked across a number of posts and pages and I’m getting good results – 2 css & 1 js shared across all the posts, 2 css & 1 js shared across the pages, and a different (but shared) set of css & js across the mobile version of the site.
I’ll mark this as resolved when I’m happy it’s behaving as expected.
It might be worth adding “window.WPCOM_Sharing_counts” into the default scripts to exclude, or at least into the docs somewhere – Jetpack is quite popular š
Thread Starter
qaws
(@qaws)
I’ve added the following to my “Exclude scripts from Autoptimize”:
- To fix the recaptcha code not running for Contact Form 7:
recaptchaCallback
- Jetpack installed (“Sharing” module):
window.WPCOM_sharing_counts
- Wordfence installed:
logHuman
If I empty my Autoptimize/W3TotalCache caches, then access a few of my posts, it doesn’t generate a js file for each one now. It looks like it’s generating 1 js for posts, another for pages, another set entirely for the mobile version of the site, and then the odd js file if the page contains obvious extra functions like youtube vids or embedded tweets. I’m expecting around 20-30 js files now, instead of the 5000 that it had generated since yesterday.
How does the “Exclude scripts from Autoptimize” function work? Does it just string find the entries listed in the “Exclude” box within each js it’s about to optimise, and exclude the js file if it finds a match? Does it have to be variable names, or can it also be things like DOM element names?
Additionally, WordPress has a ‘Compare’ feature built-in, when you are comparing post revisions. It would be really helpful if there was a way to use a comparison feature within Autoptimize, so users can compare similar CSS and JS files and discover which bits they need to exclude, without having to use custom tools to find which files need downloading, then finding a way to compare them, then finding how to fix it. This might solve lots of the “I have a really big cache, what do I do?” questions on this support forum, and make it easier for people to fix themselves.
Thanks for the help!
How does the “Exclude scripts from Autoptimize” function work? Does it just string find the entries listed in the “Exclude” box within each js it’s about to optimise, and exclude the js file if it finds a match? Does it have to be variable names, or can it also be things like DOM element names?
-> for files; the exclusion-string will be matched against the URL in the HTML
-> for inline code; the exclusion-string will be matched against the block of inline code (in which case a DOM element name might make sense indeed)
and thanks for the feedback and ideas š
frank
Thread Starter
qaws
(@qaws)
24 hours after making the changes, I only have 44 cached files totaling 18MB so I’m happy it’s working well now. I used to have 5000 files a day after emptying the cache. I’m thinking of writing up a short guide on how to find exclusions, so I will let you know.
Incidentally, what is the size limit that triggers the “cache might be getting too big” message?
Thanks for the help.
I’m thinking of writing up a short guide on how to find exclusions, so I will let you know.
great, I’ll happily link to it from the FAQ if you manage to explain things more clearly š
Incidentally, what is the size limit that triggers the “cache might be getting too big” message?
512MB, but beware the size calculation is somewhat … approximative š
frank
I don’t want to hijack this topic, but I have the same problems. It makes my server crash…
I have plusminus 1500 posts, but 6GB (!) of cached files. I don’t use jetpack, so don’t know how to fix this. Any ideas, gentlemen?
PS: it’s 6GB of cached CSS files only btw.
have a look at what I wrote earlier in this thread 1BJK903, applies to you as well š
Oh and don’t forget the FAQ! š
Yes, I understood that haha. The problem is that my page source is kind of fucked up if I don’t aggregate the CSS. Grrrr, dilemma. I love your plugin, I truly do, but not being able to drop the cache automatically after x days makes it very hard for me to keep using it.
Anyhow, I appreciate your help, this plugin and everything you do. You are a hero.
En dat meen ik. Dank.
The problem is that my page source is kind of fucked up if I don’t aggregate the CSS.
that’s merely an aesthetic problem for us geeks, no? whereas a non-optimized site OR a site which has an “exploding” cache are real problems?
not being able to drop the cache automatically after x days makes it very hard for me to keep using it.
well, easiest solution; don’t aggregate inline CSS, aesthetics be damned! š alternatively you could try to identify which CSS is causing the cache-tsunami and exclude just that from optimization.
and if you’re really into IT stuff; it’s pretty trivial to drop the cache every x days really, both on an OS-level (a small cronned script that removes wp-content/cache/autoptimize/*) or on a WP-level (approx. 5 lines of code to run autoptimizeCache::clearall() using wp-crong) š
frank
so qaws, how is your cache size these days? š
