Performance Matters

While a decade ago it may have been okay to go brew a pot of coffee while the computer was loading, today we all expect our software and devices to be fast and responsive. The same holds true for web performance. The load speed and responsiveness of a web application play a critical role in our choice of which applications we want to use. At the same time, how efficiently software runs plays a critical role in device battery life. No one wants to be carrying around a brick.

To build fast web applications, web developers need to be able to qualitatively measure application performance, effectively use their hardware, and most importantly, know which patterns to optimize and which to avoid.

We found that web developers haven’t had the right tools. Left on their own to guess, web developers in many cases only emphasized JavaScript performance and equated JavaScript performance with web performance.

However, web performance is truly a multi-dimensional problem. How quickly the network can download resources, how efficiently the CPU can perform web runtime operations, and the amount of available GPU memory all impact web performance. Let’s take a closer look at an example I gave in a Build presentation involving five real world travel booking web applications: Kayak, Expedia, Priceline, Travelocity, and Orbitz. All of these sites have very similar elements on the page. They all have logos, banner ads, interactive real time flight data, etc. We would expect them all to have very similar performance characteristics.

Figure 1 shows the metrics for each of these sites, anonymized here to avoid poking at anyone. We can see that even though these travel sites have very similar functions, they have all been designed very differently. Some have more bytes coming down the wire, others have more JavaScript.

Many developers would assume that the fastest site would be the one with the least number of formatted lines of JavaScript, like Site #4, or the one with the least bytes downloaded, like Site #3. However, that’s not the case. Site #5 is actually the fastest, even though it has more JavaScript and bytes downloaded. Figure 2 breaks down the amount of time each of these sites spent in the different browser subsystems, subsystems all standards-based web browsers have.

There are really two points here. It’s not just about how to most efficiently execute JavaScript, it’s about how all of the browser subsystems can most effectively work together. Without the right tools, developers don’t really know why their applications are slow and what to optimize.

Most web experts realized that there was a need for better interfaces to help developers measure their applications and write faster code. More importantly, there was a need for a forum to talk about performance problems that web developers faced and how to solve them.

At tech conferences, folks like Steve Souders and Arvind Jain from Google, Jason Weber from Microsoft, Jason Sobel from Facebook, and others started discussing performance-related issues, such as an accurate and interoperable way to measure page navigation time. These conversations soon led to the establishment of a working group in the W3C focused solely on performance. It was in the summer of 2010 that Jason Weber from Microsoft and Arvind Jain from Google were selected to co-chair the newly minted W3C Web Performance Working Group, chartered to identify and solve performance issues that developers encountered on the web.

Not everyone was certain all these competitors could work together. The first comment on the IE Blog post announcing this working group, referring to the Google and Microsoft co-chairing of the working group, was “I bet the Richter scale could pick up the tension in that room.” Fast forward to 2013 (and ignoring the fact that the Richter scale isn’t an actual instrument), and the Web Performance Working Group can really be seen as an example of the ideal working group. In just three years, Microsoft, Google, Mozilla, Intel, DynaTrace, and others in this group have designed APIs to help developers measure their web applications more accurately and precisely than ever before (Navigation Timing, Resource Timing, User Timing, Performance Timeline, High Resolution Time), and more efficiently schedule activities in web applications (requestAnimationFrame, Page Visibility, Efficient Script Yielding). Based on the conversations from the W3C Workshop on Web Performance, which this working group put together to hear from 45 performance experts and web developers from 21 organizations, the working group is now actively working on six new specifications to solve other performance problems: efficiently prioritizing the download of resources (Resource Priorities), asynchronously transferring data without blocking page unloads (Beacon), getting detailed network error and availability information (Navigation Error Logging, Resource Error Logging), marking links to be instantly loaded (Prerender), standardizing on a performance metric format (HAR—HttpArchive), and improving existing interfaces (Navigation Timing L2, High Resolution Time L2). The High Resolution Time specification went from an idea to fully implemented by all major browser vendors and fully standardized in just 11 months. That must be some sort of a record!

Looking back, the W3C was the perfect forum to bring together the top browser vendors, web properties, and performance experts to discuss and try to solve major performance issues. As web developers design more efficient web applications and browser vendors design runtimes that can execute those web applications more efficiently, we will all benefit from a faster and more responsive web browsing experience.

Beyond the Web Performance Working Group, the W3C has plans to work with the community to continue to enhance browsers, develop tools, improve education, and promote performance in W3C specifications.

Let’s keep innovating. Follow the performance conversation in the Web Performance Working Group!