Steve Souders

Steve’s website

Steve is the author of High Performance Web Sites and the creator of YSlow, the Firebug extension. Now working at Google, Steve discusses the next set of best practices he’s developed, including advanced techniques for loading JavaScript, where not to place inline scripts, and the importance of using multiple domains to improve web performance.

Using YSlow, walking through the Alexa top-100, the average grade is D. However, a year ago when Steve was here, the grade was an F. So maybe it’s getting a little bit better.

The evangelism efforts that have led up to a new set of research over the last year of so. Dipping into that research, 4 or 5 new best practices that are coming up.

End with punchline stats that will help us chant “performance” “performance”

IBM Page detailer, you can get a free version. However, you can’t get the paid version anymore. New favorite packet sniffer HTTPWatch.

Case Study: iGoogle

iGoogle has 25 connection requests. Because of limitations in the browser that prevent concurrent loads, there’s a “stair step” pattern that slows down the load.

Sounders used to work on big back-end systems, and mostly focused on web server time. However, for iGoogle it turns out that server time is only 9% of time from a user perspective. However, the other 91% is the front-end time. This front-end time does include network time as well. However, Steve calls it front-end time because there are ways to structure the code to address these problems.

The importance of frontend performance
17% – back-end
83% – front-end

Time spent on the frontend
aol.com 97%
ebay.com 95%
facebook.com 95%
google.com/search ~90%
more….

14 Rules

• Make Fewer HTTP Requests
• Use a CDN
• Add an Expirese Header
• GZip components
• Put Stylesheets at the bottom
• More…

YSlow and Firebug seemed like it could be bundled. So he met with Joe Hewitt (Firebug) and decided to integrate it with Firebug. YSlow evolved as Bookmarklet, and then it was a Greasemonkey extension, and then finally integrated into Firebug. Steve’s assessment was “maybe even 10,000 people will use this”

At last count, there has been 700,000 downloads of YSlow, and 10,000 daily actives.

Steve Sounders also worked with Time O’Reilly to start a Velocity conference. Kicked it off last year, and it was a huge success. There’s a conference in San Jose coming up this year, 2nd annual.

Also, Stanford released a series of videos, but you have to pay for them.

There are also O’Reilly masterclasses. Steve Souders is doing it, Crockford (teaching about JavaScript) and a few others. Steve also wrote High Performance Websites (O’Reilly) and Even Faster Web Sites (O’Reilly).

• Split the initial payload
• Load scripts without blocking
• Couple asynchronous scripts
• Don’t scatter inline scripts
• Split the dominant domain
• Flush the document early
• Use iframes sparingly
• Simplify CSS selectors

Who’s helping on this?

Doug Crockford, Nicholoas Zakas, Ben Galbraith, Dylan Shiemann, Tonyy Gentilcore, Stoyan Stefanov
15-20% of responses are not GZip.

Today, we’ll talk about 5 rules.

• Load scripts without blocking
• Couple asynchronous scripts
• Don’t scatter inline scripts
• Flush the document early
• Use iframes sparingly

Load scripts without blocking

Cuzillion
Why focus on JavaScript?
JavaScript is 10x more painful than other resources to add to your website.
In a lot of pages, the number of JavaScript requests is small. But the load time is HUGE. So why?
It’s because scripts block.

Nothing else will load while JavaScript is loading.

So how to address this?

MSN.com. IE7 only allows two connections per host. So there is domain sharding to get parallel downloads. But the amazing thing on MSN.com is to get JavaScript to load in parallel.

Asynchronous script loading. Here’s some ways…

• XHR Eval
• XHR Injection
• Script in iframe
• Script DOM Element – not you can append to head inside of head, so that’s pretty cool.
• Script defer – only supported in IE
• document.write – suggested not to use this

Steve Souders recommends Script DOM element as his solution of choice. In reality, some are better in certain situations, however as a general rule that’s his favorite trick.

What about inlined code that depends on the script?

Coupling Techniques

• Hardcoded callback
• window onload
• timer – bad because of overhead and not efficient
• degrading script tags – a cool technique based on John Resign
• script onload – pretty nice, medium complexity

Of these, Steve prefers the script onload technique.

Short story, it’s great to do asynchronous loading, but you have to pay attention to race conditions (code dependencies that require script order and can break IE)

Bad: Stylesheet followed by inline script

Browsers download stylesheets in parallel with other resources that follow. So stylesheets play nicely.
UNLESS that stylesheet is followed by an inline script.

Look at pages in a packet sniffer and see what it’s doing.

iFrames – the most expensive DOM element

Load 100 empty elements of each type
Tested in all major browsers

iFrames: no free connections. iFrames don’t give you more parallel downloads.

Flush the document early

Call PHP’s flush function to flush standard out and send it over the wire. This way, you can avoid having to wait for entire HTML before script and assets to load

There are some gotchas (things that might prevent flush from working)

• PHP output_buffering
• Transfer:-Encoding: chunked
• gzip – Apache’s DeflateBufferSize before 2.2.8
• proxies and anti-virus software
• browsers – Safari (1K), Chrome (2K)

You might need to move flushed resources to a domain different from the HTML doc

Takeaways

• Focus on the frontend – in the past, I focused on DB and backend caching. If you want scalability, that makes sense. But if you want a faster user experience, you have to focus on these front-end pieces. There’s a lot of expertise out there now – 30 rules at Google.
• Run YSlow – for first 14 rules
• This year’s focus: JavaScript – asynchronous load and other techniques
• Speed matters – speed impacts revenue

How does speed affect traffic?
Google: +500ms -> decrease in 20% traffic
Yahoo: +400ms -> decrease 5-9% in traffic
Amazon: +100ms -> decrease 1% in conversions

Cost-Savings
hardware-reduced load
bandwidth – reduced response size

If you want
Better user experience
more revenue
reduced operation expenses

The strategy is clear… Even Faster Websites

Questions from audience

Question: What do you think about third-world browsing?

Answer: What an important question. We always test locally on fast systems. But in emerging markets, the situation might be much different. Companies that are looking for big growth are focused on these emerging markets, and performance there could be an order of magnitude worse. So focus a lot on the rules that address limiting transfer time.

Question: What is general direction of pagerank and performance? Impacts on SEO?

Answer: Certainly, it’s great to work at Google, because Google really cares about performance. I had a 1.5 hour one-on-one last week with Larry Page. My job now is to make the Internet an order of magnitude faster! So, are we going to include YSlow score in PageRank? For me, that would be awesome. We’re not doing that now. However, we are including Linkc into the AdWords quality score. So if you have a slow page, you can get moved down in rankings.

Question: Do you know any research about mobile clients and mobile web?

Answer: I don’t do a lot of work on mobile. New iPhone doesn’t have similar 25K cache issue as old iPhone. Going through mobile networks can be slow. However, ppk of quirksmode fame is starting to look at mobile user agent attributes. That’s an area that needs more work.

Question: Do you have any success stories working with ads / analytics vendors?

Answer: Please send me things like that. Reaching out to WordPress, Blogger, web vendors etc could be really powerful. It’s too bad that web developers have to do this heavy lifting, so the more we can integrate them automatically into frameworks, the better. Matt Mullenweg has made some WordPress improvements recently. However, when I analyze ads, 25% of the problems are really ads. So there’s a lot of problems you can clean in your own household.
As for ads, I used to work with a group at IAB (Interactive Advertising Bureau) but am not doing that anymore. I simply don’t have time.