Category Archives: performance

Saying goodbye to 2012.FFWD

Earlier today I updated my performance-centric TwentyTwelve child theme to fix a problem with the mobile navigation (due to the fact that TwentyTwelve changed the menu-button from a h3 to a button, which required the navigation JS which 2012.FFWD inlines to be updated as well). You can download the update here.

This update “officially” marks the end-of-life of this child-theme. Although a lot of optimizations can be done on a theme-level, I prefer focusing on tools like my own Autoptimize, which not only optimize code spit out by the theme but also any CSS/ JS introduced by plugins or widgets.

Quick KeyCDN’s Cache Enabler test

cache enablerCache Enabler – WordPress Cache is a new page caching kid on the WordPress plugin block by the Switzerland-based KeyCDN. It’s based in part on Cachify (which has a strong user-base in Germany) but seems less complex/ flexible. What makes it unique though, is it that it allows one to serve pages with WEBP images (which are not supported by Safari, MS IE/ Edge or Firefox) instead of JPEG’s to browsers that support WEBP. To be able to do that, you’ll need to also install Optimus, an image optimization plugin that plugs into a freemium service by KeyCDN (you’ll need a premium account to convert to WEBP though).

I did some tests with Cache Enabler and it works great together with Autoptimize out of the box, especially after the latest release (1.1.0) which also hooks into AO’s autoptimize_action_cachepurged action to clear Cache Enabler’s cache if AO’s get purged (to avoid having pages in cache the refer to deleted autoptimized CSS/ JS-files).

Just not sure I agree with this text on the plugin’s settings page;

Avoid […] concatenation of your assets to benefit from parallelism of HTTP/2.

because based on previous tests by smarter people than me concatenation of assets can still make (a lot of) sense, even when on HTTP/2 :-)

Is the web doomed?

Off course the web is not doomed, but despite the fact that web performance is immensely important (think impact on mobile experience, think impact on search engine ranking, think impact on conversion) the web keeps getting fatter, as witnessed by this graph from mobiforge;

web-page-size-revisited-revised

Yup; your average web page now has the same size as the Doom installer. From the original mobiforge article;

Recall that Doom is a multi-level first person shooter that ships with an advanced 3D rendering engine and multiple levels, each comprised of maps, sprites and sound effects. By comparison, 2016’s web struggles to deliver a page of web content in the same size. If that doesn’t give you pause you’re missing something.

There’s some interesting follow-up remarks & hopeful conclusions in the original article, but still, over 2 Megabyte for a web page? Seriously? Think about what that does that do to your bounce-rate, esp. knowing that Google Analytics systematically underestimates bounce rate on slow pages because people leave before even being seen by your favorite webstats solution?

So, you might want to reconsider if you really should:

  • push high resolution images to all visitors because your CMO says so (“this hero image does not look nice on my iPad”)
  • push custom webfonts just because corporate communications say so (“our corporate identity requires the use of these fonts”)
  • use angular.js (or react.js or any other JS client-side framework for that matter) because the CTO says so (“We need MVC and the modularity and testibility are great for developers”)

Because on the web faster is always better and being slower will always cost you in the end, even if you might not (want to) know.

Warning WordPress plugin users about their old PHP

After my initial disbelief about the amount of WordPress installations still on the slow and vulnerable PHP 5.2.17 (or older), I decided to warn users of my plugin with an non-dismissable warning on the plugin’s settings-page (and only there, so it’s not a default WordPress admin notice) cluttering the entire backend):

php52_warning_aoThis is going in AO 2.0.2 (out later today) and will in the future also be added to WP YouTube Lyte and WP DoNotTrack (both of which have a smaller reach).

If you’re a plugin or theme developer and want to warn your users as well (without blocking them), here’s the code I used (do change the translation-domain from “autoptimize” into one that is applicable to your plugin):

<?php if (version_compare(PHP_VERSION, '5.3.0') < 0) { ?>
    <div class="notice-error notice">
        <?php _e('<strong>You are using a very old version of PHP</strong> (5.2.x or older) which has <a href="http://blog.futtta.be/2016/03/15/why-would-you-still-be-on-php-5-2/" target="_blank"> serious security and performance issues</a>. Please ask your hoster to provide you with an upgrade path to 5.6 or 7.0','autoptimize'); ?>
    </div>
<?php } ?>

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.