the limit is set at half a GB, but you can change that using the autoptimize_filter_cachecheck_maxsize-filter.
do take into account that a huge cache (even if you have a lot of disk spare space) means there is not a lot of re-use of optimized JS, meaning your users will:
(a) have to load different JS (or CSS)-files while surfing your site and
(b) they might face slowdowns if the JS (or CSS) is not cached yet and hence has to be minified (minification is relatively expensive)
hope this clarifies,
frank
Thread Starter
luffer
(@luffer)
I’ve had to use the “Inline all CSS” option which may be causing a large cache?
I wanted to use the “Inline and Defer CSS” option, but when I enabled that option and entered my above the fold CSS the site would fail and return a 404 error when I saved.
no, inline all CSS does not generate a bigger cache really. typically the “also aggregate inline JS” (and occasionally “also aggregate inline CSS”) is the root cause of cache size issues.
while we’re talking; might I ask you to mark AO 2.1 as compatible with WordPress 4.6 here (if you consider it compatible that is)? 🙂
frank
Thread Starter
luffer
(@luffer)
Well it does give a 404 error when I try and use Inline and Defer CSS.. so is it?
good question 😉
do you get the 404 immediately when submitting the autoptimize settings-screen, or do you get a 404 when having enabled “inline & defer” in wp-admin and going to the frontend?
and is this a fresh 2.1 install or did you upgrade from 2.0.2?
Thread Starter
luffer
(@luffer)
I only get a 404 error when I try to save with the “inline & defer” option enabled. I never get a 404 on my frontend, it’s just in the admin area.
Where do you redirect users to when they hit the “save” button that’s different with the “inline and defer” option enabled?
This is an upgrade, but a fairly recent install. Only been using it about a week.
Where do you redirect users to when they hit the “save” button that’s different with the “inline and defer” option enabled?
that’s the thing; it’s the exact same form submit … could you have some software (mod_security or something similar) that is checking incoming requests and blocking in some cases?
This is an upgrade, but a fairly recent install. Only been using it about a week.
and did you have the inline&defer problem on 2.0.2 as well?
Thread Starter
luffer
(@luffer)
that’s the thing; it’s the exact same form submit … could you have some software (mod_security or something similar) that is checking incoming requests and blocking in some cases?
I use Theme My Login which blocks access to wp-login.php but nothing else that I know of.
and did you have the inline&defer problem on 2.0.2 as well?
Yes
in that case; have a look at your apache (or nginx or IIS or whatever webserver you’re on) access- and error-files and at your php-errorlog. something (probably on your server) is blocking the submit of the ao_settings when critical CSS is entered. and maybe ask your hoster if they have mod_security running? you could also try if submitting with a{b:c;} works?
A similar problem in this thread, where the author was able to identify this CSS as causing the post error:
@font-face {
font-family: dashicons;
src: url(//aoxoa.co/wp-includes/css/../fonts/dashicons.eot);
}
my hunch is that the /../, is causing a silly web app firewall to think this is a directory traversal firewall. does your critical css have something like that?
