小球自由落体_自由落体瀑布

小球自由落体

2010 update: Lo, the Web Performance Advent Calendar hath moved

2010年更新： Lo， Web Performance Advent Calendar已移动

Dec 14 This post is part of the 2009 performance advent calendar experiment. Stay tuned for the articles to come.

12月14日这篇文章是2009年性能出现日历实验的一部分。 请继续关注未来的文章。

In this serias of performance posts, so far we've looked at having fewer components in the waterfall (meaning less HTTP requests) and also making the components as small as possible. The next task is to make sure that the waterfall is as short as possible - meaning let it fall freely, without interruptions and have the browser download as many components as possible in parallel.

到目前为止，在性能发布系列中，我们已经着眼于瀑布中具有更少的组件(意味着更少的HTTP请求)，并且还使组件尽可能的小。 下一个任务是确保瀑布尽可能短-这意味着让它自由下落而不会受到干扰，并让浏览器并行下载尽可能多的组件。

Some ways to make the waterfall fall free include having:

使瀑布自由下落的一些方法包括：

• fewer DNS lookups
  更少的DNS查找
• parallel downloads using several domains (this point contradicts the previous, ain't performance fun)
  使用多个域的并行下载(这一点与以前的性能矛盾)

• fewer redirects (ideally no redirects)

  重定向次数更少(理想情况下没有重定向)

• non-blocking scripts and styles
  非阻塞脚本和样式
• smaller request/reponse headers, which includes using fewer cookies
  较小的请求/响应标头，包括使用较少的cookie

减少DNS查找 (Reducing DNS lookups)

When you request a component, the browser needs to resolve the hosthame of the component to an IP address. This is known as a DNS lookup and you can see those lookups in the waterfall charts. The DNS time may look negligible (plus DNS lookups get cached by browsers and operating systems), but they sometimes take ridiculous amount of time. It depends on many factors, often beyond your control, so the best thing to do is change what you do control and that is - require fewer DNS lookups. Carlos Bueno has an excellent writeup on DNS lookups here.

请求组件时，浏览器需要将组件的主机名解析为IP地址。 这称为DNS查找，您可以在瀑布图中看到这些查找。 DNS时间看起来可以忽略不计(再加上浏览器和操作系统对DNS查找进行缓存)，但是它们有时会花费可笑的时间。 它取决于许多因素，通常是您无法控制的，因此最好的办法是更改您的控制方式，即-需要更少的DNS查找。 Carlos Bueno在这里对DNS查找有出色的撰写。

You should limit the number of DNS lookups the browser needs to perform, ideally to no more than 2 to 4, according to Yahoo's studies.

根据Yahoo的研究，您应该将浏览器需要执行的DNS查找的数量限制为不超过2-4个。

并行下载 (Parallel downloads)

Browsers have limits on how many components they download from the same domain at the same time. In older browsers, including IE6 and IE7 this limit is 2. This can definitely slow down your waterfall significantly, when you have a greater number of components to download.

浏览器限制了他们从同一域中同时下载多少个组件。 在较旧的浏览器(包括IE6和IE7)中，此限制为2。当您要下载的组件数量更多时，这无疑会大大降低瀑布的速度。

Newer browsers have increased that limit to 4 (Safari, Opera 10) or 6 (FF3, IE8), so this should be less of an issue. But at the end it depends on your page - how many components and how many people on IE6,7.

较新的浏览器已将该限制增加到4(Safari，Opera 10)或6(FF3，IE8)，因此这应该不是问题。 但最后取决于您的页面-IE6,7上有多少组件和多少人。

Below is an image of how IE7 loads a page with 8 images, where each image is artificially delayed to take 2 seconds. Downloading two components at a time, IE spends at least 8 seconds on the images (2-4-6-8) or a total time of over 9 seconds.

以下是IE7如何加载包含8张图片的页面的图片，其中每张图片被人为地延迟了2秒。 IE一次下载两个组件，因此在图像(2-4-6-8)上花费至少8秒钟，或者总共花费9秒钟以上。

Loading the same page in IE8 is shown below. IE8 loads 6 components at a time, so the 8 images are loaded in two batches (1st - 6 images, 2nd - 2 images), for a total time of 4 seconds spend on images. Overall, the whole page loads in 5 seconds.

在IE8中加载相同的页面如下所示。 IE8一次加载6个组件，因此将8个图像分两批加载(第1-6个图像，第2-2个图像)，总共花费4秒钟的时间在图像上。 总体而言，整个页面的加载时间为5秒。

Now, to work around this limitation in older browsers a common technique is to create dummy subdomains, like img1.example.org, img2.example.org and so on, so that more components can be downloaded in parallel (the limitation is per domain). If you're going to do this, remember to balance this optimization with the fewer DNS lookups recommendation, don't spread on too many domains. Look carefully at your waterfalls to find the balanced point. Again, the general recommendation is that a page should require up to 2-4 domains tops.

现在，要解决旧版浏览器中的限制，一种常见的技术是创建虚拟子域，例如img1.example.org，img2.example.org等，以便可以并行下载更多组件(此限制是针对每个域的) )。 如果要执行此操作，请记住在此优化与较少的DNS查找建议之间取得平衡，不要在太多的域中传播。 仔细看瀑布，以找到平衡点。 再次，一般的建议是一个页面最多应包含2-4个域名。

