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?
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?
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?
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.
James Turner: Staying a little bit on security, there’s certainly been more of an emphasis over the last, pick your unit of years, about making sure that data stays secure. You see things like Open ID now and everything pretty much is SSH’d. How much of a balance do you have to keep between performance and security or can they work in concert?
Steve Souders: I don’t think there is that much tension between performance and security. The things that are making websites slow are not being done in a slow way because people are striving to have greater security. In most of the places where improvement could be made, the improved way, the higher performance way of doing things, doesn’t change your security exposure to any degree.
James Turner: You’ve been focusing a lot on the front-end. I have to say as someone who works largely on the back-end, one of the trends I’ve seen is more and more tiers being layered on, of more and more complexity. Maybe not now, but certainly a few years ago, everything was going to be SOAP over web services with Enterprise Service Buses and all of this very complex multi-tier architecture. Wasn’t that just latency waiting to happen there?
That’s not true of all websites. It’s probably true of 95 percent of the websites out there. There are certainly a number of websites where the back-end is taking a long time. It’s taking 30 to 50 percent of the overall page load time. The first thing I recommend website owners do is get a handle, get an idea of the overall page load time. And then the second thing I say is break that into two parts: the back-end and the front-end. And if you find that like most websites, your back-end time is less than 10 or 20 percent, then you’re correct in focusing on these front-end best practices. If your back-end time is 30 to 50 percent or more, then you should really start on looking at your back-end architecture.
Perhaps there are some latency delays injected there because of multiple tiers or other web services that you’re using. But there are even some best practices in that situation. For example, flushing the document early is a situation where if you do have a lot of web service requests that are required to generate your HTML document, you can still send back some of your HTML page to the browser early before you start those slow web service calls and give the user some content and some feedback and start the browser doing some work while you continue on with your other back-end requests in processing.
James Turner: One place that I see a lot of slowdown in pages has nothing to do with the site I’m actually visiting, but a lot of times, it appears the ads being served on the page. What’s the state of that right now? It seems like the people who are doing the least to optimize their performance are the ad servers.
Steve Souders: Yeah. Ads being served, third party ads being served inside of web pages, is becoming more of a problem. It’s not that it’s getting worse; it’s that everything else is getting better. When I started this work about five years ago, the percentage of problems that could be associated with ads was pretty small. Maybe 20 percent of the improvements you could make to a page had to do with ads. That’s because most websites weren’t focusing on these other best practices of spriting and ETags and caching. Well, in the last five years, we’ve seen a lot of the major websites adopting these front-end performance best practices. So it’s not that ads have gotten worse; it’s that the actual website content has gotten so much better. Now, of the bad performance practices that you see inside of popular web pages, a much higher percentage, maybe 40 or 50 percent of the problems are introduced because of third party ads.
And it’s not too surprising that that’s happening for two reasons. One is that it’s amazing that this system of serving third party ads works. Here you have two companies that have never spoken to each other. You have two sets of web developers who have never met and never exchanged any plans for how to integrate content. And yet, this third party ad service can serve up content that almost 100 percent of the time loads correctly in some publisher’s page. That’s just an amazing infrastructure that has worked for as long as it has and it continues to work, especially when you consider all of the cross browser compatibility issues that can arise.
So how is it that we were able to achieve that? Well, it’s because we adopted a framework of inserting ads, of creating ads, that’s pretty simple. And because it’s pretty simple, it’s not highly tuned. That’s one reason why we shouldn’t be too surprised that we see performance issues in third party ads. The other reason is that ad services are not focused on technology. Certainly companies like Yahoo and Google and Microsoft, we’re technology companies. We focus on technology. So it’s not surprising that our web developers are on the leading edge of adopting these performance best practices. And it’s also not surprising that ad services might lag two, three or four years behind where these web technology companies are.
I think that’s where we are. We’ve seen a lot of adoption of these performance best practices in these web companies over the last three years and now it’s time for the ad services to catch up. I don’t know what the answer is there. It’s going to require changing this huge infrastructure for serving third party ads, and that’s not something that’s easy to do. Certainly we know things that we can do to make ads serve better, to make them faster, to reduce the impact they have. But getting that to propagate across this huge ecosystem of ads is going to take a long time, a lot of evangelism, a lot of monitoring and a lot of organizational changes. It’s not something that’s going to happen overnight. But hopefully in the next few years, we’ll see progress there.
I know in the last two years, the IAB has established a performance working group and has published some guidelines for how to make ads higher performance. I think we’ll continue to see progress there. And just as we’re seeing with web companies, where companies that have faster web pages are more successful, have greater revenue, reduced operating expenses, the ad services are going to realize that too, that when it comes to ads, faster ads are going to have a competitive advantage. I think, in part, the ecosystem will take care of itself. These ad services will realize that to remain competitive, they need to be fast.
James Turner: Okay. I’m going to wrap up with one last, kind of geeky, question. What is the state-of-the-art in small good-looking images these days?
Steve Souders: Well, when it comes to images, the two experts in the industry are Stoyan Stefanov and Nicole Sullivan. I worked with both of them over in the Yahoo Exceptional Performance Group. And they, in fact, contributed a chapter to my most recent book on optimizing images. So they’re really the experts, but I think I can summarize what they would say. If you have small images with a very few number of colors, GIF is probably going to be the optimal format to use. All of these formats are supported across all browsers. In most cases though, PNG is going to be the format to choose, you can choose PNG 8 for images that are less than 255 colors or PNG 24 for images that are over 255 colors. And if you have a very high resolution image, like a photograph, JPEG is still the optimal format. So your question was about small high-quality images. PNG is going to be the format of choice, most likely, for those types of images.