获取浏览器并发请求数

发布于 2024-12-05 03:41:50 字数 264 浏览 0 评论 0原文

我试图弄清楚是否值得将图像请求分散到多个子域。 [本文](链接已损坏)例如说:

大多数浏览器一次只能发出两个请求,因此浏览器将请求两个文件,下载它们,然后继续处理下两个文件。 HTTP 请求越多,或者页面正确显示所需的单独组件越多,用户等待的时间就越长。

当他们说大多数时,具体是哪些浏览器?该数字与并发 XMLHttpRequest 的数量相关吗?根据

I'm trying to figure out whether it would be worthwhile to spread image requests across multiple sub-domains. [This article](link broken) for example says:

Most browsers can only make two requests at a time, so the browser will request two files, download them and then move on to the next two. The more HTTP requests, or separate components a page requires to display properly, the longer the user will have to wait.

When they say most, which browsers in particular? Is that number related to the number of concurrent XMLHttpRequests, per this question?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

故事未完 2024-12-12 03:41:50

这里有很多事情需要考虑。在大多数情况下,我只会选择一个无 cookie 域/子域来托管您的图像,例如 static.mywebsite.com。理想情况下,静态文件应该由 CDN 托管,但那是另一回事了。

首先,IE7 只允许每个主机有两个并发连接。但如今大多数浏览器允许的功能远不止于此。 IE8 允许 6 个并发连接,Chrome 允许 6 个,Firefox 允许 8 个。

因此,例如,如果您的网页只有 6 个图像,那么将图像分布在多个子域中确实毫无意义。

假设页面上有 24 张图像。嗯,生活中很少有事情是免费的,但存在并行化导致的死亡这样的事情。如果您将图像托管在 4 个不同的子域中,那么这意味着理论上每个图像都可以并行下载。然而,这也意味着涉及 3 个额外的 DNS 查找。 DNS 查找可能需要 100 毫秒、150 毫秒,有时甚至更长。这种增加的延迟很容易抵消并行下载的任何好处。 测试网站来查看真实世界的示例

您可以通过使用 http://www.webpagetest.org/ 当然,最好的解决方案是尽可能使用 CSS 精灵来减少请求数量。我在 这篇文章这篇

更新

Steve Souders 有一篇关于分片域主题的有趣文章......

美国排名前十的网站大多数都进行域名分片。 YouTube 使用
i1.ytimg.com、i2.ytimg.com、i3.ytimg.com 和 i4.ytimg.com。居住
搜索使用 ts1.images.live.com、ts2.images.live.com、
ts3.images.live.com 和 ts4.images.live.com。这两个网站都是
跨四个域的分片。最佳数字是多少? 雅虎!
发布了一项研究,建议至少在两个之间进行分片,但没有
多于四,域。超过四个,性能实际上会下降。

http:// /www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/

但请注意,这是在 2009 年写的。 2011年他发表评论...

由于较新的浏览器为每个域打开更多连接,因此可能
最好向下修改数字。我认为2是一个很好的妥协,
但这只是一种预感。如果有一些生产属性运行那就太好了
确定最佳数量的测试。

您还应该记住,像雅虎和亚马逊这样的大型网站甚至有必要进行域分片的一个重要原因是他们的网站非常动态。这些图像附加到动态显示的产品或故事上。因此,他们不可能尽可能积极地使用 CSS 精灵。

然而,像 StackOverflow 这样的网站很少关注此类图像,并且他们已经减少了请求数量,因此不需要进行分片。实现这一目标的一大进步是他们对 sprites.png 图像的使用...

http://cdn.sstatic.net/Sites/stackoverflow/img/sprites.png?v=5

更新#2

Steve Souders 发布有关域分片的另一项更新。他重复了我已经提到过的大部分内容。但最突出的是 SPDY 以及它如何影响您的决定。

也许反对域分片的最有力的论据是它
在 SPDY(以及 HTTP 2.0)的世界中是不必要的。实际上,
域分片可能会损害 SPDY 下的性能。 SPDY支持
并发请求(尽早发送所有请求标头)以及
请求优先级。跨多个域的分片减少
这些好处。 SPDY 支持 Chrome、Firefox、Opera 和 IE
11. 如果您的流量主要由这些浏览器主导,您可能需要跳过域分片。

