minification

Whatever you do, don’t lie (when naming files)

by

So since Autoptimize 2.0.0 got released half a year ago, minified files are not re-minified any more, which can yield important performance-gains. Or that, at least, is the goal. But as checking if a file is minified is non-trivial, AO reverts to a simpler check; does the filename indicate the file is minified. So for example whatever-min.js and thisone_too.min.css would be considered minified and will simply be aggregated, whereas not_minified.js would get minified. Mr Clay’s Minify (which is used by WP Minify, BWP Minify and W3 Total Cache and of which the core minification components are in Autoptimize as well) applies the same logic.
But apparently plugins often lie about their JS and CSS, with some files claiming to be minified which clearly are not and with some files (even WordPress core files) being minified but not having the min-suffix in the name. It’s obvious that lying like that is kind of stupid: saying your files is minified when in fact it is not, offers you no advantages. Not confirming your file is minified in the name when it is, saves you 4 characters in the filename, but I suspect you were just being lazy, sloppy or tired, no?
So, ladies and gentlemen, can we agree on the following:

  1. Ideally you ship your plugin/ theme with minified JS & CSS.
  2. If your files are minified, you confirm that in the filename by adding the “.min”-suffix and minification plugins will skip them.
  3. If your files are not minified, you don’t include the “.min”-suffix in the filename, allowing for those minification plugins tot minify them.

For a more detailed overview of how to responsibly load minified JS/ CSS in WordPress, I’ll happily point you to Matt Cromwell’s excellent article on the subject.

Making Autoptimize faster

by

One of the big changes in Autoptimize 2.0 (estimated released between Christmas & New Year) is a significant improvement in the minification speed (30% faster should be no exception). As a quick reminder, this is what Autoptimize did until now;

  1. extract code from HTML & remove original references
  2. aggregate all code into one string
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. store the result in cache
  5. inject reference to cached autoptimized code in HTML

It is the actual minification in step (4) which can slow Autoptimize down (hence the importance of making sure your cached files are reusable). In Autoptimize 2.0 above logic was changed to improve performance;

  1. extract code from HTML & remove original references
  2. aggregate all unminified code into one string, but only put a reference to already minified files (*min.css and *min.js)
  3. check if a minified version of that string exists in cache
  4. if not in cache;
    1. minify that string
    2. replace references to minified files with (slightly optimized) contents
    3. store the result in cache
  5. inject reference to cached autoptimized code in HTML

As the to-be-minified string is smaller, the JS- & CSS-minifiers have less code to optimize, indeed speeding up the process significantly. Additionally this also reduces the chances of problems with the re-minification of already minified code (e.g. p. So nothing but advantages, right?
Now this was tested rather thoroughly and all known kinks have been ironed out, but If this “injected minified code late”-approach does not work in your context, you can simply disable it by hooking into the API and setting the autoptimize_filter_js_inject_min_late and/ or autoptimize_filter_css_inject_min_late filters to false (use code snippets rather then adding it to your functions.php);

add_filter('autoptimize_filter_js_inject_min_late','no_late_inject');
add_filter('autoptimize_filter_css_inject_min_late','no_late_inject');
function no_late_inject() {
	return false;
}

HTTP/2, CSS/JS concatenation and Autoptimize

by

The web performance world is abuzz with HTTP/2, which should (among other improvements) do away with the latency that each separate HTTP-request introduces, thus rendering aggregation of e.g. CSS & JS an anti-pattern. But there’s at least one in depth facts and figures based article that is not ready to dismiss “packaging” just yet. So: testing, testing, testing!
Autoptimize will in the not too distant future very likely have a “don’t aggregate, just minimize”-option, but the proof of the pudding will always be in the eating testing; sometimes it will be better to aggregate and minify as we do now, sometimes only minifying will be the better approach. And maybe (often?) a combination of those will make most sense: suppose you have a site on which 90% of pages share 90% of JS code. In that case it will likely (testing, testing, testing!) help performance to aggregate & minify the 90% of JS while excluding all other JS from aggregation (and minifying that). Sounds like the new whitelist-filters in Autoptimize’s API will come in handy no? 😉