Category Archives: performance

Why would you still be on PHP 5.2?

For Autoptimize 2.0.1 I declared a pretty complex regex to extract font-face’s from CSS using the nowdoc-syntax which is supported from PHP 5.3 onwards. Taking into account that the first PHP 5.2 release was over 9 years ago and support ended with the release of 5.2.17, over 5 years ago I assumed using a nowdoc would not be a problem for anyone. How naive I was; several people contacted me with this ugly error-message PHP 5.2 throws;

Parse error: syntax error, unexpected T_SL in /wp-content/plugins/autoptimize/classes/autoptimizeStyles.php on line 396

There is a workaround and even a more fundamental fix for that already, but who would still want to run PHP 5.2, which has this huge list of security issues? Moreover PHP 5.5 and 5.6 seem approximately twice as fast as 5.2 according to these test results and PHP 7.0 is even over three times as fast as 5.2! And still almost 9% of all WordPress sites are running on that old version (so I could have known this was coming really, bugger).

I you are one of those, do urge your hosting company to urgently provide you with an upgrade path to PHP 5.6 (or even 7.0)!

Hyper Cache hooking up with Autoptimize

satollo.netStefano Lissa, the developer of Hyper Cache, just released a version which hooks into Autoptimize (the autoptimize_action_cachepurged action) to automatically purge the page-cache if Autoptimize’s cache gets cleared. Thanks Stefano, it’s no coincidence Hyper Cache is one of my favorite page-caching plugins!

The Gator Cache-developer is also working on a new version which will do the same by the way.

HTTP/2 & JS/CSS optimization: eBay’s approach

Quick follow-up to my previous post about HTTP/2 and Autoptimize; I just read an “Packaging for Performance”, an interesting article on Performance Calendar by eBay’s Senthil Padmanabhan. Well worth the read, but the summary; their research confirms bundling of JS/CSS still has clear performance benefits, but they did stop bluntly aggregating all in one file to improve cache-ability. This leaves them with;

  • one optimized JS and one optimized CSS file for the core libraries, used throughout eBay, high cache-ratio & payload
  • one optimized JS and one optimized CSS file for the “domain constants”, used on specific eBay segments, medium cache-ratio & payload
  • one optimized JS and one optimized CSS file for the “domain variables” containing fast changing code for specific segments, having lowest cache-ratio and payload

So yeah, I see a bright future for Autoptimization in the coming age of HTTP/2! :–)

Making Autoptimize faster

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

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? ;-)

Autoptimize to allow optimizing whitelisted resources only (and more)

Although work is still ongoing on what will become Autoptimize 2.0, I thought I’d share an (API-only) feature that allows developers/ web agencies to only aggregate & minify a fixed set of known-good resources only. This whitelist-based optimization will allow for a more stable situation upon delivery of your project to customers, as the CSS/ JS of plugins that are installed by your customer will not be autoptimized, so the site is less likely to break by accident.

The following example-code shows how to tell Autoptimize to only aggregate & minify jquery.js and jquery-migrate.min.js;

add_filter('autoptimize_filter_js_whitelist','example_js_whitelist');
function example_js_whitelist() {
return "jquery.js,jquery-migrate.min.js";
}

Using autoptimize_filter_css_whitelist allows you to accomplish the exact same things for CSS. The guys over at gigaom.com are already using autoptimize_filter_js_whitelist, so we must at least be doing something right there.

Some other new filters that might prove helpful;

  • autoptimize_filter_css_removables and autoptimize_filter_js_removables will allow you to specify which CSS or JS should actually be removed alltogether (Google Fonts, Emoji’s, … all in case you don’t like dequeuing off course)
  • autoptimize_filter_css_inlinesize allows you to specify up until how many characters of optimized CSS should be inlined instead of linked (can be useful for print CSS). Default value is 128, but I might bump that to 256 actually.
  • passing “true” to autoptimize_filter_css_fonts_cdn will tell AO to try to switch the font URL’s to your CDN
  • autoptimize_filter_cssjs_multidomain takes an array which can be used to tell AO that are also to be considered local domains and resources from those can be optimize (warning; as AO aggregates from the filesystem, this only works if the resources are actually local)
  • autoptimize_filter_cachecheck_do, autoptimize_filter_cachecheck_frequency and autoptimize_filter_cachecheck_maxsize can be used to control the wp-cronned cachechecker that will get triggered daily

Non-API improvements include performance optimizations, out-of-the box support for WPML subdomain-based language-variations and a whole heap of smaller improvements and bugfixes (e.g. the fact that if you have multiple title-tags, the optimized CSS would be injected in front of every one of those).

So yeah, I’d say we almost have ourselves a release. Only major thing still to go in; swapping the “look only in head” for an “include inline code” option. And testing of course, but that’s one area where I am looking at YOU, dear reader! Download the in-development version from GitHub and test away!