Web performance - Analysing Heart.co.uk

5:17p.m., Thu 26 Aug 2010

A few weeks back I, together with m'colleague Jon Topper, delivered a presentation about the performance of heart.co.uk to the in-house team at Global Towers.

It's online via Microsoft Online Docs, courtesy of Tim Acheson, so I thought I'd re-present some of the interesting stuff here. UPDATE: the presentation is on slideshare now too :)

The trigger for the presentation was the worry that heart.co.uk performance appears sluggish via Google's Webmaster Tool. Given that Google has hinted that site performance will affect search results in future this was a worry for the business.

The presentation explains what happens when an URL is requested and how "site performance' is measured. After that, I presented some of the front-end techniques we have in place that are specifically aimed at improving the performance of the site. (I did consider titling it "We're Trying Really Hard, Honest" ;)

It was for a wide audience, including project managers & editoral staff as well as developers, so I barely scratched the surface, covering 4 broad areas:

• Writing clean mark-up
• Minimising HTTP requests
• Concatenating and compressing JS and CSS
• CSS sprites

These techniques are all detailed in the YSlow Performance Guidelines, so I won't bother re-treading that content but there's two interesting chunks of research here that I conducted before presenting:

1) Competitor Analysis

Given that half my audience was non-technical I placed this in context by comparing our source code with that of prominent competitors: Absolute Radio, Digital Spy, BBC's Entertainment portal, Kiss FM and Trent FM. Why those? Answer: I plucked them off the top of my head. Luckily, heart.co.uk compared favourably against these sites on most counts - I didn't hunt around for sites that made us look good, but I wanted similar sites, presenting similar content to similar audiences and for those sites to be familiar to my audience.

Clean Mark-up

As an experiment, I took the source of the HTML document, ran a regexp that stripped everything but textual content that is visible to the end user and then compared the difference, in bytes of the source file vs the content only.

These figures are slightly skewed by the fact that some sites pile javascript and CSS code into their HTML, but that's covered in the next table, so cool yer jets.

Content Vs Markup

Total download figures

• BBC Entertainment - 428Kb
• Trent FM - 646Kb
• Heart - 653Kb
• Absolute - 658Kb
• Digital Spy - 730Kb
• KISS100 - 1058Kb

Ad assets are included here, it's difficult to exclude them (plus I was running out of time to throw this presentation together!) I was only after a rule of thumb anyway. These figures are an average of 10 page loads. BBC Entertainment look good here - but then, they have no visually-rich ads to deal with.

Minimizing HTTP Requests

What was crucial here, for me, was to look at the core elements that render the site design and UI behaviour, rather than HTTP requests as a whole. So that's CSS files, JS files and images that have been requested within CSS declarations i.e. background images. I'm excluding stuff that's included via an adserver (which is different with each page load anyway).

The figures in brackets relate to IE6/IE7 figures where extra resources have been requested and loaded using conditional comments.

2) Ad Call Analysis

The Heart site measures up OK against the competition, we're applying more of the techniques and have a faster response too. The problem comes with ads which are called from adtech.com. The homepage of heart.co.uk has 12 script tags which request ads from adtech.com These script files frequently document.write in more script includes often from other domains in addition to the usual Flash and image files.

Number of ad calls on Global Radio sites (homepages)

• Xfm - 4
• Galaxy - 4
• CapitalFM - 5
• Classic FM - 6
• Trent FM - 8
• Heart - 12

12 script calls! Just for ads! And that's just the initial request - ads typically request at least 2 other scripts and a flash file, often across different domains - so we're talking about 30+ http requests for ads which, in the context of the earlier figures relating to our CSS/script files surely seems like a lot.

When you break down the code it heart-breaking stuff (pun intended) and it made me wonder why we bother trying to optimise performance and squeeze bytes off here and there when the online advertising industry pays such scant regard for good practice and user XP :(

Here's some tests of site speed with and without ads. Slightly skewed by the fact I'll get a quicker response from heart.co.uk by being on the Global Radio network - but the skew will be small enough to be negligible.

Numbers are in seconds and measured by the YSlow Firefox plugin. Note the large variation in the load times for the ads, and the relatively stable load times for the site.

I made no grand claims or proposals for improvement - that's not my job and I'm ill-equipped to do so, having little insight into the revenue that our display advertising generates. My aim was just to reassure the team that developers don't ignore the performance ramifications of what they do. First of all, we're paying more attentions to the detail of this 'science' than our competitors may be doing, and, secondly, a lot of the perceived problem is out of their control in that the root cause is advertisement from a 3rd (and sometimes 4th and sometimes 5th) party supplier.

Related Links

• Powerpoint Presentation Factors Affecting Web Performance (MS Docs)
• Presentation on Slideshare
• YUI Performance Guidelines
• YSlow Plug-in for Firefox
• Jon Topper on linkedin
  
• Tim Acheson's blog
  
• Absoluteradio.co.uk
• digitalspy.co.uk
• bbc.co.uk/entertainment
• kiss100.com
• trentfm.com
• heart.co.uk