Quick sidetrack: two URLs for your toolbox.

快速跟踪：工具箱的两个URL。

1. For the up-to-the-moment insight into different browser limits and capabilities, bookmark Google's BrowserScope project. Check the "Network" tab for example to see the parallel downloads limitations across browsers

   要获得有关不同浏览器限制和功能的最新了解，请为Google的BrowserScope项目添加书签。 例如，查看“网络”标签以查看跨浏览器的并行下载限制

2. Cuzillion (by Steve Souders) lets you quickly create test pages. The waterfalls above are actually coming from a page created with Cuzillion and tested in AOL's WebPageTest

   Cuzillion (由Steve Souders撰写)可让您快速创建测试页。 上面的瀑布实际上来自使用Cuzillion创建的页面，并在AOL的WebPageTest中进行了测试

没有重定向(No redirects)

Redirects are bad for your waterfall. They do nothing for the user but just slow down the experience. Think about what happens: the browser makes a request, waits for the response, the response says "no, no, go get your component from way over there", so the poor old browser starts again - makes a new request, waits for the response.

重定向对您的瀑布不利。 他们没有为用户做任何事情，只是减慢了体验。 想想发生了什么：浏览器发出一个请求，等待响应，响应说“不，不，从那边获取您的组件”，所以可怜的旧浏览器再次启动-发出一个新请求，等待响应。

So, avoid redirects, be they server-side redirects or client-side (JavaScript or meta-tag redirects).

因此，避免重定向，无论是服务器端重定向还是客户端(JavaScript或元标记重定向)。

As an illustration how bad redirects can be - consider the waterfall below. It's from a real page, not a made up case. So it all looks like the page could finish loading after about 1.1 seconds, but then a redirect occurs at 0.9s, takes half a second and then points to a 1x1 blank GIF. Obviously it's some sort of stats tracking image. But the bad parts are that: a/ it's an IMG tag, therefore delays onload and b/ there's a redirect. At the end, the page loads in 1.7 seconds instead of 1.1 seconds. The user experience suffers for no reason. The way to fix this is simply remove the image from the IMG tag and load it with new Image().src = "1x1.gif" this way taking it out of the onload flow. Then remove that redirect. For such stats tracking cases a 204 No Content response is the appropriate way to go.

为了说明重定向的错误程度，请考虑以下瀑布。 它来自真实页面，而不是虚假案例。 因此，看起来页面可以在大约1.1秒后完成加载，但是随后重定向发生在0.9秒，耗时半秒，然后指向1x1的空白GIF。 显然，这是某种统计跟踪图像。 但是最糟糕的是：a /是IMG标签，因此会延迟加载，而b /则存在重定向。 最后，页面加载时间为1.7秒，而不是1.1秒。 用户体验无故遭受损失。 解决此问题的方法是简单地从IMG标记中删除图像，并使用new Image().src = "1x1.gif"加载它，从而将其从onload流中移除。 然后删除该重定向。 对于此类统计信息跟踪案例，使用204 No Content响应是合适的方法。

阻止脚本和样式 (Blocking script and styles)

Scripts block downloads, hence slow down your free-falling waterfall. This is an important topic which deserves an article of its own, so stay tuned.

脚本会阻止下载，因此会减慢您自由下落的瀑布的速度。 这是一个重要的话题，值得一读，敬请期待。

And what about stylesheets, do they block other downloads in the waterfall? Turns out stylesheets are mostly fine, but they could also block in these cases:

样式表又如何，它们会阻止瀑布中的其他下载吗？ 事实证明，样式表通常很好，但在以下情况下它们也可能会阻塞：

• in Firefox before version 3 (probably no need to worry about it)
  在Firefox 3之前的版本中(可能无需担心)
• in all browsers, if followed by an inline script
  在所有浏览器中，如果后接嵌入式脚本

The second one is interesting as much as it's surprising. It's probably not a good idea to have inline script tags scattered all around the HTML to begin with. And since this can cause the stylesheets to block the downloads of the other components, it should be avoided at all costs.

第二个既有趣又令人惊讶。 首先，将内联脚本标签分散在HTML周围可能不是一个好主意。 并且由于这可能导致样式表阻止其他组件的下载，因此应不惜一切代价避免这样做。

Be sure to check Steve Souders' blog post for more information. Credit to Steve - I believe he was the first to take note and report this issue.

请确保查看Steve Souders的博客文章以获取更多信息。 感谢史蒂夫-我相信他是第一个记录并报告此问题的人。

So check your waterfall if you see a stylesheet that blocks, look around it in the markup for any inline script tags that can be moved further down.

