A Saturday well spent at Edgeconf – Advanced Web Technologies And The Need For Website Speed

Date: 11th February 2013
Author: Deri Jones

With two kids, it’s very rare I give up a Saturday for work.

But the edgeconf this weekend looked like it was going to be worth it: with panel discussions not vendor keynotes! It also featured some of the actual hands-on guys doing the leading edge stuff, from the major browsers Chrome, Firefox and Opera, as well as some of the sharpest developers who are delivering business value from the least technologies.

The conference was organised by the guys from FT Labs, those responsible for the FT Newspaper’s HTML5 site that allows readers to read the paper on and off-line. Offline is when your device is no longer connected to the Internet, which for a normal website would mean you can’t access any more content.  However an Offline Web Application can carry on working and serving page content it has grabbed in advance so that the user experience is seamless.

My specific interest in Web performance cropped up in several of the slots, with some interesting new tips to take away.

The structure was perfect for learning: each 60 minute slot started with a 10 minute chat and then a  panel of 4 discussed questions from the floor.

Engineers were there from most of the major browsers (shame about MS and Apple… I’m told that apparently they are less keen to send send engineers to events like this).

With the discussion at the leading edge of technology, it was interesting to hear how the browser guys are watching what developers do with the new features of HTML5, and how they build new features on top in Javascript to address additional goals.  As good usage patterns evolve, the browser guys will plan to bring them into the core Browser itself.

Here are some of the website performance optimisation tips I picked up.

Rethink the network’s effect on your visitor
As users do more and more of the browsing whilst on the move it means that the site developer has to think again about the network properties. Fast broadband at home lulled us all into a false sense of security because our pages now need to work nicely (fast) for users browser via 3g (4g…2g..!).

The problem for the mobile networks is that they are extremely variant and transient.  The fact that your visitor had a fast connection over the last 5 seconds is no predictor that their connection will be equally good for the next 5 seconds. Moving a device just 10 or 20 cms can change the network connectivity from great to terrible!

So the consensus across the conference was that there is no value in the browser recording the network speed of the visitor and passing it to the website, as there’s nothing useful the site can do with data that doesn’t say how the the user’s network connection will perform over even the next 5 seconds.

There’s an interesting warning here to RUM (Real User Monitoring) based approaches:  any performance data calculated within the browser and sent back to the site is also hugely variable, because it’s made of data from each user that itself varies widely.

For example: RUM data may show that your site slows down between 8 am and 9am, and then speeds sharply. This may be quite untrue. The slowdown may be caused by visitors browsing on mobile devices as they travel to work and then from 9am onwards the site speeds  up, as they are now on well connected wifi network in the office!

Top Tip
Two years ago the advice to website developers, was to structure pages so as to send initially as little as possible to the user to get a  usable page fast and then send the rest after page load.

But this advice has now been reversed!

Instead, it’s better to send the whole page to the user and then nothing more! The reason is down to the properties of mobile networks whereby although bandwidth increases. latency is not reduced. This results in a delay between batching enough data to send and then sending it, and then waiting to batch again.  The more you send your page in small pieces, the more prone it is to being held up.

The second reason is battery life. In mobile devices the biggest battery hogs are the screen first and the radio second. Mobile devices will allow the radio to power down, after a period of mis-use: thus saving battery.  But if your page is chattering to the user over a long period of time the radio can never power down.  In one test a site discovered that traffic being sent between pages was only 0.1% of the network traffic, but when disabled caused 40% drop in  battery drain!