Académique Documents
Professionnel Documents
Culture Documents
http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_perf...
Sign In
Help
Make Y! My Homepage
My Y!
Yahoo!
Search
Search Web
DEVELOPER
PUBLISHER
BLOG
Home
Forums
Video
Yahoo! on Github
YDN on Twitter
updates apps yui hackday oauth patterns
Search Blog
RECENT POSTS Canvas Pattern, Node.js, CSS3 Secrets, FreezePage, Paladin Hack U at UCLA HackU Michigan: Real Time Tracking, Answers, and Games
Hackstravaganza at IIT Delhi Sticky thing, Crockford on JavaScript, h5ai, Animatable, ScriptCover EVENTS
In 2004, I started the Exceptional Performance group at Yahoo!. We're a small team chartered to measure and improve the performance of Yahoo!'s products. Having worked as a back-end engineer most of my career, I approached this as I would a code optimization project - I profiled web performance to identify where there was the greatest opportunity for improvement. Since our goal is to improve the end-user experience, I measured response times in a browser over various bandwidth speeds. What I saw is illustrated in the following chart showing HTTP traffic for http://www.yahoo.com.
ALL
Upcoming
YDN
No events planned
Follow Yahoo! on Upcoming Read blog posts about YDN events
Conferences/Events Connected TV Design Patterns Evangelism Featured General Guest Posts Hackday i18n JavaScript Meta Music Open Performance Release Notes Search Technology Video YOS YUI
ARCHIVES
Developers Events Fun Geo Hack U Hadoop Identity & Reputation Mail / Messenger Mobile OAuth Partners Pipes RHoK Social Tutorials YAP YQL
Select Month
In the figure above, the first bar, labeled "html", is the initial request for the HTML document. In this case, only 5% of the end-user response time is spent fetching the HTML document. This result holds true for almost all web sites. In sampling the top ten U.S. websites, all but one spend less than 20% of the total response time getting the HTML document. The other 80+% of the time is spent dealing with what's in the HTML document, namely, the front-end. That's why the key to faster web sites is to focus on improving front-end performance. There are three main reasons why front-end performance is the place to start. 1. There is more potential for improvement by focusing on the front-end. Cutting it in half reduces response times by 40% or more, whereas cutting back-end performance in half results in less than a 10% reduction. 2. Front-end improvements typically require less time and resources than back-end projects (redesigning application architecture and code, finding and optimizing critical code paths, adding or modifying hardware, distributing databases, etc.). 3. Front-end performance tuning has been proven to work. Over fifty teams at Yahoo! have
1 de 5
22/11/11 10:14
http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_perf...
reduced their end-user response times by following our performance best practices, often by 25% or more. Our performance golden rule is: optimize front-end performance first, that's where 80% or more of the end-user response time is spent. Steve Souders [Steve Souders is Yahoo!'s Chief Performance Yahoo!. This is one in a series of Best Practices for Speeding Up Your Web Site. This article is based on Steve's book High Performance Web Sites, published by O'Reilly.]
Steve Souders (@stevesouders)
29 Comments
Bookmark
Share
Tweet
Me gusta
Categories Performance
Previous Post
MORE FROM STEVE SOUDERS
Next Post
Performance Draws a Crowd in Beijing YSlow 0.9 Release Better Support for Web 2.0 Virgin America tunes up with YSlow Velocity Web Performance and Operations Conference Web Site Optimization: a Practical Perspective
29 COMMENTS
Morgan 243 weeks ago | Report Abuse
Everything old is new again! Actually really interesting though I think its great to get back to the fundamentals, and even better to hear how much it can really help. The book looks great, reading it on Safari now.
Permalink
Are we gonna get the rest of the book for free over here, or is this a teaser?
Permalink
I doubt well get the whole thing but I read as much as I could on Safari, and hopefully he wont mind me sharing the companion website, it has all 14 rules but not all have examples yet. Still great. This is a must buy as soon as its ready. http://stevesouders.com/examples/rules.php
Permalink
Is there a tool that analyses how the browser downloads the different elements on the page and gives something like the chart you posted?
Permalink
You can get charts like this from IBM Page Detailer: http://alphaworks.ibm.com /tech/pagedetailer
Permalink
I totally agree that reducing web page weight is a good idea. One thing to be aware of is
2 de 5
22/11/11 10:14
http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_perf...
that the user doesnt have to wait for all the files to load before the page is rendered. AFAIK the files are loaded in the order they are specified in the HTML doc, so once the HTML and CSS has loaded, the user will see the page with empty spaces where the images and swfs will be. Thats why it seems odd on your graph that the stylesheet is loaded at the end.
Permalink
Not everyone puts their stylesheets in the head of the HTML document. They should, and thats the topic of Rule 5. In the example above, the stylesheet and script at the end are most likely downloaded via DHTML in the pages onload handler. Scripts also delay the rendering of pages, as shown in this example: http://stevesouders.com/examples/movescripts.php
Permalink
Are you sure that the Use a CDN item in the performance tab is working? I am using a CDN, and its telling me that Im not.
Permalink
Fiddler2s new Timeline extension (http://www.fiddler2.com/Fiddler2 /extensions.asp#Timeline) shows charts like this as well.
Permalink
You can add your CDN to the YSlow configuration settings (see http://developer.yahoo.com/yslow/faq.html#faq_cdn). Yes, Fiddler 2 has great HTTP request timeline charts.
Permalink
Steve Souders has done a great job putting together these recommendations, and I applaud his book, but am I the only one that thinks Yahoo! happens to have one of the slowest and most bloated page loads around? Its kind of disappointing to realize that theyve already squeezed and optimized these pages and they are still slow loaders! The culprit is almost always fat flash files for ads and video. Nothing new here, but interestingly, I dont see flash files listed on the chart above. Perhap they are lumped in with images. While Yahoo! uses mostly open source (php, etc.) Flash is proprietary and Adobe has done next to nothing to open it up compared to other internet technologies even compared to other proprietary tech. That seems to me to be the biggest opportunity for page load improvement open up the flash tech so we can better manage it at the developer and user levels.
Permalink
Im all for making Yahoo!s pages faster, but I will point out that across the ten top sites in the U.S., Yahoo! is in the middle. Again, Id still like to see things faster and we continue to work (hard!) on making that happen. Your comment on ads is true. Third party ads have become the #1 slowdown on Yahoo! pages. Ive started discussions with the IAB (Interactive Advertising Bureau) to setup a performance working group to get industry-wide support for improving the performance of ads. If you see bad ads, complain! Dont buy that brand. Complain to the publisher (like Yahoo!). This feedback will encourage advertisers to improve their performance practices so they dont drive away consumers. We are starting to dig into Flash performance. The Flash group at Yahoo! has built some cool tools to analyze Flash performance. But its going to take awhile to gather the best practices and make the tools public. Well share what we have when we have it.
3 de 5
22/11/11 10:14
http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_perf...
Permalink
Steve, colleague saw your presentation at Future of Web Apps in London and suggested I take a look at what your group is doing. What are your feelings about hardware Application Front End appliances like F5s BIG-IP and Citrixs NetScaler? Think they are overkill if one could fix front end issues in software?
Permalink
These hardware appliances are generally focused on delivery of the HTML document. Since thats less than 10-20% of the overall user experience, the higher priority is focusing on the other 80-90% of the time. So these are not a first priority when it comes to optimizing the user response time. If your focus is to improve your back end performance (e.g., requests/second), these can play a role.
Permalink
Steve, do you think there will eventually be a guideline involving cookies based off of the When the Cookie Crumbles article? Perhaps something YSlow could check? If images are on the same server as a cookie it gets returned in the HTTP request. If you have a site with a lot of new images, such as e-commerce, a lot of savings could be made. For example, on a search results page or a page that features new products with unique images. Since a cookie can be 4-5kb it seems that a large cookie could have a pretty sizable performance impact.
Permalink
Hi, Rob. Yes, Im baking 5-6 new rules now that address cookies and cookie-free domains. That definitely helps.
Permalink
Hi! I look at the chart that illustrates HTTP traffic and I am wondering about how did you get it. Did you use any measuring tool that analizes and provides this information on the fly or add some smart javascript measuring code to the page? Thanks.
Permalink
Thanks Dude
Permalink
Hi, Rob. Yes, Im baking 5-6 new rules now that address cookies and cookie-free domains. That definitely helps.
Permalink
hey there, Are you guys looking for charting component if yes then chk this out visifire i really enjoyed drawing chart with various animations
Permalink
First, thanks for Your helpful work, Steve! Take a look at http://site-perf.com/, may be Youll find it useful. Its another online site download measurement tool, like pingdom.com, but looks more realistic.
4 de 5
22/11/11 10:14
http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_perf...
Permalink
Steve, just wondering how the Flash performance work is coming along.
Permalink
Thank you very much for this useful article and the comments.
Permalink
Hi,Its really nice post.I totally agree that reducing web page weight is a good idea. One thing to be aware of is that the user doesnt have to wait for all the files to load before the page is rendered.
Permalink
Folks, if youre interested in Web performance issues and topics, please join the conversation on the Yahoo! Exceptional Performance Group: http://tech.groups.yahoo.com/group/exceptional-performance/ Also, the best place to pose your questions and comments. Thanks!
Permalink
Copyright 2011 Yahoo! Inc. All rights reserved. Copyright Privacy Policy Terms of Use
Contact Us
Community
Suggestions
5 de 5
22/11/11 10:14