最新下载
热门教程
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
别卷 SSR 了：3 行 HTML 让页面起飞
时间：2026-07-24 10:45:50 编辑：袖梨 来源：一聚教程网
加 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 行代码，粘贴即用
复制代码<link rel="preconnect" href="https://api.example.com">
<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example.com">
你只需要把 href 换成你自己项目的实际地址即可。
这三行到底干了什么？
1️⃣ preconnect —— 提前握手，省下 DNS + TCP + TLS 时间
复制代码<link rel="preconnect" href="https://api.example.com">
浏览器要请求一个第三方域名（比如接口 API、CDN、统计服务），正常流程是：
DNS 解析 → TCP 连接 → TLS 协商（如果是 HTTPS）→ 然后才发请求。
每一步都是几十到几百毫秒。
preconnect 告诉浏览器：“这个域名我等下要用，你现在就去把连接建立好”。
等到真正发请求时，连接已经 ready，直接发送即可。
节省时间：平均 120~300ms（尤其在弱网下非常明显）。
2️⃣ preload —— 提前加载关键资源，不让浏览器排队
复制代码<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
浏览器解析 HTML 是顺序的，一般要到 CSS 里遇到 @font-face 才会去下载字体。
但字体往往阻塞文字渲染？实际上不会阻塞，但会晚到——导致 FOIT（Flash of Invisible Text） 或 FOUT。
preload 强制浏览器 以最高优先级 提前下载这个资源，不依赖 CSS/JS 的解析顺序。
适用资源：
- 关键字体（尤其是英文字体、iconfont）
- 首屏背景大图
- 关键 CSS/JS（但一般动态 import 更常见）
注意：as 属性必须写对，否则浏览器可能不生效或重复下载。
3️⃣ dns-prefetch —— 轻量版 preconnect，只管 DNS
复制代码<link rel="dns-prefetch" href="https://cdn.example.com">
preconnect 虽然强大，但会做 DNS + TCP + TLS，开销较大。
如果只是猜测可能会用到的域名，或者想更轻量地覆盖更多域名，用 dns-prefetch。
浏览器只做 DNS 解析，存到本地缓存。后面真正请求时，跳过 DNS 这一步。
典型场景：
- 第三方统计脚本（Google Analytics、百度统计）
- 社交分享组件（如 share.js 依赖的域名）
- 图片 CDN 域名
实战：你应该怎么放？
复制代码<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<!-- 1. 最关键的当前页面 API 域名，用 preconnect -->
<link rel="preconnect" href="https://your-api.com">
<!-- 2. 字体或首屏大图，用 preload -->
<link rel="preload" href="/static/fonts/Inter.woff2" as="font" crossorigin>
<!-- 3. 多个第三方域名，用 dns-prefetch（轻量覆盖） -->
<link rel="dns-prefetch" href="https://google-analytics.com">
<link rel="dns-prefetch" href="https://cdn.yourimg.com">
<!-- 其它 head 内容 -->
</head>
顺序建议：
preconnect 最先，因为它最重但最有效；
preload 其次；
dns-prefetch 可以放多个，放在最后。
避坑指南（看完再去用）
不要滥用 preconnect
每个 preconnect 都会维持一个连接，占用浏览器资源。
建议不超过 4~6 个。超过后浏览器可能会忽略或延迟。
️ preload 不是越多越好
- 只 preload 首屏绝对需要 的资源（字体、关键图片）
- 不要 preload JS/CSS，如果它们不在首屏，反而会延迟其它资源加载
最佳实践组合
- 当前业务 API 域名 →
preconnect - 当前页面的关键字体/首屏图片 →
preload - 多个第三方统计、CDN →
dns-prefetch
你自己怎么验证效果？
- 打开 Chrome DevTools → Network 面板
- 勾选 Disable cache（模拟首次访问）
- 设置网络为 Slow 3G 或 Fast 3G
- 刷新页面，看 Waterfall 图
- 对比加这三行代码前后，
/api/xxx接口的 Waiting for server 时间 - 字体的 Start 时间是否明显提前
- 对比加这三行代码前后，
你会在 Waterfall 里看到：
preconnect域名旁边会出现一个灰色的连接建立阶段，发生在实际请求之前。preload的资源会出现在非常靠前的加载位置，颜色标识为Highest。
写在最后
这三行代码属于 “投入产出比极高” 的优化手段：
- 成本：复制粘贴，改几个域名
- 收益：首屏加载肉眼可见变快，尤其对移动端和弱网用户特别友好
下次你接到“页面加载慢”的性能优化任务，第一件事不是改代码，而是在 <head> 里加上这三行。
如果测试数据好看，记得回来点个赞