1. Associate a banner image with each post.

2. Generate multiple versions (sizes) of these banner images.

3. Provide the generated images in variables for use in post templates.

Each post in the site is represented by a directory containing an index.md Markdown file and, optionally, a banner.png image file. This repository contains two posts, one with and one without an image:

posts/2013-10-23-post-without-banner/index.md
posts/2013-10-24-post-with-banner/banner.png
posts/2013-10-24-post-with-banner/index.md

The site.hs Haskell program contains only the most basic Hakyll directives to process the Markdown files (indeed, I haven’t even bothered to override the date code; you’ll need to put the date in the Markdown file metadata). In addition, it contains the proof-of-concept code to handle the banner images.

The imageProcessor function is a helper to construct the Hakyll Rules () to process a set of banner images and the Context a allowing them to be used in the associated posts and templates. This function takes a Pattern which matches the banner images and a list describing the different versions to generate of each image.

let (postImages, postImageField) = imageProcessor "posts/*/banner.png"
                                     [ ("small" , Just (200,100))
                                     , ("medium", Just (600,300))
                                     , ("full"  , Nothing)
                                     ]

The first argument to imageProcessor is the pattern identifying the image to be processed. This pattern must end in a full filename. The second argument is a list of versions to create. Each version has a name (the String) and image processing instructions (Nothing to copy the image, Just (x,y) to scale and crop the image to the given dimensions using ImageMagick’s convert command). This generates a Rules () value to process the images (postImages in the code) and a Context a to make them available in posts and templates.

The Rules () value can be “run” just like any create or match statement and the Context a value can be used in the context of post with a path that matches the image pattern (ignoring the filename). This context defines one variable for each of the image versions being generated. In this code, the variables are:

• banner-small is a 200x100 image.
• banner-medium is a 600x300 image.
• banner-full is the original image.

These names are generated from the filename banner.png in the image pattern (this is why the pattern must have a filename) and the name of each version.

With this configuration, the posts included in the repository result in the following files being generated:

posts/2013-10-23-post-without-banner/index.html
posts/2013-10-24-post-with-banner/index.html
posts/2013-10-24-post-with-banner/full-banner.png
posts/2013-10-24-post-with-banner/medium-banner.png
posts/2013-10-24-post-with-banner/small-banner.png

As expected, each post has an index.html file and the single banner image has small, medium, and full versions.

The implementation of imageField and the assumption that the pattern ends in a file name are pretty crappy but, overall, I’m quite happy with this approach.

Today I had to look at a client’s web-site to resolve a performance problem that I’d heard of a few times but had never been able to reproduce. The reports looked something like this:

Can you look take a look at our site again? It’s very slow to load the page but all the other sites I try are fast. It works find on [manager’s] Mac but my PC and the rest are all slow.

First things first, I fired up a Windows install in Virtual Box and found that, yes, it was indeed slow on IE (but not on any other browser I tried).

Given that there’s a bit of fancy schmancy JavaScript going that was my next port of call. After a while trying to find the option to disable JavaScript (Internet Explorer has one of the worst configuration interfaces of pretty much any software I’ve used) I remembered that this install had the developer toolbar installed. A quick navigate through three or four layers of menu (Seriously Microsoft: try giving some consideration to user experience one day. You might find you like it!) and a visit to Disable -> Scripts and I’d confirmed that yes, the problem was only seen with scripting enabled.

There are various bits of jQuery used on the site including a light-box popup thing, a slideshow type arrangement and a few custom bits. I cloned the site into my development environment and prepared to set to with my trusty /* */. Horror of horrors, the problem went away. A few goes back and forth over hosts and it was clear – the problem happened “live” (with JavaScript) but didn’t happen at all locally. Crap.