更新 #3(2018 年 2 月)

正如 Dean 在下面的评论中提到的,随着现代浏览器支持 HTTP/2,CSS 精灵现在并不太受你欢迎。但您必须获得 SSL 证书,将您的站点设置为使用 HTTPS,并确保您的 Web 服务器配置为 HTTP/2。或者,或者使用已经为您设置好所有这些的 CDN。完成所有这些后,您可能可以跳过 CSS 精灵和域分片。

There are a lot of things to consider here. In most situations, I would only choose one cookieless domain/subdomain to host your images such as static.mywebsite.com. And ideally static files should be hosted by a CDN, but that's another story.

First of all, IE7 allowed only two concurrent connections per host. But most browsers today allow more than that. IE8 allows 6 concurrent connections, Chrome allows 6, and Firefox allows 8.

So if your web page only has 6 images, for example, then it'd really be pointless to spread your images across multiple subdomains.

So let's say you have 24 images on a page. Well, few things in life are free and there's such a thing as death by parallelization. If you host your images in 4 different subdomains, then that means that every single image could theoretically be downloaded in parallel. However, it also means that there are 3 additional DNS lookups involved. And a DNS lookup could be 100 ms, 150 ms, or sometimes longer. This added delay could easily offset any benefit of parallel downloads. You can see real-world examples of this by testing sites with http://www.webpagetest.org/

Of course the best solution is to use CSS sprites when possible to cut down on the number of requests. I talk about that and the inherent overhead of every request in this article and this one.

UPDATE

There's an interesting article from Steve Souders on the subject of sharding domains...

Most of the U.S. top ten web sites do domain sharding. YouTube uses
i1.ytimg.com, i2.ytimg.com, i3.ytimg.com, and i4.ytimg.com. Live
Search uses ts1.images.live.com, ts2.images.live.com,
ts3.images.live.com, and ts4.images.live.com. Both of these sites are
sharding across four domains. What’s the optimal number? Yahoo!
released a study that recommends sharding across at least two, but no
more than four, domains. Above four, performance actually degrades.

http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/

Note however that this was written in 2009. And in 2011 he posted a comment...

Since newer browsers open more connections per domain, it’s probably
better to revise the number downwards. I think 2 is a good compromize,
but that’s just a hunch. It’d be great if some production property ran
a test to determine the optimal number.

You should also keep in mind that the big reason it's even necessary for the big sites like Yahoo and Amazon to do domain sharding is that their sites are so dynamic. The images are attached to products or stories which are displayed dynamically. So it's not feasible for them to use CSS sprites as aggressively as would be optimal.

A site like StackOverflow, however, is light on these sorts of images and they have cut down on the number of requests so much that they don't need to do sharding. A big step towards making that happen is their usage of this sprites.png image...

http://cdn.sstatic.net/Sites/stackoverflow/img/sprites.png?v=5

UPDATE #2

Steve Souders posted another update on domain sharding. He repeats much of what I've already mentioned. But the thing that stood out was SPDY and how that should affect your decision.

Perhaps the strongest argument against domain sharding is that it’s
unnecessary in the world of SPDY (as well as HTTP 2.0). In fact,
domain sharding probably hurts performance under SPDY. SPDY supports
concurrent requests (send all the request headers early) as well as
request prioritization. Sharding across multiple domains diminishes
these benefits. SPDY is supported by Chrome, Firefox, Opera, and IE
11. If your traffic is dominated by those browsers, you might want to skip domain sharding.

UPDATE #3 (February 2018)

As Dean mentioned in the comments below, CSS sprites aren't really buying you very much now with HTTP/2 being supported in modern browsers. But you do have to get an SSL certificate, set up your site to work with HTTPS, and ensure your web server is configured for HTTP/2. Either that, or use a CDN that already has all of that set up for you. Once you've done all of that then you can probably skip both CSS sprites and domain sharding.

谎言月老 2024-12-12 03:41:50

google chrome 有:6,Safari 有:5,mozilla firefox 有:8 对同一域的最大并发获取请求。

google chrome have :6, Safari have :5 , mozilla firefox have :8 maximum concurrent get request to same domain.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文