Category Archives: Web development

Blogposts on blog.futtta.be about “web development”; looking into frameworks, security, best practices, the use of Flash, usability and accessibility, …

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 :-)

The optimism of a pull request

I was getting old yesterday,with pessimism taking over. But then there’s that Git pull request on your open source project, from an Argentinian developer you don’t know at all. And you discuss the idea and together you build on it, step by step and the merged result is an enrichment not only for your little software-project, but also for you personally. Because it reminds you that too is the web; a place where people collaborate for nothing but the selfless desire to improve things. Thanks for reminding me Pablo!

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.

About Insanely Stupid Code

When looking into a JS-problem on an Autoptimized site, it turned out missing semi-colons messed things up. Missing semi-colons make JS un-minifyable, as eloquently explained by master-minifier and JS-guru Douglas Crockford in this Bootstrap issue from back in the day;

That is insanely stupid code. I am not going to dumb down JSMin for this case.

Forcing Featured Video Plus to display Lyte YouTubes

A couple of days ago a WP YouTube Lyte user asked me if Featured Video Plus and WP YouTube Lyte were compatible. It took me a day to find the answer (I first said “no”), but Featured Video Plus actually has a filter (get_the_post_video_filter) that allows one to override the code used to display the featured video. And after a bit of trial and error this is what I came up with;

add_filter('get_the_post_video_filter','lyte_featured_video');
function lyte_featured_video($in) {
	$post_id = ( null === $post_id ) ? get_the_ID() : $post_id;
	$meta = get_post_meta( $post_id, '_fvp_video', true );
  	if (($meta["provider"]==="youtube") && (function_exists('lyte_parse'))) {
		return lyte_parse($meta["full"]);
	}
 	return $in;
}

Some extra checks ($post_id should not be empty, $meta should not be empty) would make this more reliable, but that’s something you should be able to add, no?

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)!