别卷SSR，3行HTML让页面起飞

加 3 行代码，我把页面 FCP 从 1.8s 砍到了 1.2s

直接上结果。在移动端 H5 资讯页上，非缓存状态、4G 弱网模拟，这三行代码带来的提升相当可观。

指标	优化前	优化后	提升
FCP（首次内容绘制）	1.8 s	1.2 s	↓33%
LCP（最大内容绘制）	2.9 s	2.1 s	↓27%
页面可交互时间	2.3 s	1.6 s	↓30%

没错，就靠下面这 3 行代码。没有动任何打包配置，没有引入任何第三方库，纯纯的复制粘贴即可生效。

3 行代码，粘贴即用

你只需要把 href 换成你自己项目的实际地址即可。

这三行到底干了什么？

1 preconnect —— 提前握手，省下 DNS + TCP + TLS 时间

浏览器要请求一个第三方域名（比如接口 API、CDN、统计服务），正常流程是：DNS 解析 → TCP 连接 → TLS 协商（如果是 HTTPS）→ 然后才发请求。每一步都是几十到几百毫秒。

preconnect 告诉浏览器：“这个域名我等下要用，你现在就去把连接建立好”。等到真正发请求时，连接已经 ready，直接发送即可。

节省时间：平均 120~300ms（尤其在弱网下非常明显）。

2 preload —— 提前加载关键资源，不让浏览器排队

浏览器解析 HTML 是顺序的，一般要到 CSS 里遇到 @font-face 才会去下载字体。但字体往往不会阻塞渲染，而是晚到——导致 FOIT（Flash of Invisible Text） 或 FOUT。

preload 强制浏览器 以最高优先级 提前下载这个资源，不依赖 CSS/JS 的解析顺序。

适用资源：

• 关键字体（尤其是英文字体、iconfont）
• 首屏背景大图
• 关键 CSS/JS（但一般动态 import 更常见）

注意：as 属性必须写对，否则浏览器可能不生效或重复下载。

3 dns-prefetch —— 轻量版 preconnect，只管 DNS

preconnect 虽然强大，但会做 DNS + TCP + TLS，开销较大。如果只是猜测可能会用到的域名，或者想更轻量地覆盖更多域名，用 dns-prefetch。

浏览器只做 DNS 解析，存到本地缓存。后面真正请求时，跳过 DNS 这一步。

典型场景：

• 第三方统计脚本（Google Analytics、百度统计）
• 社交分享组件（如 share.js 依赖的域名）
• 图片 CDN 域名

实战：你应该怎么放？

一个完整的 配置示例：

顺序建议：preconnect 最先，因为它最重但最有效；preload 其次；dns-prefetch 可以放多个，放在最后。

避坑指南（看完再去用）

不要滥用 preconnect

每个 preconnect 都会维持一个连接，占用浏览器资源。建议不超过 4~6 个。超过后浏览器可能会忽略或延迟。

preload 不是越多越好

• 只 preload 首屏绝对需要 的资源（字体、关键图片）
• 不要 preload JS/CSS，如果它们不在首屏，反而会延迟其它资源加载

最佳实践组合

• 当前业务 API 域名 → preconnect
• 当前页面的关键字体/首屏图片 → preload
• 多个第三方统计、CDN → dns-prefetch

你自己怎么验证效果？

动手验证一下，其实很简单：

1. 打开 Chrome DevTools → Network 面板
2. 勾选 Disable cache（模拟首次访问）
3. 设置网络为 Slow 3G 或 Fast 3G
4. 刷新页面，看 Waterfall 图
   • 对比加这三行代码前后，/api/xxx 接口的 Waiting for server 时间
   • 字体的 Start 时间是否明显提前

你会在 Waterfall 里看到：

• preconnect 域名旁边会出现一个灰色的连接建立阶段，发生在实际请求之前。
• preload 的资源会出现在非常靠前的加载位置，颜色标识为 Highest。

写在最后

这三行代码属于 “投入产出比极高” 的优化手段：

• 成本：复制粘贴，改几个域名
• 收益：首屏加载肉眼可见变快，尤其对移动端和弱网用户特别友好

下次你接到“页面加载慢”的性能优化任务，第一件事不是改代码，而是在 里加上这三行。