David Calhoun (@franksvalli) is an independent frontend developer who has been splitting his time between California and Japan. He's the community news writer for JSMag and keeps up a developer blog at davidbcalhoun.com. He formerly worked for Yahoo! Mobile.
Introduction
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:
However, we’re slowly starting to see a shift to other frontend concerns for each component of the frontend stack (HTML/CSS/JS). In particular, there’s been a great focus on JavaScript performance, a fact attested to by the popularity of jsPerf and the rise of JavaScript profilers.
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!
UI Profilers
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.
CSS Profilers
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
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.
DOM Monster
DOM Monster (by Amy Hoy and Thomas Fuchs) is intended as a JavaScript profiler companion, but remember that the complexity of the DOM (Document Object Model) will also affect UI repaints and reflows. Reducing that bloat is better for data down the wire, as well as UI rendering and JavaScript DOM access.
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.
UI responsiveness also became a concern for Flickr when they switched to YUI3 – though they took advantage of combining HTTP requests, the initial unprimed cache page load meant that a user might start taking actions before the JavaScript was fully loaded, parsed, and executed. Because Flickr progressively enhances their webpages, this means that without JavaScript ready, the user gets taken to pages that were put in place for users with JavaScript disabled. Their solution was to load a mini-library in the page to capture all events on the page and queue them back to be replayed later. Most importantly, this small library also provides a UI (a loading spinner) to give the user feedback after taking actions, even if it means nothing had happened, short of the event being queued up to be replayed later when the JavaScript is ready. Fake it ’till you make it!
Tidbits
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
- Use hardware-accelerated CSS animations over JavaScript animations where possible, but be aware of limitations (maximum sizes of 1024x1024px in WebKit). If you do end up needing to animate from JavaScript, try using requestAnimationFrame as opposed to setTimeout/setInterval
Call for a focus on UI performance
Performance is more than pushing bytes over a fence into a browser! Much of the user’s experience happens after a page loads, so we should still be concerned about the performance of a “loaded page” experience. This applies to our JavaScript, but equally as important is our CSS and its impact on scroll speed and overall UI responsiveness.
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!