预连接 vs dns-prefetch 资源提示 [英] preconnect vs dns-prefetch resource hints
问题描述
https://www.w3.org/TR/resource-hints/
如果我理解正确，两者都用于启动早期连接以在以后更快地加载资源.
If I understand correctly, both are used to initiate an early connection to load resources faster at a later time.
预连接只是做更多".
除了更好的浏览器支持之外，还有什么理由在预连接上使用 dns-prefetch 吗?我还看到网站在同一个链接标签上同时使用 rel 以尽可能使用预连接，否则就回退到 dns-prefetch.
Apart from a better browser support, is there any reason to use dns-prefetch over preconnect? I've also seen websites using both rel at the same link tag in order to use preconnect if possible and fall back to dns-prefetch if not.
<head>
<link
rel="dns-prefetch preconnect"
href="https://fonts.gstatic.com"
crossorigin
>
</head>
推荐答案
我最近一直在研究这个话题，到目前为止我的(理论)结论如下:
I've been researching the topic a bit lately and so far my (theoretical) conclusions are as follows:
截至 2018 年年中，在计算浏览器的实际全球使用情况时，浏览器支持差异可以忽略不计(~73% vs ~74%)
Browser support difference is negligible as of mid-2018, when counting the real global usage of browsers (~73% vs ~74%)
dns-prefetch = DNS 和 preconnect = DNS + TCP + TLS.请注意，DNS 查找的执行成本非常低(对 DNS 服务器的简单查询响应，在浏览器中缓存很短的时间)，而 TCP 和 TLS 涉及一些服务器资源.
dns-prefetch = DNS and preconnect = DNS + TCP + TLS. Note that DNS lookup is quite cheap to perform (a simple query-response to the DNS server, that is cached in the browser for a short amount of time), whereas TCP and TLS involves some server resources.
因此，实际区别在于，如果您知道服务器获取会肯定会发生，预连接很好.如果它只是偶尔发生，并且您预计会有大量流量，preconnect 可能会触发大量无用的 TCP 和 TLS 工作，而 dns-prefetch 可能更适合.
The practical difference is hence, if you know that a server fetch will happen for sure, preconnect is good. If it will happen only sometimes, and you expect huge traffic, preconnect might trigger a lot of useless TCP and TLS work, and dns-prefetch might be a better fit.
例如:
- 如果页面在每次加载时请求
https://backend.example.com/giveMeFreshData，并且响应不可缓存，preconnect很适合莉> - 如果页面仅请求静态资源，例如
https://statics-server.example.com/some-image.jpg或https://statics-server.example.com/some-css.css，并且资源很可能来自用户的浏览器缓存(许多页面使用相同的资源，您的用户将触发大量页面加载，例如这与热缓存 - 并且没有从该源获取其他资源)，然后preconnect可能会在您的服务器上创建大量不必要的 TCP 连接(几秒钟后将放弃，但仍然，它们一开始就不是必需的)和 TLS 握手(但是在这种情况下，如果您知道确切的 URL 并且资源非常重要，preload可能是一个选项). - 如果您网站上的流量很小，则不应受到这种差异的太大影响，因此
preconnect可能非常适合低流量网站，无论前面提到的内容如何.
- if the page requests
https://backend.example.com/giveMeFreshDataon each load, and the response is not cacheable,preconnectis a good fit - if the page only requests a static resource like
https://statics-server.example.com/some-image.jpgorhttps://statics-server.example.com/some-css.css, and the resource is very likely to come from the user's browser cache (the very same resource(s) is used on many pages, and your user will trigger a lot of page loads like this with the warm cache -- and no other resources are fetched from that origin), thenpreconnectmight be creating a lot of unnecessary TCP connections on your server (that will abandoned after a few seconds, but still, they were not necessary in the first place) and TLS handshakes (however in such case,preloadmight be an option if you know the exact URL and the resource is very important). - If the traffic on your website is small though, it should not be impacted too much by this difference, so
preconnectis probably a good fit for low-traffic websites, regardless of the things mentioned before.
一如既往，最好考虑用例、部署、衡量和微调.
As always, it's best to think about the use cases, deploy, measure, and fine tune.
这篇关于预连接 vs dns-prefetch 资源提示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
