https://www.w3.org/TR/resource-hints/
如果我理解正确，那么这两种方法都可以用来启动早期连接，以便在以后更快地加载资源。
preconnect只是在做“更多”。
除了更好的浏览器支持外，是否有任何理由通过预连接使用dns-prefetch？我还看到网站在相同的链接标签上同时使用两个rel，以便在可能的情况下使用预连接，而在不使用时回退到dns-prefetch。
<head>
<link
rel="dns-prefetch preconnect"
href="https://fonts.gstatic.com"
crossorigin
>
</head>
最佳答案
我最近一直在研究该主题，到目前为止，我的(理论上)结论如下:
在计算浏览器的实际全局使用量(~73%与~74%)时，截至2018年中的浏览器支持差异可以忽略不计dns-prefetch = DNS，而preconnect = DNS + TCP + TLS。请注意，DNS查找执行起来非常便宜(对DNS服务器的简单查询响应，在短时间内缓存在浏览器中)，而TCP和TLS涉及一些服务器资源。
因此，实际的区别是，如果您确定肯定会发生服务器访存，则preconnect是好的。如果仅在某些情况下会发生这种情况，并且您预计会有大量流量，则preconnect可能会触发很多无用的TCP和TLS工作，而dns-prefetch可能更合适。
例如:
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可能是低流量网站的理想选择，无论前面提到的是什么。 与往常一样，最好考虑用例，进行部署，度量和微调。