Turbocharging Oxfam

Oxfam Ireland wanted a faster site. It was already pretty performant, especially for a high traffic site, chock-full of features, but with the ever upward march of mobile usage, performance rose to the top of the want list.

Why do you want a fast site?

The reasons are many, and often not even on a site-owner's agenda when planning a site. Here's a few:

1. Slow pages cost you conversions (AKA money!). Research back in 2006 by Greg Linden showed that every 100 millisecond delay in page rendering time resulted in a 1% loss of sales for Amazon. 
2. Google prefers faster sites, so it impacts on your search rankings. 
3. If you're on a mobile device over a dodgy connection you just aren't likely to hang around waiting for a slow page to load. Face it, you'll get bored and load up Twitter instead.

What counts as fast?

How fast is fast? Well for that matter, what counts as a page load? When is it 'done'? There's lots of tools and lots of metrics. e.g.

• Actual time to finish loading a page
• Time to first byte i.e. when the first packet (piece) of information hits your browser.
• Time to usable - this is where everything on the page is not loaded, but there's enough core content there to keep a user happy while the rest finishes downloading.
• onLoad event - this is a Javascript event that fires when all the Javascript is loaded and therefore all the bells and whistles should work.
• Perceived performance - this is more nebulous, but arguably the most important thing to consider. How fast does the site feel to the user? Does the important stuff at the top load quickly and first so they have something to look at? Can you click around whilst the rest loads?

We've done a bit of a deep dive on performance testing here, if you want to know more. 

How we made Oxfam's website faster

Performance is not binary. There are a lot of variables to consider. When speeding up oxfamireland.org, we took a three-pronged approach.

• server infrastructure.
• Drupal tuning
• a home-page redesign.

Each of these avenues of attack improved matters and each one worked in tandem with the other two to achieve measurable, demonstrable speed improvements.

Server Infrastructure

This was arguably the easiest improvement to implement. We moved the site from a dedicated, generic, virtual private server to our high availability, high performance platform. Tuned specifically for running big Drupal sites, our hosting environment comes fully loaded with a Varnish reverse-proxy server and Redis (an advanced key-value store) for lightning-quick server response.

In addition to simply putting the site on our platform we also made a few changes at Apache level, to better serve certain elements of a page, for example, compressing SVG files as they were served.

Drupal Tuning

Within the guts of Drupal we found plenty of small wins. We:

• disabled some unneeded modules.
• deleted other modules that had found their way on to the site but remained unused to reduce the amount of PHP that had to be parsed.
• isolated and solved small, otherwise inconsequential PHP errors and notices to relieve pressure from the database
• minified HTML, JS and CSS to reduce page weight
• moved as much JS as possible to the bottom of the page so that it would not block other elements from loading
• ensured that no modules were setting unnecessary cookies that might interfere with Varnish

Home Page Redesign

Home pages are notoriously heavyweight. Typically, home pages tend to have rich multimedia experiences, laying out a site's wares up front in the hope that a user can easily navigate to any part of the site from there.

Heavy pages take ages to load. Pages with lots of images take longer to load. High resolution, uncompressed images squished into a carousel/slider exacerbate slow loading. Throw in a good helping of Javascript and you're unlikely to see your page load this side of the weekend.

Whilst we wanted to improver overall load time, the real win was to improve the perceived usable state, i.e. the time to having usable content presented on the page and bring that down as low as possible.

With the home page redesign, we had the following aims:

• Reduce the number of page elements. In terms of designing for speed, less is more. So fewer images, fewer styles, less Javascript, etc. Every added element will have a performance impact.
• Following on from this, reduce the number of HTTP requests. Every HTTP request involves the overhead of a round trip from client to server and back again. Fewer requests means a faster page.

Drupal allowed us to combine CSS files and Javascript files to minimize their numbers and squish them through minification and compression to reduce their file-size. We looked into using image sprites and better using image-styles in order to optimize both the actual size and file-size of images.

The single biggest change was in getting rid of the hero image slider on the home page. This single element involved multiple large images and simply by removing that, it allowed a single smaller masthead image and text to load quickly and efficiently at the top of the page, so that it is the very first thing a user sees. This gives the perception of a really lightning fast site.

So how did we do?

The combination of all these techniques, each one a small gain, led us to a very nice 15% increase in overall page speed and more importantly, a massive 50% improvement in time to perceived usable state.

In an organisation where performance directly relates to numbers of donations which in turn directly affects the lives of the poorest people in the world, every millisecond counts.