BBC newsroom and news studio at BBC New Broadcasting House
We recently attended a seminar on optimising the loading speeds of mobile websites, held at the BBC’s New Broadcasting House in Portland Place. The event was organised by the London Web Performance Group on December 10th 2013.


BBC New Broadcasting House exterior smallLearning from the BBC News mobile website

Tom Maslen, from the BBC, talked about the new BBC News website and the challenges involved in building the mobile version. Surprisingly 50% of visits to are now on mobile devices, so it’s crucial they get their mobile site right.

The mobile website has a simple layout and is designed to load as quickly as possible, with a core basic experience (designed to load on all devices) and an enhanced experience (with advanced features for newer devices). This approach means the BBC News website can support a whole range of devices and even supports older browsers by default – just they don’t get the full benefit of the advanced features.

Tom explained the huge complexity in testing a responsive website that works well in all the different types of devices on the market, each of which have their own screen sizes and behaviours.

He said that a responsive website (i.e. one that adapts to different screen sizes and devices) takes approximately three times as long to create and test compared to a traditional non-responsive website and added it definitely “makes our jobs more complicated!”


BBC New Broadcasting House entrance - smallThe five tips he gave were:

  1. Pay close attention to your file sizes, especially image files.
  2. Only download what users need – so images larger than their display size shouldn’t be used (if you’re using WordPress, try to ensure plugins don’t insert their style and JavaScript files on pages where they’re not needed).
  3. Minimise the number of files needed for download (as each HTTP request adds to the download time).
  4. When designing a responsive website, be careful when changing code that you don’t break things on other devices (i.e. have a way to test your website on lots of different devices).
  5. Use browser caching (56% of the files on the internet have a cache time of zero!).


mobile website critiqueSo, let’s put this into practice with an example of a real-life mobile website:

Eric recently asked me on Google+ to give a critique of his marketing company website (we’ll keep the name anonymous!). His real website (a responsive site based on WordPress) is pictured here and the first thing I noticed is that it was incredibly slow to load.

  1. Some quick analysis of the home page showed that it was a whopping 7MB to load – that’s massive! To put it in comparison, our Primary Image home page is currently 650KB. Eric’s website uses a video effect on the home page, however this also displays for mobile users. As we’ve all experienced, trying to get a video to load on a 3G connection can be difficult and 7MB is quite a hefty chunk of data! In reality, most users will get fed up of waiting for their mobile browser to load the page after a few seconds and leave his website.
  2. There’s a lot of unnecessary files (especially JavaScript files) being downloaded on each of Eric’s website pages, so he should look at removing these. They’re just slowing down the loading time for no benefit to the user.
  3. When a visitor goes to Eric’s home page, their browser has to download 98 files for the page to display. For each of these files, the browser has to make a request to the server and wait for the file to be delivered, so there’s a small delay for every file you include. When you’ve got lots and lots of files, this delay can start to become noticeable. In comparison, our Primary Image home page currently uses 34 files. One technique Eric could try is combining files (such as JavaScript and CSS files) rather than having lots of scattered files.
  4. Be careful that you test properly when designing a responsive website! With Eric’s website, if you look at the example iPhone view shown here, the slider panel text becomes unreadable (as it’s so small) and some big gaps appear. These need to be corrected.
  5. Eric’s website does utilise browser caching, which is good! It means that resources that don’t change much (such as the JavaScript and CSS files) are held on a visitor’s device (in their temporary internet files) for when they visit again, so they don’t have to be downloaded again. Where Eric could, however, improve his website is by using server-side caching too, which means WordPress won’t have to generate the pages every time a visitor goes to a page (a WordPress plugin like HyperCache could help with this).


Testing mobile websites with real users

Peter McLachlan, from Mobify, gave a talk on “real” user monitoring. So, rather than trying to emulate how a webpage loads on a mobile device, he has done research using measurements from real mobile devices on 3G/data connections.

Peter explained that for every second a webpage takes to load, there’s a drop-off in the number of people willing to wait and many users will exit the page without waiting more than a few seconds.

He said that whilst lowering the file sizes of a mobile website is of course important, physics also dictates that there will always be some latency (i.e. a time-lag) when requesting and downloading all the little files that make up a complete webpage between your device and wherever the web server is located. On a mobile connection, this time will always be multiplied several times greater than on a fixed line connection.

Some of Peter’s tests shows that the UK actually has a pretty good mobile data infrastructure in terms of the time it takes to get the first response from a website (second only to the Netherlands in his tests across Europe and America). What he did say, however, was that mobile coverage was quite patchy – something we all know is a real frustration! He also said there was hardly any noticeable difference between how the mobile operators performed, although ‘three’ had a very small margin better than the others.

In terms of some practical technical advice that Peter gave, he said:

  • Watch the cookie size on your website as this does have a performance impact.
  • Phase out domain sharding. In the past computer/mobile browsers could only download a very limited number of files simultaneously from the same domain name (e.g. two files would download, then once they’ve downloaded, another couple of files would download, and so on). A practice was developed to spread your website files across several different domain names to speed up loading times. Peter says this technique is no longer beneficial, especially for mobile browsing, as it results in more “cold calls” to different domain names (i.e. there’s a time-lag when connecting to a new domain name for the first time) and most browsers now allow more simultaneous connections anyway, so he recommends phasing out this practice.
  • CSS sprites are good, i.e. combining icons and small images into a single image file, as this reduces the number of different file requests and downloads.


Thanks to all that organised this London Web Performance Group meetup – a very interesting event with some useful tips!

Images Copyright © Primary Image.