I’m not a Gutenberg specialist (for from it, really) but:
the wrong way is adding JS with wp-block/ wp-element and other gutenberg dependencies on init calling wp_enqueue_script,
the right way is either hooking into enqueue_block_editor_assets (see https://jasonyingling.me/enqueueing-scripts-and-styles-for-gutenberg-blocks/)
or when using init doing wp_register_script and then register_block_type referring to the correct editor_script previously registered (see https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/block-tutorial/writing-your-first-block-type/).
I’ve tried both of these on a “bad” plugin and can confirm both solutions do prevent those needless wp-includes/js/dist/* JS-files from being added on the front-end.
So dear plugin-developer-friends; when adding Gutenberg blocks please differentiate between editor access and visitor access, only enqueue JS/ CSS if needed to display your blocks and when registering for front-end please please frigging please don’t declare wp-blocks, wp-element, … and all of those other editor goodies as dependencies unless your 100% sure this is needed (which will almost never be the case).
The performance optimization crowd will thank you for being considerate and -more likely- will curse you if you are not!
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!