Skip to main content

Somme people need a faster website...

The 100th anniversary of the Battle of the Somme is approaching and in remembrance of the battle a commemorative event will be held at 12:00 (11:00 GMT) on 1 July 2016, at the Thiepval Memorial in Northern France. Tickets for this event will be awarded by public ballot. The ballot for tickets opened on 28 September 2015, and will close on 18 November 2015.

When the ballot opened on 28th September, the BBC news website reported the event and, as is often the case for popular events, the http://somme2016.org website crashed. I checked the website a couple of times on 28th September 2015 and this is what I saw.

This isn't a good "first impression" for visitors to your website.

A couple of hours later, I tried again, this time from a desktop browser but I experienced similar problems.

Later in the day I noticed that requests for http://somme2016.org were being redirected to Seetickets, but even that redirect wasn’t working well. Perhaps the initial website was still experiencing problems or maybe the Seetickets infrastructure was having problems. I was surprised that this type of problem was happening on a site which I would expect to have less mass-market appeal than other events successfully promoted by Seetickets.

Following up my earlier investigations, I decided to have a more detailed look at the Somme 2016 website using TrustIV’s WebPageTest instance hosted in Manchester. This showed a number of potential reasons for the poor performance.

Results:

The waterfall chart for the initial page request shows that even today, the page is taking more than 8 seconds to load and more than 9 seconds to fully render in the Chrome browser on a 5Mbit/s link. 

1.3 seconds elapses before the first byte is received by the client browser (Time to First Byte). Based on the ‘Blink’ test, that’s 1.3 seconds of your site visitor's patience wasted. 

Once the page starts to download, other problems with the page construction are apparent.

Image compression: 7 images are downloaded in a higher resolution than required. Compressing these on the server would reduce the image payload from 641KB to 483KB, saving 157KB. At 5Mbit/s this would only save 0.03 seconds which doesn’t sound much on a per-user basis but the cumulative effect on the server is more significant.

Image type: Converting to progressive jpeg images may reduce the image size further and would create the impression of a faster page load time for users. Progressive jpegs contain multiple versions of an image, all of increasing quality. When a browser displays them in sequence, the user perceives a faster load time and a more responsive page.

Caching content: The webpage is primarily static content so could easily be cached by a CDN. Over 90% of the content comes from the somme2016.org domain. This domain is registered by Red Giant Projects Ltd, the organisers of the Somme 2016 commemoration. Using CDNs close to the audience could almost certainly improve performance as well as reducing the load on the somme2016.org webservers.

Reducing the number of requests: The webpage is made up from multiple .js (Javascript) and .css (stylesheet) files. Merging stylesheets into a single file would reduce the number of requests and improve performance, the same technique could then be used for the javascript files.

Server location: According to the WHOIS records, the server is hosted by GoDaddy in Arizona, USA. This struck me as a strange location for a website whose primary audience is likely to be British or French visitors. I decided to check this using several traceroute services and each time, it did seem that my page request was served from the USA.

I was surprised that the server appeared to be US-based, so I decided to double check this using the “Visual Trace Route Tool” from the yougetsignal.com website.

The apparent location of the server seemed illogical for a site designed for European visitors, so checked with HTTP-PING and saw slow response times which could be exmplained by the server's remote location. Even simple HTTP-PING requests (which request content without rendering) were taking >1.5 seconds.

Even simpler PING requests still took > 1.5 seconds.

Even more curious about this potential problem, I did some more IP location searches and all of them pointed to a US-based server.

To improve performance of this website, I’d recommend the following:

  • Move the website closer to the audience.
    (It is more than 5000 miles from the Somme to Arizona!)
  • Cache content with a CDN to reduce the load on your webservers.
  • Reduce the size of images and use progressive JPEGs to improve performance.
  • Merge CSS files to reduce the number of HTTP requests per page.
  • Merge JS files to reduce the number of HTTP requests per page.
  • Minify the .JS and .CSS code to reduce the page download size.

The list of performance improvements above stands true for a great number of websites. When promoting any event via a website, it’s essential to develop a site that will perform well. You can’t always predict the increase in traffic from a social media campaign or a news article. Techniques like Network Virtualisation add great value in providing insight into behaviour of sites globally, as well as how the page returns on mobile devices. Once you’ve improved the site as much as you can it’s vital to test it thoroughly just to reassure yourself that it will perform as required. Testing isn’t always hard, but it’s often overlooked. 

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.