performance

Autoptimize 2.7; final stretch, testers needed!

by

Autoptimize 2.7 is in the final stages and the beta version can as of now be downloaded from https://downloads.wordpress.org/plugin/autoptimize.zip
Main new features:

So who want to test? Feedback in the comments please! 🙂

Autoptimize 2.7 with Critical CSS integrated, beta out

by

The title says it all; I just pushed the first beta of Autoptimize 2.7 which has some small fixes/ improvements but which most importantly finally sees the “Autoptimize CriticalCSS.com power-up” fully integrated.

Next to the actual integration and switching to object-oriented for most (but not all) of AOCCSS files, there are some minor functional changes as well, most visible ones being buttons to clear all rules and to clear all jobs from the queue.
I hope to be able to release AO27 officially in April, but for that I need the beta thoroughly tested off course. Most important part to test is the critical CSS logic obviously, so if you have the power-up running, download/ install the beta and simply disable the power-up to have Autoptimize fill that void (if the power-up is active, AO refrains from loading it’s own critical CSS functionality).

Autoptimize 2.6 released

by
I just released AO26, which comes with a bunch of new features, improvements and bugfixes.
  • New: Autoptimize can be configured at network level or at individual site-level when on multisite.
  • Extra: new option to specify what resources need to be preloaded.
  • Extra: add display=swap to Autoptimized (CSS-based) Google Fonts.
  • Images: support for lazyloading of background-images when set in the inline style attribute of a div.
  • Images: updated to lazysizes 5.2.
  • CSS/ JS: no longer add type attributes to Autoptimized resources.
  • Improvement: cache clearing now also integrates with Kinsta, WP-Optimize & Nginx helper.
  • Added “Critical CSS” tab to highlight the criticalcss.com integration, which will be fully included in Autoptimize 2.7.
  • Batch of misc. smaller improvements & fixes, more info in the GitHub commit log.

The release has been tested extensively (automated unit testing, manual testing on several of my own sites and testing by users of the beta-version on Github), but as with all software it is very unlikely to be bug-free. Feel free to post any issue with the update here or to create a separate topic in this forum.
Happy holidays to all!
frank

Autoptimize closing in on W3 Total Cache

by

Fun fact; As per wordpress.org “popular plugins” ranking , Autoptimize is slowly but surely closing in on what used to be the go-to solution for Web Performance Optimization W3 Total Cache based on the “active installs” metric. Who would have thought? What a crazy ride …

We just joined the club!

by

Autoptimize just joined the “1+ million active installs”-club. Crazy!

I’m very happy, thanks everyone for using, thanks for the support-questions & all the great feedback therein and especially thanks to the people who actively contributed and especially-especially to Emilio López (Turl) for creating Autoptimize and handing it over to me back in 2013 and to Tomaš Trkulja who cleaned up al lot of the messy code I added to it and introducing me to PHP codesniffer & Travis CI tests.

Google Font display swap in Autoptimize?

by

Autoptimize 2.5.1 (out earlier this week) does not have an option to enforce font-display on Google Fonts just yet, but this little code snippet does exactly that;

add_filter('autoptimize_filter_extra_gfont_fontstring','add_display');
function add_display($in) {
  return $in.'&display=swap';
}

Happy swapping (or fallback-ing or optional-ing) 🙂

Developers: don’t make Gutenberg go Badass-enberg on my frontend!

by

Over the past couple of months, since the release of WordPress 5.0 which includes Gutenberg, the new JavaScript-based block editor, I have seen many sites loading a significant amount of extra JavaScript from wp-includes/js/dist on the frontend due to plugins doing it wrong.
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!