因此，如果您发现瀑布样式表受阻，请检查瀑布，在标记中四处寻找可以向下移动的任何内联script标记。

Cookies和其他HTTP标头 (Cookies and other HTTP headers)

We talked about making the responses smaller. But we can also optimize the requests by making the HTTP headers smaller. You can take a look at your request and response headers and see if you're not sending too much.

我们讨论了缩小响应范围。 但是我们也可以通过减小HTTP标头来优化请求。 您可以查看您的请求和响应标头，看看发送的不是太多。

Looking at my blog I see this Server header:

查看我的博客，我看到以下Server标头：

Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a Phusion_Passenger/2.2.4 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a Phusion_Passenger/2.2.4 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635

Seems to me like too much information.

在我看来喜欢太多信息。

There's also an ETag: Etag: "9f38013-2af0-453b354a20bc0"

还有一个ETag ： Etag: "9f38013-2af0-453b354a20bc0"

While ETags may be help with caching, when you have far-future Expires header, they are not necessary. And if you have a multi-machine setup, ETags can actually be bad (YSlow will warn you for this issue)

虽然ETag可能对缓存有所帮助，但是当您拥有远期的Expires标头时，则没有必要。 而且，如果您使用的是多计算机设置，则ETags实际上可能是不好的(YSlow会针对此问题警告您)

While you have some control over the response headers, you have very little control over the request headers. It's your users' browsers that control them. But you do have control over the Cookie header and this is where the bigger savings will actually come from because Cookie is often the biggest part of the HTTP headers

虽然您可以对响应标头进行某些控制，但是您对请求标头的控制却很少。 是用户的浏览器控制它们。 但是您确实可以控制Cookie头，而这实际上是节省的地方，因为Cookie经常是HTTP头的最大部分

减少饼干(Reduce cookies)

You should aim at sending the least possible amount of cookies. Be careful when you write cookies. Make them smaller and write them to the appropriate sub-domain name. If you have a blog at blog.example.org and a main site at www.example.org, then don't write the blog.example.org cookies at *.example.org level.

您应该以发送尽可能少的Cookie为目标。 编写Cookie时要小心。 使其更小，然后将其写入相应的子域名。 如果您在blog.example.org有一个博客，而在www.example.org有一个主要站点，则不要在*.example.org级别上写blog.example.org cookie。

Hotmail have talked about how they compress their cookies before writing them. That's also an idea if you have big Cookie headers.

Hotmail已经讨论了如何在编写cookie之前压缩cookie。 如果您有很大的Cookie标头，这也是一个想法。

组件的无Cookie域 (Cookie-less domains for components)

Better yet, for static components that don't have any use for these cookies, just don't send them. Setup static.example.org and don't write cookies for this domain. Then put your static components there.

更好的是，对于不使用这些Cookie的静态组件，只需不发送它们。 设置static.example.org ，不要为此域编写Cookie。 然后将您的静态组件放在那里。

A curious piece of stats here - Philip Dixon reported (slides) that after Shopzilla.com moved their static components to a cookie-free domain they made more money.

令人好奇的统计数据-菲利普·迪克森( Philip Dixon)报道(幻灯片)，在Shopzilla.com将其静态组件移至无Cookie的域后，他们赚了更多钱。

Images to non-cookie domain resulted in 0.5% top line revenue increase!

非Cookie域中的图片使收入增加了0.5％！

"top line" means revenue (maybe you know that but I had to check :)). This is a fascinating idea - that you can make more money by improving something as simple as cookie-less components. So, every little bit helps. Keep making your site faster and ... you never know.

“顶线”表示收入(也许您知道，但我必须检查一下：)。 这是一个令人着迷的想法-您可以通过改进无cookie组件之类的简单方法来赚更多的钱。 因此，一点点帮助。 保持网站速度更快，而且……永远不会。

www或否www (www or no-www)

This point also adds to the good old www vs. no-www flamewar. If you opt for no www, then in IE you cannot write cookies to example.org, but you'll write to *.example.org. This means your static.example.org will see all the cookies too. This post has some more info on the topic.

这一点也增加了旧的www vs.no-www Flamewar。 如果您不选择www，则在IE中您无法将cookie写入example.org，但是您将写入* .example.org。 这意味着您的static.example.org也将看到所有cookie。 这篇文章中有关于该主题的更多信息。

If you've already polluted your top-level domain with long-term cookies, the remedy would be to just buy a new "clean" domain, like examplestatic.org, never ever write cookies to it and use it for your static components.

如果您已经用长期cookie污染了顶级域，那么补救措施是只购买一个新的“干净”域，例如examplestatic.org ，永远不要向其写入cookie并将其用于静态组件。

谢谢！ (Thanks!)

And that's it for today's post, thank you for reading and may HTTP be with you 😉

就是今天的帖子，谢谢您的阅读，也许HTTP与您同在😉

Tell your friends about this post on Facebook and Twitter

在Facebook和Twitter上告诉您的朋友有关此帖子的信息

翻译自: https://www.phpied.com/free-falling-waterfalls/

小球自由落体