As a last resort before breaking a live site to try to diagnose the issue I appealed to Twitter. A few responses from some helpful sorts didn’t point out any obvious things to check (and pretty much discounted my own theory of blaming: my favourite of Microsoft’s misfeatures, filters). In a last ditch effort to find the problem without disabling bits of the live site I appealed again to Twitter for someone to jog my memory. I remembered a site that I’d seen before (in mid-October, it turns out) that provided performance data and screenshots from real browsers. Nick Cowie replied with the linked that saved me hours: I was looking for webpagetest.org!

WebPagetest is a free web-page performance service. Give it a URL (and maybe set some options), wait a little while, and you get back report about your site. Like most such things you get a screen shot, but more usefully WebPagetest provides a timeline of fetching and rendering the page. Here’s an edited screenshot of that first report:

Notice, if you will, all that red and yellow and the fact that the initial request took 53 seconds and subsequent requests took 31 seconds! A closer look at the waterfall chart shows that around a third of the time to load and render the page comes from those red requests – about a dozen requests that result in 404s – so I set about fixing them. It was evident that they were images that form the border of the Fancybox “popup” and a quick grep saw that they were referenced from fancybox.css with a relative path. I was wrong when I though that filters weren’t to blame: Microsoft’s filter hack interprets paths to images relative to the document being displayed not the stylesheet it is defined in (unlike every other reference to an external resource in a stylesheet). One such error might not be a problem: a silly, preventable mistake, but not critical (beyond the resource not being loaded and used). A dozen means that IE stalls for 12 URLs / 2 connections * load time which can be ages if your slowish CMS is serving the 404 pages.

I fixed the missing files (by duplicating them to the expected location, I’m afraid) and the load time dropped by some 20 seconds. Job done.

All that yellow looked a bit dodgy though, so I kept going. Most of that is indicating requests that could have been cached on the client but weren’t because of configuration issues. I added some ExpiresDefault server directives and pretty much all that yellow went away:

Resolving a few 404 errors that slipped through the obviously gaping cracks in our QA procedure and correcting some server configuration oversights took this site from load and render times of 53 seconds and 31 seconds (initial and subsequent, respectively) down to 23 seconds and 2.6 seconds!

There are three things that have come out of this experience:

1. The client’s problem has finally been resolved.

2. It’s pretty clear that I’ve got a lot of work to do improving our quality assurance procedures.

3. It’s also clear that developing a server configuration with reasonable defaults will result in some dramatic performance improvements.

Now it’s time to fill these gaps so that we catch this type of issue and pick these low-hanging fruit in our current and future work.

A quick Google led me to an article called Create PDF thumbnails with imagecache and ImageMagick while GD is still the default toolkit which supplies the following code (simplified a little by removing the PDF-y bits):

<?php
$w = 246; // change to your preferred thumbnail width
if (!_imageapi_imagemagick_convert($image->source.'[0]', $image->source.'.png', array(0 => '-thumbnail '.$w))) return FALSE;
$img = imagecreatefrompng($image->source.'.png');
file_delete($image->source.'.png');
$image->resource = $img;
$image->toolkit = 'imageapi_gd';
$image->info = array('extension' => 'jpeg');
return TRUE;
?>

Alas, this code it pretty useless: because it stomps on $image->info any further actions on this $image will probably break.

Thankfully, there’s an easy fix: when you update $image, make sure you update everything that needs fixing. Here’s the amended code:

<?php
// "Thumbnail" the image
$width = 600;
if (!_imageapi_imagemagick_convert($image->source, $image->source.'.png', array(0 => '-thumbnail '.$width))) return FALSE;

// Load it back in as a GD resource
$img = imagecreatefrompng($image->source.'.png');

// Get the "deets" on the new image
$info = getimagesize($image->source.'.png');
$image->resource = $img;
$image->toolkit = 'imageapi_gd';
$image->info = array(
  'width' => $info[0],
  'height' => $info[1],
  'extension' => 'png',
  'file_size' => filesize($image->source.'.png'),
  'mime_type' => $info['mime'],
);

// Clean up
file_delete($image->source.'.png');

return $image;
?>

Make sure that you’ve enabled the ImageMagick toolkit, drop this code in a custom action and you’ll be on externally processing images in no time!