Category Archives: autoptimize

How to fix render-blocking jquery.js in Autoptimize

Autoptimize by default excludes inline JS and jquery.js from optimization. Inline JS is excluded because it is a typical cache-buster (due to changing variables in it) and as inline JS often requires jQuery being available as a consequence that needs to be excluded as well. The result of this “safe default” however is that jquery.js is a render-blocking resource. So even if you’re doing “inline & defer CSS” your Start-Render time (or one of the variations thereof) will be sub-optimal.

Jonas, the smart guy behind criticalcss.com, proposed to embed inline JS that requires jQuery in a function that executes after the DomContentLoaded event. And so I created a small code snippet as a proof of concept which hooks into Autoptimize’s API and that seems to work just fine;

The next step is having some cutting-edge Autoptimize users test this in the wild. You can view/ download the code from this gist  and add it as a code snippet (or if you insist in your theme’s functions.php). Your feedback is more then welcome, I’m sure you know where to find me!

(When) Should you update to WordPress 5.0?

Concerning the very short-notice release-announcement of WordPress 5.0 with Gutenberg for Dec 6th: I’m with Yoast;He has a great “should I update”-checklist and conclusion in this blogpost;

  • Is now the right time to update?
  • Can your site work with Gutenberg?
  • Do you need it?

So our advice boils down to: if you can wait, wait. 

So if you have a busy end-of-year, if you’re not 100% sure your site will work with Gutenburg or if you don’t really need Gutenberg in the first place; wait (while WordPress 5.0 stabilizes with some minor releases).

Warning: Divi purging Autoptimize’s cache!

A heads-up to Autoptimize users who are using Divi (and potentially other Elegant Theme’s themes); as discovered and documented by Chris, Divi purges Autoptimize’s cache every time a page/ post is published (or saved?).

To be clear; there is no reason for the AO cache being cleared at that point as:

  1. A new page/ post does not introduce new CSS/ JS
  2. Even if new CSS/ JS would be added somehow, AO would automatically pick up on that and create new optimized CSS/ JS.

Chris contacted Divi support to get this fixed, so this is in the ticketing queue, but if you’re using Divi and  encounter slower saving of posts/ pages or Autoptimized files mysteriously disappearing then his workaround can help you until ET fixes this.

Hide-my-WordPress & Autoptimize compatibility glue

An “Autoptimize Critical CSS“-user saw some weirdness in how the site looked when optimized. The reason for this turned out to be not the critical CSS, but the fact that he used “Hide My WordPress Pro”, a plugin that changes well-known paths in WordPress URL’s to other paths (e.g. /wp-content/plugins -> /modules/ and /wp-content/themes -> /templates) and uses rewrite rules .htaccess to map requests to the filesystem. This resulted in Autoptimize not finding the files on the filesystem (as AO does not “see” the mapping in .htaccess), leaving them un-aggregated.

To fix something like that, a small code snippet that hooks into Autoptimize’s API can do the trick;

add_filter('autoptimize_filter_cssjs_alter_url', 'rewrite_hidemywp');
function rewrite_hidemywp($url) {
    if ( strpos( $url, 'modules/' ) !== false && strpos( $url, 'wp-content' ) === false ) {
        $url = str_replace('modules/','wp-content/plugins/', $url);
    } elseif ( strpos( $url, 'templates/' ) !== false && strpos( $url, 'wp-content' ) === false ) {
	$url = str_replace('templates/','wp-content/themes/', $url);
    }
    return $url;
}

The above is just an example (as in the Pro version of hide-my-wp you can set paths of your own liking and you can even replace theme names by random-ish strings), but with a small amount of PHP-skills you should be able to work out the solution for your own site. Happy optimized hiding!

Quick trick to disable Autoptimize on a page

So suppose you have one page/ post which for whatever reason you don’t want Autoptimize to act on? Simply add this in the post content and AO will bail out;

<!-- <xsl:stylesheet -->

Some extra info:

  • Make sure to use the “text”-editor, not the “visual” one as I did here to make sure the ode is escaped and thus visible
  • This bailing out was added 5 years ago to stop the PHP-generated <xsl:stylesheet from Yoast SEO from being autoptmized, if I’m not mistaking Yoast generates the stylesheet differently now.
  • The xsl-tag is enclosed in a HTML comment wrapper to ensure it is not visible (except here, on purpose to escape the HTML tags so they are visible for you to see).