Everything you wanted to know about web performance but were afraid to ask, part 1
Network World invited Strangeloop president Joshua Bixby to illustrate exactly where web performance pains occur — from server time and round trips to browser differentiation and user expectations. (Make sure to watch part 2, which covers the solution landscape, including content delivery networks, application delivery controllers, and front-end optimization solutions like the Strangeloop Site Optimizer.)
Joshua Bixby: Hi, my name is Joshua Bixby from Strangeloop. I’m here today to talk about web performance, particularly web performance when it comes to public facing websites. I want to talk about the problem. So, I want to talk about the problem in the context of a user. So, here is a browser, a customer at their computer on a browser. Let’s use IE7 here as an example. There are many browsers in the world and one of the problems in the modern world is the proliferation of browsers. Let’s start simple and we’ll go more complex. This customer makes a request for example.com, that request gets routed through the Internet and into the data center. In the data center that request first goes to a web server, that web server starts to stitch together the page, all of the dynamic elements makes calls to a database, starts filling up that page.
There is time that’s taken here what we call server time, backend time. That request then gets sent back to the user, I’ve now stitched together this page and that page is going to come all the way back to the user. So, I have time here that’s taken between when the user makes a request for the page and when the server serves it back. And I’ve got time when the server is actually stitching the page together. Now, I get to the browser and in this case IE7 like all browsers is quite, both an intelligent animal and a very linear, very simple animal. What it does, is it takes that page and start reading it just like you would from left to right and top to bottom. Every time there is a request for an object and again remember most web pages are composed of many objects, started at two about 10 year ago now most pages have somewhere between 80 and 200 objects.
So, when you see and request for an object, something like, let’s say an image, you open up a highway all the way back to the server here and you request it. You say “hey I would like to get that image.” So, you make that request and the server then serves that back to you, pretty simple. The next object that encounters, it opens another highway. In the case of IE7 two highways are open. So, I’ve got one highway here and one highway here. Those highways are accessible between you as the browser and here the data center. You make request back and forth across those two browsers. Now, there are some limitations to these highways. One, is only one thing can be going in one direction at a time. So, if I make a request everything else stops, going back and then when the server responds nothing is coming this way.
Now, imagine if I’ve got 80 to 200 round trips or request in order to stitch together this page and render it, I’m making calls back and forth, back and forth, again 80 to 200. There are a lot of requests here, back and forth, back and forth. Now, it’s not that simple, not only do I adjust those two highways in the case of IE7, I also have some wide loads, if we use that terminology they are going to come across, Java Script is the biggest culprit. Sites usually are made up of images, CSS files, Java Script files occasionally flash files maybe others but this is the bulk of those request, a bulk of that 80 to 200. When a Java Script file is called for, and I make a call, “hey give me server Java Script file, you know, Java Script one,” the server says “okay, guys stop everything, I’m delivering your Java Script, this is my wide load,” I take up both of these lanes and stitch that over.
Why is that important? It’s important because as I said we’ve got this time between the browser and the server that has to be traversed. This is the speed of light, it’s not as if this is slow or hampered, I mean there is some packet loss and some jitter but ultimately this is a pretty refined machine but it takes time from Los Angeles to New York, it’s taking 50, 60 milliseconds for each of these trips. So, the number of trips that I have in the proliferation of trips is important. If we look at a graph of what that has looked at overtime, the number of trips is exponentially increasing. Started as I say in 1999, the average page has two trips in 2010, the average is 80 and when I say average most of our sites that we look at today have well over a 150 trips from the server to the browser.
So, that’s one of the problems with the modern web. Another problem, another big problem is what we started with here. So, I want to talk about the browser side of this. So, we talked about the fact that in this example I was using IE7 and I pointed that out deliberately because each browser has its own unique way of rendering pages, of actually bringing pages to you. So, I’ve got IE and in that I’ve got a number of flavors, six, seven, eight soon to be nine, I’ve got Firefox, you know, version two and three and 3.5. I’ve got Safari, I’ve got Chrome et cetera, et cetera, et cetera, I’ve got browsers for iPads, iPhones, all of these browsers consume pages differently.
I like to think of them, well some of them, not all of them, as really fine tuned racecars. And like every fine tuned racecar you need racecar-type fuel. Well, in the example we just talked about, remember the server is in the modern world for the most part from most organizations are serving the same thing to every single one of this, every single one of this gets the one size fits all package from the server. So, when we talked about that HTML coming over and all those objects it’s the same every single time for every single browser for the most part. That’s a problem because these all have special ways to optimize for performance that are being taken into consideration. So, you sort of take one size fits all, lowest common denominator approach here.
So, I just want to review quickly before we talk about how to solve this problem. So, I’ve got a number of issues, one of the issues, of course, is that the server takes time to generate a page. So, one we’ve got server time, two we’ve got the number of round trips, which is a big issue and the distance between those round trips, imagine this problem is aggravated in the case of international customers. Some of our customers, for example, are 200 to 300 milliseconds. Three, we have the fact that it is a multi browser world and that multi browser world means the one size fits all or lowest common denominator approach, I’m going to do just a lowest thing that all these browsers support, is a problem.
And the last problem that we have today is really a problem of user expectation. If we look at the user expectation graph over the last 10 years we come here in 1999, users expected a site to load in 8 seconds. Since then, you know, a new study came out in 2006 where it was 4 seconds. Recent study this year in 2010, 2 seconds. So, you have to ask yourself is your site loading in 2 seconds, is your site actually doing what users expect because if they don’t you’re losing money. I want to talk about how you lose money and then I’m going to talk about solving the problem.
So, there have been many studies that have been conducted over the last two years, ground breaking studies, where organizations have taken traffic and split it into two piles to hit their website. So, here is a user and you either get fast or slow. Now, what’s important about the distinction between fast and slow for example when Microsoft did the study, Microsoft did it and fast for them was 100 milliseconds faster. Fast for Google was for 400 milliseconds faster. So, what’s important as we look through, this is we’re not talking about a site that’s loading in 20 seconds here, you know, 5 seconds here and 20 seconds here, that’s not what we’re talking about.
We’re talking about is incremental improvements and so I challenge you when you think about your own sites loading can, you know, is there a possibility of 100 millisecond gain, 400 millisecond gain, we often find that there is. Users come in and they are segmented into either the fast group or the slow group, A or B. And they are served exactly the same page from the server except that in one case it’s fast and one case it’s slow. If we look at the fast group, this group here those that were improved by, you know, a 100, 400 milliseconds what we see is, for example, in the case of Google we see a dramatic increase in conversion, in revenue, AOL found, for example, there top users surf four times more pages. If you think of yourself as a content site four times more pages, four times more ads, four times more likely to make money. If we look at some of the sites like Microsoft, they found that, they found that they made five percent more revenue per customer. If you look at Shopzilla they found twelve percent higher conversion. If you look at these numbers, again, this is good science, the only thing that’s differ between these two is in one case it’s fast, in one case it’s slow, huge and dramatic business improvement.
If we look at how that business improvement manifest itself, think about your funnel. You are either making money through e-Commerce or you’re making money through ad clicks or content, how do people get into a funnel? Well, they get in a variety of ways, one of the most important ways is through natural search sort of SEO. One thing that we know is a direct relationship between SEO and performance. Google just announced that when your site is faster you will have a higher ranking in Google. That tells you something about how important performance is. Now, that you are in the funnel we see and we talked about this day well, increased page views. So, when my site is faster, I also increase page views. When my site is faster I increase conversion.
So now, more people are coming out of this funnel, they are staying in here, my bounce rate is going down, they are not bouncing out and they are converting. So, I want to talk about one why – how we can solve this problem? Because I think that’s really the next step. So, we have this problem, I want to look at the existing solutions in the market and how they are solving it and how we believe that our solution at Strangeloop, but more importantly the idea of transformation and how we need to think this market, is important.