7/04/2009

High Performance Web Sites: The Importance of Front-End Performance

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.

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 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.]
Posted at March 20, 2007 9:16 AM

7/02/2009

Google Hosts文件

研究了一晚上google的域名,自己从位于加利福尼亚的谷歌总部DNS服务器上扒出来的。
把下面的内容添加到C:\Windows\System32\drivers\etc\hosts文件中就行了

#Search
64.233.189.147 www.google.com
64.233.189.104 www.google.com
64.233.189.99 www.google.com
64.233.189.147 www.l.google.com

#Mail(POP3/SMTP)
209.85.147.109 pop.gmail.com
209.85.147.109 smtp.gmail.com

#WebMail
64.233.189.18 mail.google.com
64.233.189.19 mail.google.com
64.233.189.83 mail.google.com
64.233.189.18 www.gmail.com
64.233.189.19 www.gmail.com
64.233.189.83 www.gmail.com
64.233.189.19 googlemail.l.google.com

#Docs
64.233.189.101 writely-china.l.google.com
64.233.189.101 writely.l.google.com
64.233.189.102 docs.google.com
64.233.189.101 docs.google.com
64.233.189.100 docs.google.com

#Map
64.233.189.104 map.google.com
64.233.189.99 map.google.com
64.233.189.147 map.google.com
64.233.189.104 maps.google.com
64.233.189.99 maps.google.com
64.233.189.147 maps.google.com
64.233.189.99 maps.gstatic.com
203.208.39.93 khm.google.com
203.208.39.91 mt0.google.com
203.208.39.93 mt1.google.com
203.208.39.91 mt2.google.com
203.208.39.91 mt.l.google.com
64.233.189.99 maps.l.google.com

#Scholar
64.233.189.99 scholar.google.com
64.233.189.104 scholar.google.com
64.233.189.147 scholar.google.com
64.233.189.104 scholar.l.google.com

#Group
64.233.189.102 groups.google.com
64.233.189.100 groups.google.com
64.233.189.101 groups.google.com
64.233.189.101 groups.l.google.com

#Misc
64.233.189.101 id.google.com
64.233.189.102 id.google.com
64.233.189.100 id.google.com
64.233.189.100 id.l.google.com