Traditionally, older performance studies were concerned with speeding up things on the server side, but a few years back Steve Souders famously started research on the idea that the main performance bottleneck happened on the client side. In particular, in the way bytes were pushed to the client from the server. “Reduce HTTP requests” has become a general maxim for speeding up frontend performance, and that is a concern that’s even more relevant in today’s world of mobile browsers (often running on networks that are an order of magnitude slower than broadband connections).
These studies have been concerned with latency and bandwidth, and this still continues to be the focus of performance research today. You are probably already familiar with the standard HTTP waterfall chart:
After the page loads: the UI layer
This is all well and good, but we’re missing something: the presentation (UI) layer. Ok, that’s actually a bit of an exaggeration. UI performance tips have been disseminated throughout the community for years, but often as an aside, with bandwidth and latency concerns much more at the forefront. For instance, where CSS is even a concern, the focus is on reducing CSS filesizes. But what about expensive selectors? Or CSS that may cause the page to lag horribly?
One of the reasons UI performance has been downplayed is perhaps because of its inability to be quantified. As engineers, it’s a bit disconcerting to say that as a result of many hours of improvements, a website “feels” more responsive, or scrolls more smoothly. We would rather say “this site was originally rated at a 6/10 for responsiveness, but now it’s rated 8/10 for responsiveness!” But how on earth can we do gauge that? Well, now we can!
Recently we’ve been given the tools to measure UI performance. A new CSS profiler is available in Opera’s developer tools, and one is on the way for WebKit browsers. Here’s the new face of performance profiling:
Here’s a few tools that should come in handy when testing UI performance:
CSS Stress Test
CSS Stress Test (by Andy Edinborough) is a bookmarklet that figures out which CSS declarations are slowing down the page by selectively removing each one, then timing the scroll speed performance. The result is a bookmarklet that’s a bit jarring to watch, but seems quite useful in tracking down rogue CSS bottlenecks. Note to self: apparently applying border-radius to a ton of elements isn’t a very good idea, performance-wise.
A CSS profiler is coming to a browser near you, which will give us much more insight into the actual speed of the CSS we write, moving us forward from vague and mysterious rules. Is the universal selector (*) really that expensive? Are border-radius, box shadow, and rgba values really performance drains? Now we have ways to measure those concerns!
CSS Lint (by Nicole Sullivan and Nicholas Zakas) is a set of best practices (you may not agree with them all, but that’s ok), including a few helpful rules that target UI performance specifically. Run your stylesheets through and it’ll give you some helpful tips on what to improve.
Perception of Speed
If you think about it, all of performance is concerned with how performance is perceived by the user. While we’re mostly concerned with real performance improvements, we have to recognize the limitations and realize that we don’t always have control over bandwidth, latency, or the speed of a user’s browser. Where we’ve already done our best elsewhere, here we sometimes have to fake it. Fake it ’till you make it!
What do I mean by faking it? This might mean preloading content where possible, which is what Gmail mobile does before the user clicks on the “Show more messages…” button. After the user clicks, the content has already been loaded – it only needs to change the UI to show the new content, and this happens extremely fast. It doesn’t really matter how long it took to make the original HTTP request, because either way the experience is the same for the user, and their perception is that the interface is extremely fast. This is an example of a great marriage of good user experience design with good engineering.
“Faking it” might also mean simply being responsive and quickly showing the user a visual indicator after they take an action. It doesn’t matter how well you optimize HTTP requests or how fast the connection is – if you don’t give an indication after the user performs an action, they will likely repeat their action (a click or another tap on the touchscreen) and come away with the impression that it’s a sluggish interface.
As I mentioned before, UI performance tips have been circulating for quite a while, but they have been somewhat downplayed compared to latency and bandwidth issues.
Here’s a collection of tidbits to give you an idea of some of the concerns that are out there:
- Sprites save HTTP requests, but large sprites hog up memory
- Pure CSS3 images? Hmm, maybe later (Marcel Duran) – pure CSS3 images are awesome but perhaps impractical, as they trade less bandwidth for decreased rendering speed (it turns out that images render faster)
- Microsoft’s FishIE Tank is a nice benchmark to test Canvas rendering speed, measured in frames per second. You may even find that tweaking the viewport tag on mobile devices may speed up rendering times
- CSS gradients are faster than SVG backgrounds
- Older WebKit browsers had scrolling/rendering lag with large box shadows – not all CSS3 stuff is ready for prime time, and sometimes images might be the way to go – better UI performance at the expense of more data down the wire
- CSS radial gradients may be awesome and save the request of an image, but they might have rendering problems in some browsers, particularly Android. We save bandwidth by not requesting an image, but the user experience suffers
- Avoid IE CSS filters, as they have a performance hit
Call for a focus on UI performance
This might mean that we are sometimes better off using images instead of new CSS fanciness that’s not yet ready for primetime, and it’s up to us to weigh the cost and understand the tradeoff! It also helps us appreciate new CSS features or fancy demos while remaining skeptical of their practical use.
More than anything, if you struggled with a UI performance issue and overcame it, the world could learn from your experience! When you blog about it, you save other folks some time – time that could be spending with their families, which is definitely more important. We need more articles from folks like Marcel and Estelle, who understand that performance goes beyond saving bytes.
So get to it! But first, enjoy your time off. Happy holidays and merry Christmas!