我们应该与 Chrome 进行“dns-prefetch 预连接”的域数量是不是有限制？

Posted 2023-02-23

【中文标题】我们应该与 Chrome 进行“dns-prefetch 预连接”的域数量是不是有限制？

【英文标题】：Is there a limit to how many domains we should "dns-prefetch preconnect" with Chrome?我们应该与 Chrome 进行“dns-prefetch 预连接”的域数量是否有限制？

【发布时间】：2019-08-22 00:56:42

【问题描述】：

当我们想要确保使用第三方小部件/插件/附加组件/分析等的快速网站时。实现这一目标的众多要求之一是为每个单独的域“dns-prefetch preconnect”名称（基本上为 DNS 查找等节省了一点）

在我们失去任何潜在利益之前，我找不到可以建议我们可以“dns-prefetch preconnect”多少个域名的文档。还记得在过去 Internet Explorer 如何限制可以并行下载的图像数量，只是想知道 Chrome 是否可以有一些理由来限制“dns-prefetch preconnect”请求？

例如：多少算太多？

<link rel="dns-prefetch preconnect" href="https://admin.typeform.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://api.amplitude.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://api.segment.io" crossorigin />
<link rel="dns-prefetch preconnect" href="https://app.launchdarkly.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://bam.nr-data.net" crossorigin />
<link rel="dns-prefetch preconnect" href="https://cdn.amplitude.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://cdn.segment.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://customer.api.drift.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://embed.typeform.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://event.api.drift.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://events.launchdarkly.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://fonts.googleapis.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://images.typeform.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://js-agent.newrelic.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://js.driftt.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://load.sumo.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://metrics.api.drift.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://renderer-assets.typeform.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://static.addtoany.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://sumo.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://weclean1.typeform.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://www.google-analytics.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://www.googletagmanager.com" crossorigin />
<link rel="dns-prefetch preconnect" href="https://www.youtube.com" crossorigin />

非常感谢任何链接反馈/建议！

【参考方案1】：

不应过度使用资源提示

首先，如下所述，您应该更喜欢preload。如果您不确切知道您的页面将包含哪些资源，dns-prefetch 和 preconnect 可能是合适的。

resource hint specificationindicates认为最佳连接数是高度偶然的：

每个源的最佳连接数取决于 协商协议，用户当前连接配置文件，可用 设备资源、全局连接限制和其他特定于上下文的 变量。因此，决定应该有多少连接 被打开被推迟到用户代理。

dns-prefetch 和 preconnect 都表示用户代理“应该”启动该过程，这意味着他们不必这样做。

Ilya Grigorik，该规范的编辑，says

也就是说，明智地使用它：每个打开的套接字都会在 客户端和服务器，并且您希望避免打开可能会发生的套接字 没用过。与往常一样，应用、衡量现实世界的影响并迭代到 从此功能中获得最佳性能里程。

同样是 Google 员工的 Sérgio Gomes，echos Ilya 的警告更加具体：

请记住，虽然<link rel="preconnect"> 非常便宜，但它 仍然会占用宝贵的 CPU 时间，尤其是在安全时 连接。如果不使用连接，这尤其糟糕 在 10 秒内，当浏览器关闭它时，浪费了所有这些 连接工作。

一般来说，尽量使用<link rel="preload">，因为它是 进行更全面的性能调整，但请务必将 <link rel="preconnect"> 保留在您的工具带中以应对边缘情况。

Sérgio 继续举例说明preconnect 而不是preload 是合适的。我强烈推荐taking a look。

Ivan Akulov，前 Google 员工，现任网络性能初创公司 CEO，ventures a numerical recommendation：

您希望加速超过 4-6 个域。不建议使用超过 4-6 个域的 <link rel="preconnect" />，因为打开和保持连接是一项昂贵的操作。 <link rel="dns-prefetch" /> 更轻量级，因此如果您也想加快其他第三方域的速度，请将其用于其他第三方域。

