The state of speed and the quirks of mobile optimization

Steve Souders on browser wars, site speed, and the HTTP Archive.

Google’s performance evangelist and Velocity co-chair Steve Souders (@souders) recently talked with me about speed, browser wars, and desktop performance vs mobile performance. He also discussed a new project he’s working on called the HTTP Archive, which documents how web content is constructed, how it changes over time, and how those changes play out.

Our interview follows.


What are the major factors slowing down site performance?

SteveSouders.jpgSteve Souders: For years when developers started focusing on the performance of their websites, they would start on the back end, optimizing C++ code or database queries. Then we discovered that about 10% or 20% of the overall page load time was spent on the back end. So if you cut that in half, you only improve things 5%, maybe 10%. In many cases, you can reduce the back end time to zero and most users won’t notice.

So really, improvement comes from the time spent on the front end, on the network transferring resources and in the browser pulling in those resources. In the case of JavaScript and CSS, it’s in parsing them and executing JavaScript. Without any changes in user network connection speeds, websites are able to cut their page load times in half. And that’s because even with fast connection speeds or slow connection speeds, there are ways that the browser downloads these resources that developers can control. For example, more parallel downloads or less network overhead in managing connections.

We can work around some of the network problems, but inside the browser there’s very little that developers can do in how JavaScript and CSS are handled. And of those two, JavaScript is a much bigger problem. Websites have a lot more JavaScript on them than CSS, and what they do with that JavaScript takes a lot more time. I always tell website owners: “If you care about how fast your website is, the first place to look is JavaScript. And if you can adopt some of the performance best practices we have around JavaScript, you can easily make gains in having your website load faster.”

Why do load times vary by browser?

Steve Souders: Even if you’re on the same machine, loading a page in one browser vs another can lead to very different timing. Some of the factors that affect this difference are things like the JavaScript engine, caching, network behavior, and rendering.

I don’t think it’s likely that we ever will see standardization in all of those areas — which I think is a good thing. If we look at the competition in the last few years in JavaScript engines, I think we would all agree that that competition has resulted in tremendous technological growth in that space. We can see that same growth in other areas as the focus on performance continues to grow.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

Are we in the middle of a “speed arms race” between browser developers?

Steve Souders: We’re certainly in a phase where there’s a lot of competition across the browser teams, and speed is one of the major competitive differentiators. That’s music to my ears. I don’t know if we’re in the middle of it, because it’s been going on for two or three years now. Going forward, I think speed is always going to be a critical factor for a browser to be successful. So perhaps we’re just at the very beginning of that race.

Starting around 2005 and 2006, we started to see web apps far outpacing the capabilities of the browsers that they ran in, mostly in terms of JavaScript and CSS but also in resource downloads and the size of resources. I’ll be honest, I was nervous about the adoption of AJAX and Web 2.0, given the current state of the browsers, but after that explosion, the browsers took notice, and I think that’s when this focus on performance really took off. We’ve seen huge improvements in network behavior, parallel downloads, and JavaScript performance. JavaScript engines have become much faster, and improvements in CSS and layout — and some of the awareness around these performance best practices — has helped as well.

We’re just reaching the point where the browsers are catching up with the rich interactive web apps that they’re hosting. And all of a sudden, HTML5 came on the scene — the audio tag, video tag, canvas, SVG, web workers, custom font files — and I think as we see these HTML5 features get wider adoption, browsers are going to have to put even more focus on performance. Certainly mobile is another area where browser performance is going to have a lot of growth and is going to have a critical impact on the adoption and success of the web.

What new optimization quirks or obstacles does mobile browsing create?

Steve Souders: As large and multi-dimensional as the browser matrix currently is, it’s nothing compared to the size of that matrix for mobile, where we have even more browsers, hardware profiles, connection speeds, types of connections, and proxies.

