Steve Souders: Making Web Sites Faster in the Web 2.0 Age

How huge JavaScript libraries, rich content, and lame ad servers are slowing the web down

by James Turner | comments: 9

As much as anything else, a user's impression of a web site has to do with how fast the site loads. But modern Web 2.0 websites aren't your father's Oldsmobile. Chocked full of rich Flash content and massive JavaScript libraries, they present a new set of challenges to engineers trying to maximized the performance of their sites. You need to design your sites to be Fast by Default. That's the theme of the upcoming Velocity Online Conference, co-chaired by Google performance guru Steve Souders. Souders is the author of High Performance Web Sites and Even Faster Web Sites, and spent some time discussing the new world of web site performance with me.

James Turner: There's been an evolution of the whole area of web performance, from the old days when it was all about having a bunch of servers and then doing round robin or just spreading the load out. How is web performance today different than it was, say, ten years ago?

Steve Souders: Well, what's happened in the last five years or so is that Web 2.0 and DHTML and AJAX has really taken off. And that's really been in the last two years. Five years ago, we started seeing a lot of flash and bigger images. So basically what's happened is our web pages have gotten much richer, and that also means heavier. There's more content being downloaded, more bytes. And then in the last two years, with the explosion of Web 2.0, we're seeing not only a lot more bytes being downloaded into web pages, but we're seeing that that involves a lot of complex interaction with JavaScript and CSS. And so whereas maybe five or ten years ago, the main focus was to build back-end architectures that would support these websites, we're seeing today that we need a lot more focus on the front-end architecture of our websites and web applications.

So that's where Velocity comes in, and my work comes in. Whereas ten or twenty years ago, you had people looking at collecting and evangelizing best practices for back-end architectures like databases and web servers, Velocity and my work is about identifying and evangelizing best practices for building really fast high-performance front-end architectures.

James Turner: I know, as someone who's been doing AJAX development, AJAX is a very different kind of paradigm for how you're interacting with the server. It's a lot more chatty. Are the current generations of web servers really designed for that kind of interaction?

Steve Souders: I think that the chattiness of AJAX applications isn't really the issue with regard to performance. I mean, anything can become an issue, but looking across the top 1,000 websites in the world, that's not the issue. The issue is that these web applications that do AJAX require a lot of JavaScript to set up that framework on the client, inside the browser. And to set that up, to download all of that JavaScript and parse it and execute it just takes a lot of time. A user is downloading complex photos or mail or calendaring application, and before they've even done any chatty AJAX request, they're just waiting for the application to actually load and start up. That's the frustrating period, you just want to get in and start working on your slides or reading your mail, and you're waiting for this start up to happen. Typically, once these AJAX frameworks have loaded, the AJAX work that we're doing in the background is not that big of a problem either from a back-end perspective or from the client side perspective.

James Turner: One of the things we see a lot these days is people using libraries like YUI or Google's libraries or JQuery . They have compressed versions, but they're still pretty large. To what extent do you think there's a need to really go in and pick and choose out of those libraries?

Steve Souders: Well, myself personally, I do that frequently because I only need usually one small feature, like I need a carousel or I need a drop-down menu or something like that. And I'll go to the work of pulling out just the code that I need. But I'm working small website projects. If you're building a whole web application, you're probably using many parts of these JavaScript frameworks. There still might be some benefit in pulling out just the pieces that you need. But that's extra work. And when you need to upgrade, that's the likelihood of introducing bugs or other problems. So certainly, I wouldn't avoid doing that. It should be evaluated, pulling out just the JavaScript that you need from the frameworks so long as the licensing even supports that.

But something else that helps address that problem is the Google AJAX Libraries API. This is where Google is actually hosting versions of JQuery and Dojo and YUI and Google's Closure JavaScript framework and Scriptactulous and EXT and others. What happens is you can have multiple websites that don't have any interaction with each other, Sears.com and WholeFoods.com, but they both might be using JQuery 1.3.2. And if they're both downloading that library from the Google AJAX Libraries API, then the URL is exactly the same. So a user that visits multiple of these websites only has to download that JavaScript once during their entire cache session. That further mitigates the need or motivation or benefit of pulling out just the parts that you need.

At first, I didn't think there would be that much of a critical mass around these people that would adopt the Google AJAX Library CDN and the actual version numbers of these JavaScript frameworks, but it's actually taken off really well, a lot of websites are using them. Users are actually getting this critical mass benefit where when they go to some website, Sears.com, that's using JQuery, they already have that in their cache from a visit they made a previous day to a different website. So I think in general, I would recommend to developers that they not change the JavaScript frameworks they're using. And if they're using a framework that's hosted on Google, download it from there. It's hosted on Google's infrastructure, so it's going to be fast, reliable, and users will actually get the benefit of having a greater probability of the framework being in their cache, because multiple websites are taking advantage of loading it from there.

James Turner: I have to put my security hat on for a second and ask, when you get into a situation like that, the flag that comes up for me is if someone managed, by some kind of an injection fake, delivery a version of a library that had vulnerabilities so that it appeared to be coming from Google, you could get into a situation where someone would be using a poison library. Do you think that's at all a realistic concern?

Steve Souders: Well, I think it depends on who's doing that. I work at Google so I don't want to come off as sounding like a fan boy who's only going to say great things about what Google is doing. I'm as cautious as the next person with what passwords I use and what information I give to any web company. But when it comes to something like this, I've built stuff that's running on Google App Engine or Amazon AWS. It's always possible that these big companies, these big web hosting providers are going to go down. But there's probably a greater chance that my website is going to go down than Google or Amazon. And the same thing with security. There's probably a greater chance that my website is going to be hacked than Google or Amazon. So I think it is a possibility. But I think the odds are pretty small of that happening. And that would not be a concern that would stop me from taking advantage of these services because of the performance benefits I get from them.

(continue reading)