RSS

Portfolio: betfair.com rebuilt for speed

08 Jan

Betfair’s completely rebuilt sports betting site – http://beta.betfair.com/football

I used: Javascript | YUI3 | CSS3 | LESS | HTML5 API’s | Agile | Performance optimisation

I just completed a 12 month contract with Betfair Plc in Hammersmith to help rebuild their sports betting site from the ground up. The project had two main aims – make it robust, and blazing fast.

betfair.com is high volume – its 3.7 million customers in 140 countries have £300M on deposit. Notable spikes in usage include the 2010 World Cup Final (£68M traded) and the Grand National (30,000 bets placed in a single minute).

Performance had been shown to have a direct correlation with revenue. Make the site faster, and people place more bets. Simples.

The old site had pushed most processing and rendering duties to the browser, resulting in a morass of several MB of Javascript and a page load time of 15 – 20 seconds. The aim was to reduce that to 3s. That’s in the slowest browser, with an empty cache, on an average 4Mb connection. And ‘page loaded’ doesn’t just mean downloaded and rendered, it includes all Javascript initialised so the page is usable. It’s no fun if you make things easy is it?

Betfair's new site

I worked as front end developer on the team providing ‘core’ services including login and navigation. I also had a dedicated period to work purely on performance and get that load time closer to the magic 3 second mark.

2011 was, without doubt, the most intensive period of learning I’ve experienced in my professional career. What did I learn on the Betfair project? Well…

Testing

It’s no exaggeration to say my outlook as a developer was reconstructed.

I’ve enough to say on testing front end code for a future post. I’m not sure how other people found it, but for me this was a major change in approach from what I was used to and a bit of a journey, not a quick turnaround. In a nutshell -

  • It subverts your approach to coding, from being DOM focussed.
  • When you say a piece is dev complete, it should mean you also have test coverage and the tests are running green.

Agile

I hadn’t *done* Agile to this degree previously. Here’s how the experience unfolded for me -

Pre-launch

There was an initial construction phase lasting several months, to get the first release of the product out. You’re involved in a *lot* of user story workshops, definition and pointing. Plenty of “known unknowns” and a certainty there were several “unknown unknowns” lurking.

After a period of investigating each area of functionality to flush out problems and detail, we fell into a more formal scrum process – 2 week sprints drawing from the new backlog.

My whole perspective at this stage, with little experience of Agile to draw on, was from the ‘front’ of the project – get stuff defined, get to work on it. I’d had a lot of experience of working up to launches and deadlines, but little awareness of the hard yards needed to get stuff through to production in an ‘Agile’ manner, in other words…

Continuous delivery

So had I already experienced the main parts of Agile in defining and working through user stories? If we focused just on the execution of a series of sprints would it be enough for the shiny new features to drop off the conveyor belt?

Nope.

The critical factors, I learned, are

  • Automated tests – both javascript unit tests (we used Jasmine for this), and acceptance tests (Selenium 2 / Webdriver, scripted with Groovy). The tests have to be quick to write, quick to run, and must be run frequently. The results have to be visible to developers, ie “in your face” visible, not that you have to go looking for them. If you have this, you can develop, refactor and bug fix without that queezy feeling in your stomach that your next commit might introduce regressions, and bug fixing doesn’t resemble ‘whack-a-mole’.
  • A fast, stable delivery pipeline

In other words the stuff enabling the end of the production process, not the start. But you have to begin to address them, especially automated testing, right from the start.

YUI3

Before using YUI3 I thought “Why do you need more than jQuery?”.

Working with another library actually threw into relief jQuery’s strengths (especially the great API docs with embedded examples) and weaknesses (OK so it’s not even designed to structure your code, but it will, if you don’t know any better – as many jQuery starters don’t – ie. lots of nested callbacks).

YUI3 has some fantastic features -

  • the attribute system lets your objects have properties with getters / setters, onChange events and validation all built in
  • the loader system lets you split your YUI modules across separate files that load in parallel and may complete at different times, but will ensure all the dependencies execute in the correct order
  • you get helper methods for things like objects, arrays, console logging

Performance

This was a cornerstone of the project and integral to decision making from the outset. There was an SLA commitment that each page will load in 3 seconds or less. This is important – it gives the leverage needed to influence each technical and design decision made.

2 imagined conversations -

Between front end and server side engineers -
Q. Do we render HTML on the server or template it in the browser?
A. On the server – it’s faster, more robust and there’s less to download to the client

Between designers and front end developers -
Q. Do we use sliced graphics to do rounded corners in IE7/8?
A. No – use CSS3 for capable browsers falling back to square corners for IE. Would IE users rather have a slow site with a few rounded corners?

Some pointers -

  • Balance the application correctly between the server and browser
  • Consider performance from the beginning and at every step – don’t leave it to the end
  • Record ‘real world’ performance – eg. full round trip time. We rolled our own but for an out-the-box solution check out Yahoo Boomerang
  • Take a baseline using  a ‘private instance’ copy of Webpagetest. Make your optimisations, run the page again on your dev server in Webpagetest, see the difference. In other words make performance gains measurable.

So did all this work?

The site is being rolled out in the UK during early 2012 – currently some users are being diverted to the new experience which you can see at beta.betfair.com/football. In the coming weeks 100% of customers will get the new site.

Some early metrics from sessions using the new beta site -

  • Sessions that bet – up 2%
  • Bounce rate – improved 40%

Check out this presentation on the Betfair rebuild at Velocity Europe 2011.

About these ads
 
1 Comment

Posted by on January 8, 2012 in Portfolio

 

Tags: , ,

One response to “Portfolio: betfair.com rebuilt for speed

  1. mal

    February 16, 2012 at 10:05 pm

    Johnny

    Great job with speeding up the site and boy did it need it! I just gone back to IE and bet you have this down as one of the slowest browsers. pretty reliable tho.

    Any chance of trialing the new site as this is so so slow in IE…Like back to the dark ages…even when trying the Canadian site.

    Mal

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: