我的所有静态内容都应该位于无 Cookie 的域中吗？
目前，我们正在从备用（无 cookie）域提供静态内容的重要部分 - 事实上，如果重要的话，它也是一个完全不同的 IP 地址。
这无疑帮助我们提高了页面加载速度，但并非所有内容都是从该域提供的。
常识似乎是，从第二个域提供服务速度更快，因为您消除了 cookie/会话/等流量并且，因为它允许更多并发连接。
后者让我很好奇：如果我们将所有静态内容移动到另一个域，主域将只收到一个请求（针对 HTML），而所有其他后续请求都会发送到另一个域。
这将减少浏览器向我们的服务器发出的并发请求量。这不会让事情变得更慢吗？特别是因为我们的页面通常包含大量图像。
我能找到的所有信息都建议将所有内容移动到无 cookie 域，但这个问题从未被提及，这可能意味着作者可能没有考虑到这个缺点？
We are currently serving a significant part of static content from an alternate (cookiefree) domain - in fact, it's a whole different IP-address as well should that matter.
This has certainly helped us with page load speed, however not all content is served from that domain.
Common knowledge seems to be that serving from a second domain is faster because you eliminate cookie/session/etc traffic and because it allows for more concurrent connections.
It's the latter that has me curious: if we move all static content to the other domain, the main domain will only get a single request (for the HTML) and all other subsequent requests go to the other domain.
This will reduce the amount of concurrent requests a browser will make to our server. Won't that make things slower? Especially because our pages often include a lot of images.
All information I can find suggests moving all content to the cookieless domain, but this issue is never mentioned which might mean that the authors might not have considered this downside?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你是对的，但你不必坚持使用单个 cookieless 域...
例如，你可以通过子域进行分片，例如使用 static.domain.com 作为 js/css，然后使用 image1.domain.com / image2。图像的domain.com /等。
如果您正在运行类似图像库之类的东西，您理想情况下希望在所使用的浏览器支持的尽可能多的连接上对图像进行分片（我认为 - 您可能只想针对仅使用 6 个进行测试）。
为了便于维护，每个子域可以指向同一台服务器。
更新 - 2013 年 12 月 12 日
这些天我不会超过 2 个分片（而且我也会在有分片和没有分片的情况下进行测量） - Will Chan 写了一篇关于“过度分片”和 TCP 拥塞的好文章- https://insouciant.org/tech/network-congestion-and-web-browsing/
You're right but you don't have to stick with a single cookieless domain...
For example you could shard via sub-domains e.g. use static.domain.com for js/css and then image1.domain.com / image2.domain.com / etc for images.
If you're running something like an image gallery you ideally want to shard the images over as many connections as the browser in use supports (I think - you may just want to test this against just using 6).
To ease maintenance each subdomain could be pointed back at the same server.
Update - 12 Dec 13
I wouldn't go over 2 shards these days (and I'd measure it with and without shards too) - Will Chan wrote a good post on 'over sharding' and TCP congestion - https://insouciant.org/tech/network-congestion-and-web-browsing/