我们在Chrome中应该“dns-prefetch preconnect”多少个域名才合适？

Question

我们在Chrome中应该“dns-prefetch preconnect”多少个域名才合适？

8

当我们想让一个使用第三方小部件/插件/附加组件/分析等的网站保持极快的速度时，其中之一要达到这个目标的要求是对每个单独的域名进行“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 />

任何链接的反馈/建议都非常欢迎！

- dankilev

4个回答

2

旧版 Chrome 中同时进行的 DNS 查询数量有限制，最多只能进行六个。从 Chrome 26 版本开始，在 Windows、Mac 和 Linux 上都引入了异步 DNS 解析器，有效地移除了这一限制（或者说将其增加了）：

“使用异步 DNS 解析器不再受到 6 个 DNS 请求的限制，但你的观点仍然正确...我们仍会限制并发解析的数量。”——Ilya Grigorik，Google 网络性能工程师（来自 Twitter）

- Rick Davies

2

如果您关心Safari，还要注意这个错误：

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

最初的回答。

Browser support for dns-prefetch is slightly different from preconnect support, so dns-prefetch can serve as a fallback for browsers that don't support preconnect.
<link rel="preconnect" href="http://example.com">
<link rel="dns-prefetch" href="http://example.com">
Recommended — To safely implement the fallback technique use separate link tags.
<link rel="preconnect dns-prefetch" href="http://example.com">
Not recommended — Implementing dns-prefetch fallback in the same tag causes a bug in Safari where preconnect gets cancelled.

- Null

1

我是一个相对新手，无法添加评论，因此添加答案。

根据我的测试，Chrome在DNS缓存中似乎有1000的TTL 这可能是打开“太早”的"dns-prefetch preconnect"连接实际上会对所需性能产生负面影响的原因。

您还可以检查preconnect vs dns-prefetch resource hints

“TTL”是“Time To Live”的缩写

- user11410271

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- crenshaw-dev · Accepted Answer

资源提示不应过度使用

首先，如下所述，您应该优先使用preload。如果您不确定页面将包含哪些资源，则dns-prefetch和preconnect可能是适当的选择。

资源提示规范指出最佳连接数高度依赖于：

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

无论dns-prefetch还是preconnect都表明用户代理“应该”启动进程，这意味着它们不必这样做。

该规范的编辑Ilya Grigorik说

尽管如此，请明智地使用：每个打开的套接字都会产生客户端和服务器的成本，并且您希望避免打开可能未使用的套接字。一如既往，应用、测量实际影响并迭代以从此功能中获得最佳性能里程。

Sérgio Gomes，也是谷歌员工，回应 Ilya 的警告并更具体地指出：

请记住，尽管 <link rel="preconnect"> 很便宜，但它仍然会占用宝贵的 CPU 时间，特别是在安全连接上。如果浏览器在 10 秒内没有使用该连接，则会关闭它，从而浪费所有早期的连接工作。

一般来说，尽可能使用 <link rel="preload">，因为它是一个更全面的性能调整，但对于边缘情况，请保留 <link rel="preconnect">。

Sérgio 继续举了几个例子，说明何时使用 preconnect 而不是 preload。我强烈建议查看这些例子。

Ivan Akulov，前谷歌员工，现任网络性能初创公司 CEO，提出数字建议：

你想加速4-6个以上的域名。不建议使用超过4-6个域名的，因为打开和保持连接是一项昂贵的操作。更轻量级，所以如果您想加速其他第三方域名，请使用它。

但是Ivan虽然是一个值得信赖的来源，但他没有提供这个建议的硬技术支持。

没有阅读每个相关浏览器的源代码，就不可能有理由说dns-prefetch/preconnect的数量太多了。即使阅读了源代码，也只能提供适当数量的提示。没有硬性限制，但上述权威来源让我们有理由谨慎。

但很难知道在哪里划分线。

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

1.确定对您和您的用户重要的指标 2.使用最佳可用的综合和实际用户数字来测量现状 3.进行更改并测量差异

需要多次迭代才能找到最佳配置。而且最佳提示选择可能会随时间而变化。从可维护性的角度来看，最好积极地预连接符合Sérgio的“边缘情况”要求的所有内容，并信任浏览器完成其工作。但是，再次强调，不要没有测试就这样做。

还有一些注意事项。

那个页面有很多第三方依赖项。我确信您正在按照要求工作，但现在可能是向管理层询问重新评估其中一些必要性的好时机。

最后，请记住crossorigin不适用于每个资源提示。这取决于要下载的资源是否使用CORS。如果您不知道，那么可能需要加倍预连接数。

当与rel =“preconnect”一起使用时，crossorigin属性不描述目标来源的位置，而是描述将从该来源下载哪种资产。如果资产使用CORS，则需要crossorigin。如果不使用CORS，则应省略crossorigin。如果两种类型的资产都存在，则需要两个资源提示。

请查看使用CORS的资源列表以获取指导。