但 Ivan 虽然是一个有信誉的消息来源，但并未为此建议提供硬性技术支持。

如果不阅读每个相关浏览器的源代码，就无法辩解地说有多少 dns-prefetch/preconnects 太多了。即使在阅读了源代码之后，它也只能提供关于多少合适的提示。没有硬性限制，但以上权威来源让我们有理由保持谨慎。

但很难知道在哪里画线

只有一种方法可以提高性能：

决定哪些指标对您和您的用户很重要 使用可用的最佳合成和真实用户数字来衡量现状 做出改变并衡量差异

需要多次迭代才能获得最佳配置。最佳提示选择可能会随着时间而改变。从可维护性的角度来看，最好积极地预先连接满足 Sérgio 的“边缘案例”要求的所有内容，并信任浏览器来完成它的工作。但同样，永远不要不经过测试。

其他几点说明

该页面有很多第三方依赖项。我确信您的工作符合您的要求，但这可能是要求管理层重新评估其中一些必要性的好时机。

最后，请记住crossorigin isn't appropriate for every resource hint。这取决于要下载的资源是否会使用 CORS。如果您不知道，这可能会使所需的预连接数量增加一倍。

crossorigin 属性与 rel="preconnect" 一起使用时，不会 描述目标来源在哪里，而是描述什么样的资产 将从该来源下载。如果资产使用 CORS， 需要crossorigin。如果不使用 CORS，则应为 crossorigin 省略。如果两种类型的资产都存在，则有两个资源提示 是必须的。

查看此list of resources that use CORS 以获得指导。

【讨论】：

谢谢，迈克尔，是的，就我的情况而言，我不（想）不断确切地知道该页面将包含哪些资源。这确实是一个复杂的问题，我主要是在从 Chrome 的角度寻找对许多连接的最佳建议折衷方案。 +1

很公平！我讨厌这类问题的答案往往如此模糊。但 Chrome 团队推出功能的速度如此之快，我敢肯定他们不会经常有机会回去讨论更精细的点。

经过一些测试，我最多选择了 5 个。来自 Chrome 的任何更多建议也将是有益的。干杯！

在我们了解更多之前，我已经接受了您的回答，这绝对可以让人们朝着正确的方向前进。暂时还需要更多的测试。再次感谢！

这是一个很好的回应，但它并没有真正回答问题；)

【参考方案2】：

如果您关心 Safari，也请注意这个错误：

https://web.dev/preconnect-and-dns-prefetch/

浏览器对 dns-prefetch 的支持与 preconnect 支持略有不同，因此 dns-prefetch 可以作为不支持 preconnect 的浏览器的后备。

<link rel="preconnect" href="http://example.com">
<link rel="dns-prefetch" href="http://example.com">

推荐 — 为了安全地实施后备技术，请使用单独的 链接标签。

<link rel="preconnect dns-prefetch" href="http://example.com">

不推荐——在同一个文件中实现 dns-prefetch 回退 标签会导致 Safari 中的一个错误，即取消预连接。

【参考方案3】：

在旧版 Chrome 中，并发 DNS 查找限制为六个。从适用于 Windows、Mac 和 Linux 的 Chrome 版本 26 开始，有一个异步 DNS 解析器，它有效地消除了这个限制（或者可能只是增加了它）：

“6 个 DNS 请求不再适用于异步 DNS 解析器，但您的观点仍然成立.. 我们限制了飞行中解析的数量。” — Ilya Grigorik，Web Google 的性能工程师 (via Twitter)

【参考方案4】：

我还很新，还不能添加评论，所以添加一个答案。

根据我自己的测试，Chrome 似乎有一个TTL of 1000 in the DNS Cache 这可能是“过早”打开"dns-prefetch preconnect" 连接实际上可能会对所需性能产生负面影响的原因。

您也可以查看preconnect vs dns-prefetch resource hints

“TTL”是生存时间的缩写