Proposal: stronger default settings about autoptimize HOT 9 CLOSED

Hey @adamsilverstein :-)

Thanks for your input! I do agree that in an ideal world it would be better to have JS, CSS & HTML opt. on by default except ... when things break (which esp. for JS opt. is a risk).

Directing users to the settings page through the notification after activating (see screenshot below) "teaches" them they can activate and deactivate specific options. Without that first interaction with the settings page I fear most people will simply uninstall Autoptimize as soon as the JS optimization breaks something.

That being said; typically HTML & CSS opt. with the default sub-settings are pretty safe, so we could enable those by default and in the notification point to the settings page to also enable JS optimization maybe?

What do you think? :-)

from autoptimize.

well, thinking about JS; we could enable it by default if we sub-options like "aggregate" or "don't aggregate but defer" off? that way unminified JS is minified and the risk of issues is (very) small?

disadvantage; users will have to choose between "aggregate" and "dont aggregate but defer" themselves, whereas the latter is default in the current setup?

re. stack packs; very interesting, will most certainly look into that, thanks!

from autoptimize.

Hey @futtta - thanks for the response (which I just saw now) -

except ... when things break (which esp. for JS opt. is a risk).

Ah yes, this was what I expected your reasoning for having things disabled was.

That being said; typically HTML & CSS opt. with the default sub-settings are pretty safe, so we could enable those by default and in the notification point to the settings page to also enable JS optimization maybe?

Excellent to hear that! I do think starting with the "safer" HTML and CSS optimizations enabled by default makes sense, and I will adjust my PR to change only those defaults.

Changing the notification as well makes sense, although I suspect many people might miss that message - I know I did!

I do have another idea though for a touchpoint where you could inform your users about enabling the JavaScript features though: Lighthouse Stack Packs. These allow you to provide technology specific recommendations (based on Wappalyzer where Autoptimize is already recognized), so Autoptimize can have its own Stack Pack where you tell users what action they should take for each specific Lighthouse audit violation - eg telling them to enable JS features for the appropriate audits. Hopefully this would also help reduce your support burden, a couple of other optimization plugins are already leveraging this to help their users.

from autoptimize.

I updated my PR to change only the HTML & CSS optimization defaults.

I didn't change the notification after activating in the PR, only the defaults, what do you think?

from autoptimize.

well, thinking about JS; we could enable it by default if we sub-options like "aggregate" or "don't aggregate but defer" off? that way unminified JS is minified and the risk of issues is (very) small?

My personal take is that you should enable as much as possible by default since most users a. won't check or change defaults and b. won't know the best settings for their site. That said, I agree it is good to avoid having default features that have some likelihood of breaking the site functionality. So I think we could enable JS optimizations with "Do not aggregate but defer" and then point users to "aggregate" option if useful.

from autoptimize.

well, thinking about JS; we could enable it by default if we sub-options like "aggregate" or "don't aggregate but defer" off? that way unminified JS is minified and the risk of issues is (very) small?

@futtta - I changed the defaults as you suggest here in this commit: e234273 (#404) - feel free to take or revert that bit!

from autoptimize.

just merged @adamsilverstein , thanks for insisting! I'll likely be brave and even enable "defer JS" by default, I can always backtrack if this results in too much breakage.

from autoptimize.

just merged @adamsilverstein , thanks for insisting! I'll likely be brave and even enable "defer JS" by default, I can always backtrack if this results in too much breakage.

🎉 woohoo, thanks for approving! hopefully you will see new sites that install the plugin have a stronger performance boost, it might even be discernible in the CrUX dataset.

ps. What tends to break with the defer feature? Have you seen the new Script API strategy feature we landed in WordPress core in 6.3? this new approach to adding defer considers dependencies so scripts load order don't break as easily (if another script depends on a script you try to defer and isn't deferrable itself, the script doesn't get deferred).

Does the current feature try to defer all scripts? maybe you could consider using the core feature if available (ie add the 'defer' strategy to enqueued scripts) as a "safer" default option? let me know what you think!

from autoptimize.

going through my backlog in the lul between Christmas & New Years Adam :-)

AO will try to defer everything, linked JS, inline JS, with or without the data-wp-strategy attribute.

The good news; I have not seen an uptick in support tickets, so the change might be working well. On the other hand; a lot of "how to's" for AO still recommend to aggregate JS, in which case the defaults don't apply any more ..

from autoptimize.