you’re on 2.1.1 I guess, upgrade to either 2.2 (released today) or 2.1.2 (https://downloads.wordpress.org/plugin/autoptimize.2.1.2.zip) to fix.
frank
Anonymous User 11660062
(@anonymized-11660062)
Overall a great plugin….
FYI: I am running version 2.2.1 and the cache behavior is still not fixed. You may want to look into why this is the case.
-
This reply was modified 9 years, 1 month ago by
Anonymous User 11660062.
hey @pateljxgmailcom;
some questions:
* how many files/ cache size are we talking about here?
* can you check the number of files in wp-content/cache/autoptimize/js vs wp-content/cache/autoptimize/css?
* what are your Autoptimize settings, esp. “also aggregate inline”-js/css ?
* can you share your URL?
frank
Anonymous User 11660062
(@anonymized-11660062)
Hello Frank,
Here is my URL: https://visualwilderness.com/ (I have similar issue on my other two websites: http://jaypatelphotography.com/, http://photographybyvarina.com/. However the cache growth is slower as the traffic to this site is much lower).
My website uses about 31 JS and about 25 css. Not all of them will be compressed. There are currently 53 JS and 71 CSS Files in the cache folders (I just cleaned the cache few minutes ago).
Settings
JS – All boxes unchecked except for Optimize JavaScript Code?
CSS – All boxes unchecked except for Optimize CSS Code? & Also aggregate inline CSS?
Anonymous User 11660062
(@anonymized-11660062)
Frank,
One more data point…I had upgraded from 2.1.1 to 2.2.1. I just uninstalled and re-installed the plugin…and monitoring it now. Will keep you posted as to what happens.
Anonymous User 11660062
(@anonymized-11660062)
Does not look good. Here is the results after about 100 minutes of run time.
Cache Size: 297.79 MB (59% Full)
CSS Files in Cache Directory: 414
JS Files: 60
At this rate, the cache will be full in couple of hours. I am going to disable the plugin until we find a fix for this issue.
Let me know if you need anything else via email.
@pateljxgmailcom maybe don’t disable, but untick “also aggregate inline CSS” as the problem seems to be specific to CSS optimization?
Anonymous User 11660062
(@anonymized-11660062)
I can certainly run a test like this…and report back to you to see how it works.
I have read your blog about the issue with cache refresh/invalidation and I understand why it grows and why it is not quite as easy to invalidate this, however from usability point you can offer better tools to make the implementation a bit easier. Is any of these possible?
-Include a debug mode that compares current and last version of ALL CSS/JS files that are minimized. And then generate a report on which files are changed that required generation of new cache entry. And this can be excluded manually or automatically to tune the system.
-Cache purge based on time stamp? Why not set cache-expire parameter for CSS/JS that are optimized by the AO…and then expire all cache entries older then this? So, I can set cache-control:public, max-age=86400 for ALL CSS files and then any cache file older then 1 day expires? If this is possible let the users choose the default value of cache expiration.
Thanks.
debug mode; could quickly become _very_ complex, not sure I’m up for that. but if you want to contribute, yes please 😉
cache purge on timestamp; problem is with HTML (in your own cache or in a caching reverse proxy or in a browser cache) which still refers to autoptimized CSS/JS that would be deleted after one day; all those break if the AO’d files aren’t available any more. additionally from a perf. point of view you want your max-age to be as big as possible, one day would be sub-optimal.
frank
Anonymous User 11660062
(@anonymized-11660062)
I would love to contribute….but my coding skills are not quite as good as what they used to be.
If AO files are not available they should be regenerated for Cache? Sure this will take a hit in the performance, but it will make the plugin hands off. While I do agree that 1 day is not optimal…that was just an example.
Update: After turning of the inline CSS Aggregation, the growth of the cache has slowed down. I will keep an eye on it and see it does not get out of hand..
If AO files are not available they should be regenerated for Cache?
that’s not possible; AO builds the files on-the-fly and injects them in the cached HTML. if the static files don’t exist, AO doesn’t even know about that, it’s just the webserver that gives a 404. moreover AO does not keep a table with a list of all CSS/ JS per page, so even if AO would know it still would not be able to re-generate the CSS/ JS without re-parsing the HTML (which it gets by hooking into wordpress, but wordpress might not even get triggered for a page from cache).
Update: After turning of the inline CSS Aggregation, the growth of the cache has slowed down. I will keep an eye on it and see it does not get out of hand..
that’s great news! you should see cache size stabilizing after a couple of hours.
frank
