letting people come in and sit up front, so I hope we can do that.

I'm really excited to see everyone that showed up, but I have a cold shower announcement

to make. I'm not giving anything away. So although that's not entirely true. I'm

giving away information and knowledge, but nothing that physically you can take home

and give to your kids if that's what they're expecting.

So I'm going to talk about HTML5 from a performance perspective, but first I'm going to start

off and give a little background on my work in working on Web performance and kind of

the motivation. I think probably a lot of people -- how many people here build Web sites?

Yeah, okay, great. So I think there's something in the DNA of

engineers in general, and especially programmers, to be efficient and optimize.

I think as developers we all like our code -- we feel proud if people -- if we can say

about our code that it's really fast and efficient. And so at the beginning I'm going to talk

about how we can try to work to instill that interest and buy-in for performance across

other parts of the organization outside of engineering.

So there will be a little preamble on that and then we'll dive into the HTML5 stuff.

I just want to mention the slides are up on my Web site, stevesouders.com. If you go there

there's a link to it. You can check that out. Okay. So let's get started -- oh, the other

thing I want to mention is really more than what I say and more than the words on the

slides, I really want people to pay attention to the photos in the background of the slides.

[ Laughter ] >>Steve Souders: Come on, we're going to -- loosen

up a little bit. Let's go. I mean, like the story of my life, like I

take slow things and make them fast, like is that very appropriate or what?

I need more feedback. [ Applause ]

>>Steve Souders: Yeah, okay, there we go. I worked at Yahoo for a long time, eight years.

I was going to be there one year and I was there eight years. And about four and a half

years ago I joined Google, which was really my goal when I first started on Web performance

because I knew the people at Google really cared about making things fast, and it's true.

So I've been there four and a half years. I do mostly open source stuff, so I did -- I

created YSlow, Cuzillion, Sprite Me, Hammerhead, Browserscope. Lindsey Simon now runs that

project, very successful project. Jdrop, which is a great concept, but not such a successful

project, but you should check it out. HTTP Archive, another one I don't have time to

talk about today, but check it out, HTTParchive.org. I wrote "High Performance Web sites," "Even

Faster Web sites." I taught at Stanford based on the books and

I run the velocity conference. Oh, I have to update. We just had it this week in fact.

I just finished that on Wednesday. So I've been doing this performance stuff

for quite a listening time now, seven years, I think, but when I started back in 2004 I

kind of felt like the lone voice in the woods. So really I'm sure there were people that

were working on it back then, but when I searched for information about making Web sites faster,

I really didn't find very much. There was a great blog post from David Hyatt that actually

really opened my eyes to where I should look for making Web sites faster.

I should mention that when I talk about performance, I mean that from the end user's perspective.

My goal when I started this in 2004 was to make the user experience fast.

Now, there's another aspect of performance which I think of more as efficiency or scalability

on back end servers. How can we handle 10X the current number of users with the same

hardware? Those kinds of efficiency optimizations are also performance, but when I say performance,

I really mean speed, speed of the user experience. So when I first started working on this there

really wasn't that much information out there and I would try to go -- I started documenting

things, writing books, blogging, trying to go to other teams and convince them to focus

on performance. And it's kind of like QA or writing unit tests.

Like try to sell unit tests -- time to build unit tests to someone from marketing or sales.

That's kind of hard to do, because it's hard to visually see the benefit of that.

So at the beginning it was kind of the same thing with talking about make the Web site

faster. Yeah, we need like a couple of people to work for at least six months. And you won't

see anything different on the site, it will just feel faster. And believe me, that's really

critical. And they're like no, really we want you to

add more flash. [Laughter].

>>Steve Souders: And so fast forward to 2010, future of Web apps. We have Fred Wilson. How

many people know Fred Wilson? Like one of the most prolific bloggers. He's

the number one VC out of New York City, out of Union Square, very techy guy. But really

his business is investment, funding startup companies.

Here he is speaking at a tech conference about his 10 golden principles of successful Web

apps. What's number one? Speed. He says, First and foremost we believe that speed is more

than a feature, speed is the most important feature.

And he goes on to talk about with their portfolio companies they track all of the company's

performance, speed, page load time for real users. And that in their experience the data

shows that when the speed drops off, the success of the business drops off.

And that's why they do this for all the portfolio companies that they work with.

And so I think that's to me like Web performance has arrived. We have a VC talking at a tech

conference about speed, like this was beautiful to me. I start almost every slide deck with

this slide. And actually, a partner of Fred's spoke at

the Velocity conference this week. And in addition -- if that's not enough to

have the number one VC out of New York City talking about performance, I'm going to run

through a bunch of case studies here that correlate performance speed to the success

of the business. So here's -- about two years ago Bing and

Google Search got up on stage at the same time and talked about experiments they had

run. Bing introduced intentionally a delay in serving search results. They took it up

to two seconds. At a two-second delay they saw all their goodness metrics drop off. Most

significantly revenue per user dropped off four percent.

And of course, these companies are doing this on a very small sample size.

So Google took this up to 400 milliseconds at the max. Didn't see that much dropoff in

searches per user, although at Google scale that's a fairly significant dropoff.

The thing that was really interesting about this study was after they removed the delay,

they kept that user group segmented and tracked their usage. And it took I think six weeks

for the usage, the searches per day, and other goodness metrics, to resume where they were

before the experiment started. So the user's awareness of what the experience

is like is something that gets ingrained and lives with them and it takes a long time to

