I just pushed out an update of the Autoptimize 2.4 beta branch on GitHub, with this in the changelog;
- new: Autoptimize “listens” to page caches being cleared, upon which it purges it’s own cache as well. Support depends on known action hooks firing by the page cache, supported by Hyper Cache, WP Rocket, W3 Total Cache, KeyCDN Cache Enabler, support confirmed coming in WP Fastest Cache and Comet Cache.
- new: Google Fonts can now be “aggregated & preloaded”, this uses CSS which is loaded non render-blocking
- improvement: “remove all Google Fonts” is now more careful (avoiding removing entire CSS
We’re still looking for beta-testers and some of these new features might convince you to jump on board? You can download the zip-file here, installing it a simple one-time process:
- Deactivate Autoptimize 2.3.x
- Go to Plugins -> New -> Upload
- Select the downloaded zipfile and upload
- Click activate
- Go to Settings -> Autoptimize to review some of the new settings
In case of any problem; we’re actively looking for feedback in the GitHub Issue queue :-)
Autoptimize 2.3.3 was just released. It is a minor release with the following minor improvements & fixes:
- improvement: updated to latest version of Filamentgroup’s loadCSS
- improvement: by default exclude
wp-content/uploads from CSS optimization (Divi, Avada & possibly others store page-specific CSS there)
- bugfix: stop double try/catch-blocks
- misc. bugfixes (see GitHub commit log)
This is (supposed to be) the last minor release of the 2.3 branch, 2.4 is a major change with some big under-the-hood and functional changes. That new version has been in the works for some months already and if you’re up for it you can install by simply downloading this zip-file from GitHub. The GitHub version will also auto-update thanks to the great Plugin Update Checker library.
- integrate all “pro” features (that’s right, free for all)
- include some rewritten code for easier maintenance
- be fully i18n-ready (lots of strings to translate :-) )
I will provide support on the wordpress.org forum (be patient though, I don’t have a deep understanding of code, functionality & quirks yet). I also have some more fixes/ smaller changes/ micro-improvements in mind (well, a Trello-board really) for the next release, but I am not planning major changes or new functionality. But I vaguely remember I said something similar about Autoptimize a long time ago and look where that got me …
Anyway, kudo’s to David for a great plugin with a substantial user-base (over 30K active installations) and for doing “the right thing” (as in not putting it on the plugin-market in search for the highest bidder). I hope I’ll do you proud man!
Over 3 years ago Autoptimize added support for critical CSS and one and a half year ago the first “power-up” was released for Critical CSS rules creation.
But time flies and it’s time for a new evolution; automated creation of critical CSS, using a deep integration with https://criticalcss.com using their powerful API! A first version of the plugin is ready and the admin-page looks like this (look to the right of this paragraph);
- beta-test (asap)
- release as separate plugin on wordpress.org (shooting for April)
- release as part of Autoptimize 2.5 (target mid 2018)
This new “criticalcss.com” power-up has been tested on a couple of sites already (including this little blog of mine) and we are now looking for a small group of to help beta-test for that first target. Beta-testers will be able to use criticalcss.com for free during the test (i.e. for one month). If you’re interested; head on up to the contact form and tell me what kind or site you would test this on (main plugins + theme; I’m very interesting in advanced plugins like WooCommerce, BuddyPress and some of the major themes such as Avada, Divi, Astra, GeneratePress, … ) and I’ll get back to you with further instructions.
[UPDATE 29/03/2018: Autoptimize 2.4 can now be downloaded from https://github.com/futtta/autoptimize/archive/beta.zip and will automatically update so ensure all new functionality and fixes are applied]
TL;DR Autoptimize 2.4 will be a major change. Tomaš Trkulja (aka zytzagoo) has cleaned up and modernized the code significantly, making it easier to read and maintain, switched to the latest and greatest minifiers and added automated testing. And as if that isn’t enough we’re also adding new optimization options! The downside: we will be dropping support for PHP < 5.3 and for the “legacy minifiers”. AO 2.4 will first be made available as a separate “Autoptimize Beta” plugin
on wordpress.org via GitHub and will see more releases/ iterations with new options/ optimizations there before being promoted to the official “Autoptimize”.
Back in March 2015 zytzagoo forked Autoptimize, rewriting the CDN-replacement logic (and a lot of autoptimizeStyles::minify really) and started adding automated testing. I kept an eye on the fork and later that year I contacted Tomas via Github to see how we could collaborate. We have been in touch ever since; some of his improvements have already been integrated and he is my go-to man to discuss coding best practices, bugfixes and security.
FFWD to the nearby future; Autoptimize 2.4 will be based on Tomaš’ fork and will include the following major changes:
- New: option only minify JS/ CSS without combining them
- New: excluded JS- or CSS-files will be automatically minified
- Improvement: switching to the current version of JSMin and -more importantly- of YUI CSS compressor PHP port which has some major performance-improvements of itself
- Improvement: all create_function() instances have been replaced by anonymous functions (PHP 7.2 started issuing warnings about create_function being deprecated)
- Improvement: all code in autoptimize/classlesses/* (my stuff) has been rewritten into OOP and is now in autoptimize/classes/*
- Improvement: use of autoload instead of manual conditional includes
- Improvement: a nice amount of test cases (although no 100% coverage yet), allowing for Travis continuous integration-tests being done
- dropping support for PHP below 5.3 (you really should be on PHP 7.x, it is way faster)
- dropping support for the legacy minifiers
These improvements will be released in a separate “Autoptimize Beta” plugin soon (albeit not on wordpress.org as “beta”-plugins are not allowed). You can already download from GitHub here. We will start adding additional optimization options there, releasing at a higher pace. The goal is to create a healthy Beta-user pool allowing us to move code from AO Beta to AO proper with more confidence. So what new optimization options would you like to see added to Autoptimize 2.4 and beyond? :-)
[corrected 19/02; wordpress.org does not allow beta-plugins]
In general i rarely bother looking into WordPress core code or what’s on the horizon. The last month or so however I came across 3 problems that were due to core.
1. Shortly after pushing Autoptimize 2.3.x out, a subset of users started complaining about a flood of “cachebuster”-requests bringing their site to a crawl. It turned out all of them were using Redis or Memcached and that due to a longstanding bug in WordPress core Autoptimize did not get the correct version-string from the database, triggering the update-procedure over and over, purging and then preloading the cache. A workaround -involving a transient featuring my wife and daughter- was introduced to prevent this, but “oh my gawd” what an ugly old WordPress core bug that is! Can someone please get this fixed?
2. A couple of users of WP YouTube Lyte noticed their browsers complaining about unbalanced tags in the Lyte HTML output (which is part of the_content). It took me a lot of time to come to the conclusion that WordPress core’s wpautop was messing things up severely due to the noscript and meta-tags in Lyte’s output. As wpautop has no filters or actions to alter the way it works, I ended up disabling wpautop when lyte’s were found in the_content.
3. My last encounter was with the ghost of WordPress Yet-to-come; Gutenberg … To allow WP YouTube Lyte to turn Gutenberg embedded YouTube’s into Lyte’s, it turned out I had to dive into the tag soup that Gutenberg adds as HTML-comments to the_content. I have yet to find documented functions to extract the information the smart way, so regexes to the rescue. But any plugin that hooks into the_content better be aware that Gutenberg (as part of WordPress 5.0) will potentially mess things up severely.
Although I cursed and sighed and I am now complaining, I felt great relief when having fixed/ worked around these issues. But working in the context of a large and successful open source software project and depending on it’s quality can sometimes almost be a pain as much as it is a joy. Almost … ;-)
So Steve Stern likes to yank my chain I the wordpress.org support forums :-)