Evening gmcinnes;
Autoptimize generates new cached files every time it detects even the slightest difference with what has been cached already (even 1 character difference will do). Differences between pages can occur because some plugins will only inject css and/ or js only when they are active on that particular case. Also the CSS/ JS loaded for logged in users (you) is (slightly) different from what anonymous visitors see. If you feel there are too many files there, you could always try to go through your site (as anonymous user) and compare the files between pages/ posts/ archives and try to exclude the non-generic JS or CSS from optimization (or even use the whitelist-functionality that is available via the API).
Now if some users report unstyled pages, that is a whole other issue, obviously. Have you encountered these yourself as well? Is the autoptimized CSS-file missing (404) or corrupt? Do you have links you could share where this would be the case?
frank
First, Frank, you deserve huge kudos and thanks for being so amazing at support. It’s very rare for even *paid* plugins to have the level of support you provide for free.
I haven’t seen these issues myself. They’re transient even for people who are experiencing them. I don’t have a consistent reproduction case yet.
Given what you said, am I right in thinking that there would be an autoptimize css file for each *page* that has slightly different css, and that those files wouldn’t change unless the underlying css for one of those pages does?
am I right in thinking that there would be an autoptimize css file for each *page* that has slightly different css, and that those files wouldn’t change unless the underlying css for one of those pages does?
that is correct. this can even become a real problem if, when aggregating inline JS (or CSS, but that’s less likely), there is ‘random’ code added (e.g. nonce’s). that can cause a new autoptimized file being created over and over, which can slow down page performance and “explodes” the cache in which case one should either exclude such “cache-busting” code from aggregation or simply disable aggregation of inline JS (or CSS). more info in the FAQ, off course 🙂
frank
Ok Frank. That’s good to know. I won’t bother aggregating the inline assets. It’s not worth the extra problems.
I have another question: I seem to have a problem getting jQuery into the aggregation. Most everything else depends on it, so I need to make sure it gets into the aggregated file first. Is there any way to control the order of the files in the aggregation?
Is there any way to control the order of the files in the aggregation?
well, autoptimize aggregates in the exact order things are found, so -on condition you aggregate everything, inline JS included- this should be OK.
if you’re not aggregating inline JS (and/ or excluding some non-inline JS), then you might have to “force JS into head” (so your autoptimized JS with jquery is loaded early) or alternatively simply exclude jquery.js from optimization.
frank
