dns-prefetch与preconnect在浏览器缓存存在时的作用及性能影响

好问题！咱们一步步拆解你关心的几个点：

1. 当外部JS已在浏览器缓存中时，dns-prefetch和preconnect的行为 #

首先要明确：浏览器的资源缓存（比如JS文件）、DNS缓存、TCP/TLS连接缓存是三个独立的缓存体系，互相不影响：

• 对于dns-prefetch：如果浏览器已经缓存了该域名的DNS解析结果（通常TTL在几分钟到几小时），会直接复用缓存，不会发起新的DNS请求，几乎没有额外开销。哪怕JS在缓存里，只要DNS缓存过期了，dns-prefetch依然会提前解析域名，避免后续请求的DNS等待。
• 对于preconnect：如果浏览器已经有针对该域名的活跃连接（比如keep-alive连接）或者未过期的连接缓存，会直接复用现有连接，不会重新建立TCP/TLS连接。只有当连接缓存过期或不存在时，才会提前建立连接，而这个开销本身也远小于实际请求资源的开销。

2. 会不会不必要地增加页面加载时间？ #

几乎不会。
浏览器对这些预取操作有智能判断机制：如果检测到已经有可用的DNS缓存或连接缓存，会快速跳过这些预取步骤，不会产生多余的网络请求。即使没有缓存，dns-prefetch和preconnect的开销也非常小（DNS请求通常几毫秒，TCP握手+TLS协商几十毫秒），相比它们能带来的加速收益，这点开销完全可以忽略。

3. 是否仅在首次页面加载时发挥作用？ #

当然不是！它们在很多非首次加载场景下依然有用：

• 当用户清空了DNS/连接缓存，但JS资源仍在缓存中时，预取操作能提前完成DNS解析和连接建立，避免后续同域名资源（比如页面中的图片、其他脚本）加载时的等待。
• DNS缓存和连接缓存的过期时间通常比JS资源的缓存时间短很多，当JS还在缓存但DNS/连接缓存已过期时，预取依然能为后续的请求（哪怕是同一JS的重新验证请求）节省时间。
• 即使页面只有这一个外部JS，当用户再次访问页面时，如果DNS/连接缓存已经过期，预取依然能加速JS资源的验证或重新加载过程。

内容的提问来源于stack exchange，提问作者Sr. Schneider