Technology

Blogposts on blog.futtta.be about internet, web developement, browsers, security, linux, …

Autoptimize troubleshooting howto

by

Autoptimize can help improve your site’s performance, but in some cases after installing and activating you might encounter issues with your site. Although frustrating and maybe even scary, these problems can generally be easily resolved by re-configuring Autoptimize and I’ll be happy to share how you can do that.

First off: if the problem is limited to just one (or two) page(s), go to that page’s edit screen and in the “Autoptimize this page” metabox simply disable “optimize this page” and forget about it (or if you want to be more specific you candisable just “optimize JS” or “optimize CSS” or “lazyload images” or …).

If the problem is more widespread, then try to identify what is breaking things by just disabling CSS or JS or HTML or Image optimization (incl. lazyload). Keep in mind you might have to clear your page cache after a configuration change (depending on your setup this might be a page caching plugin or on the server or at host level or at a 3rd party such as Sucuri or Cloudflare).

If the problem goes away by disabling CSS optimization, reactivate it and

  1. If “aggregate CSS” and “also aggregate Inline CSS” are on, first try disabling “also aggregate inline CSS” and if still broken try also disabling “aggregate CSS”
  2. Try adding wp-content/themes to exclude the theme CSS from being optimized
  3. Try adding wp-content/plugins to exclude all plugins CSS from being optimized, if that works you can try narrowing it down further by excluding specific plugins e.g. wp-content/plugins/elementor

If the problem goes away by disabling JS optimization, reactivate it and

  1. Check the browser console for relevant JavaScript errors (see this wordpress.org support article for info on how to do that)
  2. If you see “jQuery is not defined“-errors on the browser console, make sure wp-includes/js/jquery/jquery.min.js is not aggregated (add it to the JS optimization exclusion field) or asynced/ deferred in any way.
  3. If “aggregate JS” is active, try switching to “don’t aggregate but defer”, optionally with “also defer inline JS” on as well (in which case you can likely remove at least the default exclusions).
  4. Try adding wp-content/themes to exclude the theme JS from being optimized
  5. Try adding wp-content/plugins to exclude all plugins JS from being optimized, if that works you can try narrowing it down further by excluding specific plugins e.g. wp-content/plugins/elementor (example in screenshot above: koko to exclude all Koko Analytics JS)

Image optimization or lazyload issues can be fixed by excluding the image(s) from those optimizations by either excluding (part) of the image path (e.g. wp-content/uploads/2022/10/whatever.jpg) or if the <img tag has a e.g. class attribute excluding by class-name (e.g. img-fancybox-hidden).

If the problem is with HTML minification, just keep that off, it’s not very important. Obviously, if you have some of the options on the “Extra” tab active, try deactivating them one by one.

If all of the above fails, there is always free quality support offered over on the wordpress.org Autoptimize support forums! 🙂

Autoptimize 3.0 almost done, want to test?

by

Work on Autoptimize 3.0 is almost finished and it has some big changes both functionally and technically;

  • fundamental change for new installations: by default Autoptimize will not aggregate JS/ CSS any more (HTTP/2 is ubiquitous and there are other advantages to not aggregating esp. re. inline JS/ CSS and dependencies)
  • new: no API needed any more to create manual critical CSS rules.
  • new: “disable global styles” option on the “Extra” tab.
  • new: compatibility logic for “edit with Elementor”, “revolution slider”, for non-aggregated inline JS requiring jQuery even if not excluded (= auto-exclude of jQuery) and JS-heavy WordPress blocks (Gutenberg)
  • improvement: defer inline now also allowed if inline JS contains nonce or post_id.
  • improvement: settings export/ import on critical CSS tab now takes into account all Autoptimize settings, not just the critical CSS ones.
  • technical improvement: all criticalCSS classes were refactored, removing use of global variables.
  • technical improvement: automated unit tests on Travis-CI for PHP versions 7.2 to 8.1.
  • fix: stop Divi from clearing Autoptimize’s cache which is pretty counter-productive.
  • misc smaller fixes/ improvements, see the GitHub commit log

Obviously given the amount of changes, thorough non-regression tests are required and that’s where you come in; you can download Autoptimize 3 beta from GitHub and install it instead of 2.9.5.1.

As some of the changes (esp. the new defaults for CSS & JS optimization) are only applicable to new installations (so not upgrades from 2.9.x), having that tested would be much appreciated as well 🙂

Looking forward to your feedback people!

peace & love,
frank

Нет войне!

by

My work as a developer of free and open source software is an expression of my firm belief in humanity, communication and collaboration. War is the opposite of those beliefs and I strongly support any action that opposes Vladimir Putin’s invasion of Ukraine. As such the protests in Russian cities against the war need to be heard loud and clear and repeated by anyone who believes in dialogue; Нет войне!

New in AO 3.0 beta: preload images for better LCP

by

A couple of days ago while racing my bicycle and not really thinking much, the next idea for Autoptimize just came to move; add a field to the metabox to allow an image to be specified as “to be preloaded” to help with Largest Contentful Paint.

Well, this has now been committed to the beta-version in 3 guises; when image optimization or image lazyload is active, AO will look for the full <img tag and use that to create a responsive preload tag. If the preload does not match an <img tag or if those 2 optimizations are not active, AO will add a non-responsive preload.

But enough writing, why don’t you go off to download the Beta now and play with it yourself already? All feedback is welcome!

The AO metabox with the new LCP preload field.

Autoptimize & WordPress 5.9 issue with aggregated inline CSS

by

WordPress 5.9 comes with a change I had not noticed before; it is adding inline CSS with random-ish names, which when “also aggregate inline CSS” is active makes the AO cache grow incredibly fast.

As a workaround you can add .wp-container- to the CSS optimization exclusions. I have just pushed out Autoptimize 2.9.5.1 which automatically excludes inline CSS with that string.

Fixing “Edit with Elementor” and Autoptimize

by

A regularly reported issue for Autoptimize + Elementor users is that JavaScript optimization breaks the “Edit with Elementor” button in the front-end admin bar. The easiest workaround is to disable the “also optimize for logged in administrators/ editors” option, but below code snippet is more surgical as it will only disable JS optimization, leaving e.g. CSS & Image, which do not impact “Edit with Elementor”, active;

if ( defined( 'ELEMENTOR_VERSION' ) && is_user_logged_in() && current_user_can( 'edit_posts' ) ) {
    add_filter( 'autoptimize_filter_js_noptimize', '__return_true' );
}

When in doubt, you can use the code snippets plugin to safely add this.

Of bugs and workarounds vs. root cause

by

My father, a retired mechanical engineer and a who’s technical skills, knowledge and passion are a big inspiration for me, always told his colleagues never to quick-fix the problem, but to look for the root cause instead.

Photo by Luis Villasmil on Unsplash

This obviously is true for software as well and remembering this good advice while walking the dogs yesterday evening stopped me from committing a finished workaround for a small bug (notices in the PHP error-log) and got me frantically error-logging left and right to try to identify the root of the problem this morning.

That root cause, as it turned out, was just a misplaced closing round bracket resulting in a combined conditional not executing correctly (I admit something silly like that should have been spotted during testing). Once identified, the fix was easily applied, improving the code and preventing extra workaround code from making things more complex.

So again: thanks dad!