preconnect在真实HTTPS场景下可节省200–600ms SSL握手时间，前提是满足四条件：HTTPS协议、href仅含协议+域名、带正确crossorigin属性、JS在1秒内发起fetch且服务端返回CORS头。

preconnect 能省多少 SSL 握手时间

在真实 HTTPS 场景下，rel="preconnect" 可跳过 DNS 查询、TCP 三次握手和 TLS 协商三步，对未缓存连接的第三方域名，通常能减少 200–600ms 的 TTFB（首字节时间）。这个收益在弱网、高延迟或移动端更明显；本地开发环境或强缓存命中时基本测不出来——因为连接根本没重建。

为什么加了 preconnect 却没省到 SSL 时间

最常见原因是浏览器压根没复用预建连接，本质是「连了但用不上」。关键失效点包括：

• crossorigin 属性漏写、写错（如 crossorigin="" 是非法 HTML，整条 <link> 被忽略）
• href 带路径或参数（如 https://cdn.example.com/main.js → 必须缩为 https://cdn.example.com）
• 放在 <link rel="stylesheet"> 或 <script> 后面 → 浏览器已开始加载资源，空闲窗口关闭
• 目标域名实际走 HTTP（http://api.example.com）→ Chrome 直接跳过
• 同源域名（如 https://your-site.com）→ 浏览器自动复用连接，preconnect 无意义

HTTPS 第三方 API 加 preconnect 的硬性条件

只有同时满足以下四点，SSL 握手才真被提前完成：

• 域名必须是 HTTPS 协议（https://api.example.com ✅，http:// ❌）
• href 只含协议+域名（https://api.example.com ✅，https://api.example.com/v1/ ❌）
• 必须带 crossorigin 属性（<link rel="preconnect" href="https://api.example.com" crossorigin> ✅）
• 页面 JS 在加载后 1 秒内就调用 fetch()，且服务端返回了 Access-Control-Allow-Origin 头

特别注意：如果 fetch() 显式传了 credentials: 'include'，服务端还必须返回 Access-Control-Allow-Credentials: true，否则预建的连接仍无法复用。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

立即学习“前端免费学习笔记（深入）”；

怎么验证 preconnect 是否真正生效

不能只看 HTML 里有没有写，得查网络行为：

• Chrome DevTools → Network → 右键表头勾选 Connection ID 和 Protocol
• 找到目标请求（如 fonts.gstatic.com），确认其 Connection ID 与 preconnect 条目一致
• 观察 Initial connection 时间是否接近 0ms（理想状态）
• 若该请求仍显示 connect 耗时 >200ms，或 preconnect 行本身耗时超过 500ms，说明没起作用

真实环境测试很重要——本地开发因代理或自签名证书，preconnect 往往不触发 TLS 协商，务必部署到 HTTPS 环境再验证。