The next version of Autoptimize (2.9.2) will allow you to add any post/ page to the critical CSS job queue, so no need to patiently await the job to appear any more:
Once in the queue you have the “process jobs manually” button to push to get the critical CSS juice flowing.
- New: per page/ post Autoptimize settings so one can disable specific optimizations (needs to be enabled on the main settings page under “Misc Options”).
- New: “defer inline JS” as sub-option of “do not aggregate but defer” allowing to defer (almost) all JS
- Improvement: Image optimization now automatically switches between AVIF & WebP & Jpeg even if lazyload is not active (AVIF has to be explicitly enabled).
- Misc. other minor fixes, see the GitHub commit log
This release coincides with my father’s 76th birthday, who continues to be a big inspiration to me. He’s a mechanical engineer who after retirement focused his technical insights, experience and never-ending inquisitiveness on fountain pen design and prototyping, inventing a new bulkfiller mechanism in the process. Search the web for
Fountainbel to find out more about him (or read this older blogpost I wrote in Dutch). Love you pops!
Quick public service announcement; Autoptimize 2.9 is almost ready to be released but given the planned release of WordPress 5.8 (July 20th) and the risk of support requests mixing up WordPress core update related issues with the Autoptimize update related issues, Autoptimize 2.9 will probably be released one week after WordPress 5.8, so on or around Tuesday 27th.
If you’re eager to use 2.9 (with better image optimization, improved JS optimization and per page/ post Autoptimize settings) you can off course download the beta here immediately.
I just upped Autoptimize 2.9 beta to version 4, which is likely to be the last version before the official 2.9 release (eta end June/ early July).
Main new features;
- defer all JS (also inline)
- nextgen images without lazyload
- per page/post settings
- misc. bugfixes and smaller improvements
You can download the beta from Github (do disable 2.8.x before activating 2.9-beta-4) and you can log any issues/ bugs over at https://github.com/futtta/autoptimize/issues
Looking forward to your feedback!
So we have per post/ page AO settings and we now have “also defer inline JS” for what will become 2.9. And there’s more to come …
I’m in the process of adding a per page/ post option to disable Autoptimization.
In the current state of this work in process one can disable Autoptimize entirely on a post/ page or disable just JS optimization as you can see on the screenshot.
Now my question to you, Autoptimize user, is; what other options of below list _have_ to go in that metabox taking into account the list should be between 3 and 5 items long?
- CSS optimization (which includes Critical CSS)
- Critical CSS usage/ Inline & defer CSS
- HTML optimization
- Image optimization
- Image Lazyload
- Google Font optimization
- Preload (from “extra” tab)
- Preconnect (from “extra” tab)
- Async (from “extra” tab)
This morning I finally pushed Autoptimize 2.8.2 out of the gates which was a relatively minor release with misc. small improvements/ bugfixes. Only it proved not that minor as it broke some sites after the update, so here’s a quick postmortem.
- 7h33 CEST: I pushed out 2.8.2
- 7h56 CEST: first forum post about a Fatal PHP error due to
- 7h58 CEST: second forum post confirming issue
- 8h01 CEST: responded to both forum posts asking if file was indeed missing on filesystem
- 8h04 CEST: I changed the “stable version” back to 2.8.1 to stop 2.8.2 from being pushed out.
- 8h07 CEST: forum post replies confirming the file was indeed missing from the filesystem
- 8h15 CEST: I pushed out 2.8.3 with the fix
- 8h22 CEST: confirmed fixed by first user
- 8h26 CEST: confirmed fixed by second user
Root cause analysis
One of the improvements was changing the classname of the HTML minifier to avoid W3 Total Cache’s HTML minifier being used. For this purpose not only small changes were made to the HTML minifier code, but the file was also renamed from
ao-minify-html.php. The file itself was present on my local filesystem, but I did *not*
svn add it, so it was never propagated to the wordpress.org SVN server, resulting in it not being in the 2.8.2 zip-file causing the PHP Fatal “require(): Failed opening required” errors.
svn ci has be proceeded by an
svn stat, always. I’ve updated my “go live” procedure to reflect that.
Additionally; I strongly advise against automatic updates for Autoptimize (and I don’t auto-update any plugin myself), not only for major f-ups like mine today, but also because any change to how (auto-)optimization works needs to be tested for regressions. And if you have a site that generates money somehow, you really should have a staging site (which can auto-update) to test updates on before applying on production.
So here is a very quick rundown of 3 such alternatives:
- Gravity Forms: premium-only, visual form builder, very flexible, big ecosystem (lots of 3rd party plugins & integrations)
- Formidable Forms: has a free Light version, drag & drop interface for building forms, very flexible (we currently use this on autoptimize.com), lots of integrations but smaller ecosystem.
- HTML Forms: free plugin from the team that also develops “Koko Analytics” (which I now use on all my sites) and “Mailchimp for WordPress” with a premium addon for extra features, similar to Contact Form 7, no frills, very light on JS so great for performance.
My advice; try HTML Forms if you have rather standard contactform-like forms and you’re not looking for something fancy (which CF7 is not either), try Formidable if you need drag & drop form building or if you (will) need more flexibility/ integrations.
wp-includes/js/dist the comma-separated JS optimization exclusion list (or in some cases even
It is nice CF7 gets rid of the jQuery dependancy, but I’m not sure is replacing that with a significant amount of extra WordPress blocks JS-files was such a good idea?
Update: additionally the change also introduces nonces (random password-like strings as hidden elements in the form) which can spell serious trouble when using page caching plugins.
Up until now Autoptimize, when performing image optimization, relies on JS-based lazyloading (with the great lazysizes component) to differentiate between browser that support different image formats (AVIF, WebP and JPEG as fallback).
As JS-based Lazyload is going out of fashion though (with native lazyload being supported by more browsers and WordPress having out-of-the-box support for it too), it is time to start working on