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.
An “Autoptimize Critical CSS“-user saw some weirdness in how the site looked when optimized. The reason for this turned out to be not the critical CSS, but the fact that he used “Hide My WordPress Pro”, a plugin that changes well-known paths in WordPress URL’s to other paths (e.g. /wp-content/plugins -> /modules/ and /wp-content/themes -> /templates) and uses rewrite rules .htaccess to map requests to the filesystem. This resulted in Autoptimize not finding the files on the filesystem (as AO does not “see” the mapping in .htaccess), leaving them un-aggregated.
To fix something like that, a small code snippet that hooks into Autoptimize’s API can do the trick;
The above is just an example (as in the Pro version of hide-my-wp you can set paths of your own liking and you can even replace theme names by random-ish strings), but with a small amount of PHP-skills you should be able to work out the solution for your own site. Happy optimized hiding!