Update 4th Feb: the HTML minify bug was fixed in W3TC v. 0.9.7.2, released a couple of days ago.
Update 19th Feb: I’m still seeing issues caused by W3TC, seems like not all is fixed fully yet.
Quick heads-up for users that have both W3 Total Cache and Autoptimize installed; the latest W3TC update (version 0.9.7.1) introduces a nasty bug in the HTML minifier which also impacts Autoptimize as that uses the same minifier class (Minify_HTML, part of Mr. Clay’s Minify). When W3TC is running the Minify_HTML class is loaded by and from W3TC, meaning AO’s autoload does not have to load the Minify_HTML from AO proper (which does not have that problem).
2018 is end of life and 2019 will be released soon. Autoptimize 2.5 is not at that point yet, but I just pushed a version to GitHub which adds image lazy loading to Autoptimize;
The actual lazy-loading is implemented by the integrated lazysizes JS lazy loader which has a lot of options some of which I will experiment with and bring to Autoptimize to the default improve user experience.
If you want you can download the beta (2.5.0-beta2) now from Github (disable 2.4.4 before activating the beta) and start using the new functionality immediately. And if you have feedback; shoot, I’ll be happy to take your remarks with me to bring AO 2.5 ready for release (I’m targeting March, but we’ll see).
Autoptimize by default excludes inline JS and jquery.js from optimization. Inline JS is excluded because it is a typical cache-buster (due to changing variables in it) and as inline JS often requires jQuery being available as a consequence that needs to be excluded as well. The result of this “safe default” however is that jquery.js is a render-blocking resource. So even if you’re doing “inline & defer CSS” your Start-Render time (or one of the variations thereof) will be sub-optimal.
Jonas, the smart guy behind criticalcss.com, proposed to embed inline JS that requires jQuery in a function that executes after the DomContentLoaded event. And so I created a small code snippet as a proof of concept which hooks into Autoptimize’s API and that seems to work just fine; The next step is having some cutting-edge Autoptimize users test this in the wild. You can view/ download the code from this gist and add it as a code snippet (or if you insist in your theme’s functions.php). Your feedback is more then welcome, I’m sure you know where to find me!
Concerning the very short-notice release-announcement of WordPress 5.0 with Gutenberg for Dec 6th: I’m with Yoast;He has a great “should I update”-checklist and conclusion in this blogpost;
Is now the right time to update?
Can your site work with Gutenberg?
Do you need it?
So our advice boils down to: if you can wait, wait.
So if you have a busy end-of-year, if you’re not 100% sure your site will work with Gutenburg or if you don’t really need Gutenberg in the first place; wait (while WordPress 5.0 stabilizes with some minor releases).
A heads-up to Autoptimize users who are using Divi (and potentially other Elegant Theme’s themes); as discovered and documented by Chris, Divi purges Autoptimize’s cache every time a page/ post is published (or saved?).
To be clear; there is no reason for the AO cache being cleared at that point as:
A new page/ post does not introduce new CSS/ JS
Even if new CSS/ JS would be added somehow, AO would automatically pick up on that and create new optimized CSS/ JS.
Chris contacted Divi support to get this fixed, so this is in the ticketing queue, but if you’re using Divi and encounter slower saving of posts/ pages or Autoptimized files mysteriously disappearing then his workaround can help you until ET fixes this.