preconnect与dns-prefetch资源提示

本文介绍了preconnect与dns-prefetch资源提示的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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.

preconnect只是在做更多".

preconnect is just doing "more".

除了更好的浏览器支持外，是否有任何理由通过预连接使用dns-prefetch?我还看到网站在相同的链接标签上同时使用两个rel，以便在可能的情况下使用preconnect，而在不使用时回落到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％与〜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很好.如果仅在某些情况下发生这种情况，并且您预计会有大量流量，则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/giveMeFreshData on each load, and the response is not cacheable, preconnect is a good fit
if the page only requests a static resource like https://statics-server.example.com/some-image.jpg or https://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), then preconnect might 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, preload might 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 preconnect is 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.

这篇关于preconnect与dns-prefetch资源提示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！