An epic 15 minutes of jazz from Kamasi Washington’s soul; “Truth”. I’ve been listening to this on repeat since I heard it yesterday evening on Lefto’s radioshow. So beautiful & moving, so rooted in the past and yet so fresh and timeless!
Thanks for using Autoptimize guys & girls, looking forward to providing you with the new version next month!
So work on Autoptimize 2.2 is almost finished and I need your help testing this version before releasing (targeting May, but that depends on you!). The more people I have testing, the faster I might be able to push this thing out and there’s a lot to look forward to;
- New option: enable/ disable AO for logged in users for all you pagebuilders out there
- New option: enable/ disable AO for cart/ checkout pages of WooCommerce, Easy Digital Downloads & WP eCommerce
- New minification/ caching system, significantly speeding up your site for non-cached pages (previously part of a power-up)
- Switched to rel=preload + Filamentgroup’s loadCSS for CSS deferring
- Additional support for HTTP/2 setups (no GUI, you might need to have a look at the API to see/ use all possibilities)
- Important improvements to the logic of which JS/ CSS can be optimized (getPath function) increasing reliability of the aggregation process
- Updated to a newer version of the CSS Minification component (albeit not the 3.x one, which seems a tad too fresh and which would require me to drop support for PHP 5.2 which will come but just not yet)
- API: Lots of extra filters, making AO (even) more flexible.
- Lots of bugfixes and smaller improvements (see GitHub commit log)
So if you want to help:
- Download the zip-file from Github
- Overwrite the contents of
wp-content/plugins/autoptimizewith the contents of
autoptimize-masterfrom the zip
- Test and if any bug (regression) create an issue in GitHub (if it doesn’t exist already).
Very much looking forward to your feedback!
Historically Autoptimize used its own JS-implementation to defer the loading of the main CSS, hooking into the domContentLoaded event and this has worked fine. I knew about Filament Group’s loadCSS, but saw no urgent reason to implement it as I saw no big advantages vs. my homegrown solution. That changed when criticalcss.com’s Jonas contacted me, pointing out that the best way to load CSS is now using the
rel="preload" approach, which as of loadCSS 1.3 is also the way loadCSS works;
<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
rel="preload" currently is only supported by Chrome & Opera (both Blink-based), a JS polyfill is needed for other browsers which uses loadCSS to load the CSS. Hopefully other browsers catch up on
rel="preload" because it is a very elegant solution which allows the CSS to load sooner then with the old code while still being non-render blocking. What more could one which for (“Unicorns” my 10yo daughter might say, but what does she know)?
Anyways; I have integrated this new approach in a separate branch on GitHub, you can download the zip-file here to test this and all the other fixes and improvements since 2.1.0. Let me know what you think. Happy preloading!
After the PR-beating WordPress took with the massive defacements of non-upgraded WordPress installations, it is time to revisit the point-of-view of the core-team that the REST API should be active for all and that no option should be provided to disable it (as per the decisions not options philosophy). I for one installed the “Disable REST API” plugin.