I run [INDISTINCT] and that's where I first kind of met Steve, I had him come out for

this conference called The Ajax Experience to talk about all of these great stuff he

was doing at Yahoo! with respect to performance, that then went on become--to become his book

and the YSlow application Firebug extension that he's going to talk about. And he's got

some fun anecdotes about how he came up with the name and some other fun stories to share

with us. So, let's all welcome Steve from Yahoo!.

>> SOUDERS: I just want to say, every once in a while in your career, you get to meet

people who are incredibly smart and incredibly nice people too, and [INDISTINCT] is one of

those guys and, so I wanted to present you with a copy of my book, [INDISTINCT]

>> Oh, very nice. Thank you very much. Thank you.

>> SOUDERS: All right. Thanks for having me here.

>> [INDISTINCT] >> SOUDERS: I'm sorry?

>> [INDISTINCT] >> SOUDERS: I'm sentimental. I'm emotional.

That's okay. So, my name is Steve Souders. I'm the Chief Performance Yahoo!! and I understand

Doug Crockford from Yahoo! was here a month or so ago. So, it's--maybe not the first time

that someone from Yahoo! has come and done a presentation at Google. But I do have to

say, I will, you know, was wondering how this was going to go and, you know, was trying

to get myself prepared for this. And so, I just want to start off with this note, and

I don't know if anyone remembers Concentration, Ed McMahon was one of the hosts for it, yeah.

And so, anyone from the audience, want to take a guess? Sissy Spacek and someone who

looks like Peter Frampton in the movie Carrie. How many people here actually know what this

expression means or has ever used it? So, preaching to the choir might have been another

good one to use but in rebus that--I didn't think that was as interesting. So, my wife

said no one is going to know what that means. So, I thought I would look it up in Wikipedia

and bring that as well. So, it kind of mean something that's--so it's selling coal or

carrying coal to Newcastle, it's something that is may be foolhardy or pointless. And

so, given how fast Google sites are and the work that you're doing on performance maybe

there's not a lot of motivation or point for me to come and talk more about performance.

But as was shown with this expression, there can even be cases where someone comes and

surprises people by carrying coal to Newcastle and actually being able to sell it. So I'm

hoping that there are some takeaways that you can get from this performance best practices

that we found at Yahoo! and so let's dig into that. So I've been at Yahoo! for about eight

years working on various things and about three years ago some of the folks there asked

me to start a group to focus on performance. And so I called the group the Exceptional

Performance Group. And the charter is very simple. We're supposed to quantify and improve

the performance of all Yahoo! products worldwide. Such a really big charter, we scoped it down

a little bit. I kind of break performance into two areas, response time, so it's kind

of a black box perspective of it, and efficiency. So, efficiency actually is easier to correlate

to dollars. If you can do what you're doing with half the hardware, that's a lot of hardware

cost that you've saved, power consumption, rack space, but actually the area that I focused

on for the last three years is the response time. And the main reason for that is at Yahoo!,

of course, we want to reduce our hardware cost and our power cost, but really, it's

really important for us to have a very good user experience, very engaging products that

increase stickiness and user adoption. So that's where we've been focusing. And we've

also narrowed it down a little bit by focusing almost exclusively on web apps. So we're not

like trying to optimize Yahoo! Messenger. And were kind of like a consulting group within

Yahoo!. We've--we've done this at Yahoo! in other areas like security and, you know, redundancy.

We can have a small group of people; in my case, our group's about five to seven people.

We have a small group of people that focus full time on this area and can really do a

deep dive. And then we disseminate, we evangelize those best practices across the company. So,

we build tools like YSlow, I'll be showing later. We have lots of other tools. Some we've

released, some are internal. We look at a lot of data. We do research, so we'll--we'll

do--we kind of have on the job experience. We'll go out and we'll do consulting with

groups and we'll go, "Oh, wow! This is what really made this site go a lot faster. Let's

store that away as a best practice. Let's see if we can generalize it and make it applicable.

See if it's applicable to 80% of the properties," that's what we call them at Yahoo!, "80% of

the properties at Yahoo!." So we try to identify these best practices. Sometimes we have to

research the best practices. So no one's actually doing it yet but we think there's a way to

navigate through this--these set of constraints to find something that's going to accelerate

the user experience. So we do research and when we find these best practices we evangelize

them out to the--to the company. So when I started this, my background is more on backend

engineering. So, some of the first projects I did at Yahoo!, I ran the My Yahoo! team

for three years, I built an architecture that pushed all of our content, all our sports

scores and movie listings and TV listings worldwide. I wrote a caching layer between

all of our properties. So if you had a property that needed personal information, like someone's

calendar for that day, they wouldn't have to constantly bombard the calendar service

with web service calls. We could cache that in a way of updating the cache and expiring

the cache and flushing the cache. So when I was approached to start this performance

team, I thought, "Okay. Well, this is going to work well." You know, I've worked on large

scale systems trying to make them as efficient as possible, but I said, "Before I start digging

into this, if the--" we identified early on that the goal was really to make the user

experience faster. I said, "let me look at that. Let me analyze that, profile that, and

see what the long tent in the pole is." And so I found something that was kind of surprising

and I'm glad I found it right away because it completely flipped the approach to looking

at performance at Yahoo!. So this is--this is from a package [INDISTINCT] called IBM

page detailer, each of the bars is a http request. The first--you can see they're labeled,

and the first one is the html document and in this case, this www.yahoo.com with an empty

cache. And the thing that's--was very surprising to me was only 5% of the overall user wait

time was getting that html document and that includes not just the web servers stitching

the content together but the time for the request to go up and all of the packets to