One of the biggest challenges developers are going to face on the mobile side is getting a handle on the performance of what we’re building across the devices we care about. I talked earlier about how on the desktop, without any change in connection speed, developers could work around some of the network obstacles and get significant improvement in their page load times. On mobile, that’s going to be more difficult.

The connections on mobile are slower, but they’re also constrained in other ways. For example, the number of connections per server and the maximum number of connections across all servers are typically lower on mobile devices than they are on the desktop. And the path that HTTP requests have to take from a mobile device to their origin server can be much more convoluted and slower than they are on the desktop.

So, network performance is going to be a major obstacle, but we can’t forget about JavaScript and CSS. Mobile devices have less power than desktops. The same amount of JavaScript and CSS — or even half the amount of JavaScript and CSS — that we have in the desktop could take significantly longer when executed on a mobile platform.

What should companies be doing to optimize mobile browsing?

Steve Souders: Developers are in a great place when it comes to building desktop websites because there’s a significant number of performance best practices out there with a lot of research behind them and a lot of tooling and automation. The problem is, we don’t have any of that for mobile. That’s the goal, but right now, it doesn’t exist.

When I started talking a year or so ago about switching the focus to mobile performance, most people would respond with, “Don’t the best practices we have for desktop also apply to mobile?” And I always said the same thing, “I don’t know, but I’m going to find out.” My guess is that half of them are important, a quarter of them don’t really matter, and a quarter of them actually hurt mobile performance. Then there’s a whole set of performance best practices that are really important for mobile but don’t matter so much for the desktop, so no one’s really focused on them.

In the first few months that I’ve been able to focus on mobile, that’s played out pretty well. There are some things, like domain sharding, that are really great for desktop performance but actually hurt mobile performance. And there are other things — like “data: URIs” for embedding images, and relying on localStorage for long-term caching — that are great for mobile and don’t exist in any of the popular lists of performance best practices. Unfortunately, companies that want to invest in mobile performance don’t have a large body of best practices to refer to. And that’s where we are now, at least that’s where I am now — trying to identify those best practices. Once we have them, we can evangelize, codify, and automate them.

What is the HTTP Archive and how can developers use it to improve site speed?

HTTP Archive logoSteve Souders: Over the last five years, we’ve seen a lot of interest in website optimization — and websites have changed over that time. Unfortunately, we don’t have any record of what those changes have been, how significant they’ve been, or what areas we’ve seen change and what areas we haven’t seen change. The purpose of the HTTP Archive is to give us that history.

It’s similar to the Internet Archive started by Brewster Kahle in 1996 — the Internet Archive collects the web’s content and the HTTP Archive archives how that content was built and served. Both are important: The Internet Archive provides society with a record of the evolution of digital media on the web, and the HTTP Archive provides a record of how that digital content has been served to users and how it’s changing, specifically for people interested in website performance.

This project will highlight areas where we’ve seen good traction of performance best practices and where we haven’t. Another insight that will come from this is that it’s important, for example, for browser vendors and JavaScript framework developers to develop tools and features that can be adopted by developers to improve performance. It’s also important to provide support for development patterns that are currently popular on the Internet. We can’t ignore the way the web is currently built and just author new features and wait for developers to adopt them. The HTTP Archive will provide some perspective on current development practices and patterns so browser developers can focus on performance optimizations that fit with those patterns.

Image transfer size and image request chart
Click to enlarge and see more trends data from the HTTP Archive.

Right now, there aren’t that many slices of the data, but the ones that are there are pretty powerful. I think the most impactful ones are the trending charts because we can see how the web is changing over time. For example, we noticed that the size of images has grown about 12% over the last five months. That’s pretty significant. And there are new technologies that address performance issues like image size — Google has recently released the WebP proposal for a new image format that reduces image size. So, the adoption of that new format by developers and other browsers might be accelerated when they see that image size is growing and will consume even more bandwidth going forward.

Associated photo on index pages: Speedy Gonzales by blmurch, on Flickr

Related:

tags: , , , , ,

Get the O’Reilly Web Ops & Performance Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Edu

    To read