Performance snapshot: Ryanair’s 2015 redesign
Discount airline Ryanair recently updated their site, which has seen some vast design improvements. The new site has a far more reserved colour palette, clear buttons and labels, strong typography — and it’s also responsive to boot.
You only have to look back to 2009 to understand that Ryanair.com has come from some very humble beginnings.
Being vaguely aware of the software that powers the airline industry, I’m almost certain that there were some serious challenges in working on this redesign—unfortunately, it looks as though performance was one of them.
After chatting with Jake and a couple of others on Twitter, I decided to add Ryanair.com to my Calibre account to see what stats and graphs would be able to tell me.
Ouch. When I looked into the requests being made, it didn’t look as though anything unusual was happening. The site is large, but being as the industry average total page size is now well over 2000KB (as reported by httparchive), it didn’t seem completely out of control.
Webpagetest’s CPU utilisation graph showed that something much more sinister was happening.
When a site causes such signifigant CPU spikes, it could be one of a few things:
- Excessive use of animation (or non-hardware accellerated animation)
- Intensive JavaScript — iterating over a large DOM, audio analysis, endless loops
- HD Video playback
- Expensive CSS selectors targeting a large amount of DOM elements
Being that there wasn’t any obvious runtime performance issue, and we knew that the TTVC (Time to visually complete) was slow, I started to investigate the network timeline.
There was a total of 342kb of CSS being delivered over the wire using GZip. Once those stylesheets are uncompressed? Totally different story—2.88MB.
My mind immediately ticked over to Jon Rohan’s excellent slide deck “Github’s CSS Performance”, in which he demonstrated how a page with a large DOM (GitHub’s code diff pages) ground to a halt due to complex selectors. If you’ve not seen it already, drop everything and read it now. I’ll wait here.
I decided to dive in to see where the bloat in the CSS was coming from.
When I uncompressed the CSS using Chrome’s pretty-print feature (I tried two online css-unminifiers, but they both crashed), I saw some pretty horrifying selectors.
As you can see, there appears to be a few things going wrong here:
- Heavy use of selector nesting (At a guess, I’d say that the sass inception rule has been broken)
- Overly complex selector usage (:not used three times on one element when a more simple selector could be used — alongside a convention like BEM/SMACSS)
- The wall of selectors that apply to a single property suggest that the codebase extensively uses SASS `@extend` (Which is often a bad idea)
How could this be avoided?
Firstly, I’d outlaw usage of `@extend` altogether — It’s usage causes more headaches than it’s worth. For those who are carefully watching SASS output, no sweat.
Many teams have a ‘build screen’ in their office that shows CI build status, live customer usage graphs and other interesting statistics about the codebase. I’d have CI generate a specificity graph, and push that to the build screen for the whole team to see.
Finally, I’d set a file size budget using Calibre, then add a notification to either email the entire team when the budget had been blown, or post a message to Slack.
Final thoughts
Ryanair.com makes many invidual requests for JavaScript resources (38, in fact). As others have pointed out HTTP2 or SPDY would help quite a lot, as individual resources would be sent through a single connection.
Being that HTTP2 or SPDY aren’t in use on Ryanair, it’s safe to say that concatenating the scripts into a `bundle.js` would be a quick and relatively painless way of making a vast improvement.
Want to start tracking and improving performance? Give Calibre a shot. Need some help getting started? Talk to me about a performance audit of your site.