come back. All of that was only 5%. And in my previous life, working on these large websites,

that's the part I was always focusing on, how can I build a better data base or cache

data in memory or change my compiler options, anything to squeeze out a couple more milliseconds.

And it turns out that I was working on the short tents in the pole. So really the long

tent is this, I call it the frontend. I think--most of the time when someone says, "The frontend

part," they might be thinking about like JavaScript executions, so this is bigger than that. It's

really--I call it frontend, everything after the html document has arrived to the browser.

Once the browser has that delivery of the--of the page, what does the browser have to do

from that point forward? I call that the frontend part. So there's certainly JavaScript html,

JavaScript CSS, parsing, JavaScript execution, but there also is a lot of other network time

involved there for all of these other http request. Most of the time there isn't, for

this other part, this frontend part, there usually isn't a lot of backend time, web server

time, because most of these are static assets that are just read off the disk. But some

of them could be hx:request or something that take a little longer. But in this case we

found that 95% of the time for a empty cache is spent on everything after the html document.

So I thought, "Okay. Well, what is it with a prime cache?" So even in that case its only

12%. There's a little white gap here in the middle where the browsers reading those cached

assets off the disk and having to reparse the CSS and JavaScript and execute the JavaScript,

and at the end there are still a handful of request for images that have changed or ads

or beacons or something. But still only 12% was that backend part, getting the html document.

So this, you know, really surprised me and I said, "Well, maybe this is something peculiar

to www." But as I looked at more and more sites, I found that this pattern held true.

That only ten to twenty percent of the total end-user experience was spent getting the

html document down. So these are the top, as of about 6 months ago, these are the top

ten sites in the U.S. And there's only one that breaks that kind of guideline and that's

Google in a prime cache. So there's only 2 http request for Google with a prime cache,

just www.google.com. And--but even here, the html—-you'd think like--I think the other

one is a beacon, maybe I was in like a test bucket or something like that, I don't know

if it happens all the time, but here the html document was still only 36%. But this is the

exception; almost every site you got to you'll find what we call the performance golden rule,

that 80% to 90% of the end-user response time, the time the user is waiting, is spent on

this part after the html document arrives. And so that's--if you really want to improve

response times that's where you have to focus. I've got three good reasons why you should

believe that. One, just the a priori probability of making an improvement is greater if you

focus on that frontend part. In your wildest dreams, maybe you could cut the backend performance

in half while you put a 5% to 10% dent in the response time in the user experience.

But if you could cut that frontend part in half, you're going to make a 40% to 45% dent,

and that's going to be huge. Users are actually going to notice that. So just a priori, you

have a better chance of making a big difference. The changes are simpler. So, you know, if

you want to change--cut half of the backend response time, you have to come up with a

new database schema, optimize your code, replicate your architecture across multiple data centers

worldwide. Huge, huge complex task. Whereas, you'll see in a minute, I'll talk about some

of these guidelines in more detail, most of them are hours or days of work. Change your

web server configuration, rearrange the page a little bit, nothing that's really that complex.

So the changes are simpler and they're proven to work. So my group has worked with, probably,

a hundred properties at Yahoo!. It's pretty easy for us, in fact there's only one exception

I can think of where we've haven't been able to go in and with just a few days work cut

25% off the response time of any website. And what's also cool is now that the book

is out and YSlow is out, I'm getting e-mails from people at small and large companies everywhere

that they've tried rules, you know, 2, 3 and 7 and they've cut 20% or 40% of the response

times. So this doesn't just happen at Yahoo! and it doesn't just happen at gigantic websites,

these rules really apply to almost any web page that you're building. So, I wanted to

talk a little bit--I'm going to have just a few slides about some research and then

we'll go through the bulk of the talk, is the rules that the guidelines we have. And

at the end I'll run YSlow and we could like look at some Google sites or any other sites

and analyze, to do kinds--kind of some live analysis. So, my coworker Tenni Theurer blogs

about most of our research on yuiblog.com, and I'm going to talk about one of these experiments

that we wrote up, the browser cache experiment, because a lot of our best practices hinge

on increase in the use of the browser's cache. But before we really could know how valuable

that was, we had to answer the question, "How many users come in with prime cache?" We didn't

know, no one knew and I couldn't find any research about that out there in the world.

So we made up this experiment where we put a little 1X1 pixel in a page, but we had to

be kind of careful about these two response headers. We put the expires in the past and

we made sure that on all the servers the file stamps was identical. So the last modified

timestamp for--no matter which server you went to, for this image, would always be the

same. And so, we know that there's going to be two possible http status codes returned

for this, either a 200 which tells us the user had an empty cache or 304 which tells

us that the user had downloaded this image previously, they have it in their cache with

this last modified header, so when they requested--when they went to the page again and requested

that image again they made a IMS, If Modified Since request or conditional git request,

they said, "I have a copy of this image on my disk that was last modified at this time,"

and the web server says, "Oh, we'll just use that one. 304 not modified, just use that

one." But those two different status codes, 200 and 304 are written into the web server

logs. So we can just go through the web server logs and find the ratios of these 200s to

304s and answer these two questions. What percentage of users come in everyday with

an empty cache and what percentage of page views happen everyday with users with an empty

cache, and we'll see that those are two different numbers. So on the first day no one has seen

this image before, so 100% of the users come in at least once a day without having this

image, they come in at least once a day considered having an empty cache, and 100% of page view

have an empty cache. But then over time, more and more users are going to get this pixel,

this image, written into their cache and as they go to the pages that image is going to

get a 304 status code response. So after--and we've run these on various sites at Yahoo!,