build that and to recover from delays. So it's important to stay on top of keeping your

Web site fast. And Yahoo ran a similar study. And for full

page traffic, that means traffic where the onload event actually fires, a 400-millisecond

delay saw a five to nine percent dropoff in traffic.

Here Mozilla -- this is about a year old. Mozilla, when you want to upgrade to Firefox

and you're in Internet Explorer, you get the IE landing page, and they made that IE Firefox

landing page 2.2 seconds faster, and they saw a 15% lift in Firefox downloads. So for

them that's their business metric, being a nonprofit.

And this was a seminal study from Velocity a few years ago. Shopzilla did a tremendous

performance effort, taking their site from seven seconds to about three seconds, and

they saw conversion rate go up seven to 12 percent depending on the country.

This is very significant. They saw the unique users from search engine marketing more than

double. And this was the first study that showed another benefit in addition to the

business metrics is operating costs going down.

So here we have the number of servers needed to run the Web site after this optimization

dropped. And that kind of makes sense because like one of the optimizations is connecting

scripts together, so instead of making seven requests to my server, I'm only making one.

Turn on Gzip so the amount of time it takes for the response to get off the server box

is lowered and so the server can handle a higher QPS.

And then following that a good friend of mine, Bill Scott, when he was at Netflix, they had

-- they didn't have Gzip turned on for some reason. I can go into it after if people want

to ask. And he turned it on one day and the [Indiscernible]

said the Web site is down, all we're serving is the error page.

And he said why do you think that? And they said the traffic in our data server

has dropped in half. He said, Nope, we're serving everything, it's

just that we turned on Gzip. So this is probably six figures a month in a data center that

they saved. Pretty significant. Here's another example, Edmunds.com turned

on -- added an expires header so that their resources through their CDN could be cached

and they saw their CDN traffic drop by a third. So again, this is a six-figure maybe high

five-figure savings per month from CDN costs. And then not that recently anymore, this was

about a year and a half ago, Google announced that speed or latency was going to be taken

into consideration for page rank. And that was caveated, it's one of two hundred signals,

it only effects about one percent of search results, but still it's a consideration and

page rank is really important. All of these things about a year, year and

a half ago I saw coming together and so I coined a new catch phrase for this emerging

industry called WPO. It stands for Web Performance Optimization. And actually as I mentioned,

I keep mentioning, we just had Velocity this week, there were a number. Sequoia, Battery

Ventures, Excel, Union Square were all there. This industry is really growing up. There's

a number of startups in this Web performance space now.

And the elevator pitch is it drives traffic to your site. We see that with search engine

marketing, with page rank. It improves the user experience. You would think that making

Web sites faster the user would get in and out more quickly, and it's just the opposite.

All of these studies show that page views per session, session length all increase because

the users are having a better experience. It increases revenue. We saw stats on that

with conversions, downloads, and it reduces operating costs.

So this all sounds pretty good, right? Web PO is really taking off.

All right, that's the preamble. How many people here think fast Web sites are good?

All right. So hopefully if you're having trouble selling that -- if this is stuff that you

want to work on and you're having trouble selling that back home, you can take some

of these case studies and show people back home that this is a good investment. You'll

actually get a positive ROI. And maybe these will give a little guidance on what you can

track on the business side to actually correlate performance improvements with the goals of

the business. All right. So let's transition into the meat

of the topic. I don't want to debate about what HTML5 is. There's the spec. I also mean

CSS3. It's the new stuff. So I'm going to highlight a few things around

HTML5 and CSS3 that I think are really important to pay attention to from a performance perspective.

So the first is if you want to optimize something you need to be able to measure it. And right

now what we'd really like to measure is the user's perception of speed. Currently there's

no JavaScript handler for brain activity. So what we've been using as an industry -- as

a proxy for that is the window onload event. Now, the problem with that is, for example,

if I do a Google search and I click on a search result that takes me to Whole Foods, and I

want to measure -- from Whole Foods' perspective, they want to know how long it took for the

user to click that link to when Whole Foods was ready. And the problem is tracking the

start time. How do you track the time that the user started by clicking on that link?

Because that's the user's perception time. And what you can do is at the top of the Whole

Foods page you can put a script lock that takes a time measurement, but that totally

ignores the time it takes for the request to go up to the Whole Foods server, for it

to stitch together all of the content and send that back down to the browser.

So about two years ago Google and Microsoft formed this Web performance working group

as part of the W3C, and the first task was to create the Web timing spec, which is actually

three specs, navigation timing, user timing, resource timing.

How many people here use navigation timing to measure Web sites?

Good. It's not good that there were so few hands up. It's good because I'm going to talk

about it a little bit. So those of three and I'm going to talk about

each one in a little bit more detail. They're also working on a few other specs, page visibility

I'll touch on quickly. Script-base animations I'm not going to spend too much time on, but

people are doing a lot of animation with JavaScript and they're working on making that better.

And efficient script yielding, since the browsers are single threaded, if you have long running

JavaScript it can really degrade the user experience. So what can scripts do to mitigate

that. But let me talk about the timing specs. So

navigation timing actually is out. The spec is done and it's available today. If you look

at window.performance, there's this timing object. And you can do things like from the

timing object you can get the navigation start and the load event end, take the difference.

And the nice thing is that the Web timing spec gives us two main things. This is the

first one. This is the time at which the -- the epic time at which the user clicked on that

link on Google. So now the user can -- the Web site owner can get the full time from