前端首屏提速 3 秒：性能优化实战指南

前端首屏提速 3 秒：性能优化实战指南

用户在手机上打开一个页面，如果 3 秒内看不到有意义的内容，很大一部分人会直接退出。首屏时间从来不是"能跑就行"的技术细节，它同时对应着跳出率、转化率和搜索排名。但"优化首屏"也不是一句口号，它是一条从网络传输、资源加载、关键渲染路径，一直到构建配置与线上监控的完整链路。任何单点优化——比如只把图片压一压——往往收益有限，因为你没有打中真正的瓶颈。本文按"先测量、再分层优化、最后守住成果"的顺序，给出一套可以直接落地的实战方案，目标是把首屏的 P75 LCP 压进 3 秒以内，并稳定住。

一、先把首屏拆开：从 TTFB 到 LCP 的五个阶段

很多团队一上来就压缩图片、上 CDN，结果收益不明显，原因是没有定位到真正的瓶颈。首屏时间不是一个数字，而是若干可测量阶段的串联，把每一段的耗时单独拉出来，优化才有靶心。

第一段是 TTFB（Time to First Byte），从发起请求到收到第一个字节，涵盖 DNS 解析、TCP 与 TLS 握手、服务端处理、回源和排队。在移动网络下，如果 TTFB 超过 800 毫秒，绝大多数情况下瓶颈在后端或 CDN 回源，前端再怎么折腾都无济于事。第二段是 FCP（First Contentful Paint），用户看到"有东西了"的时刻。第三段是 LCP（Largest Contentful Paint），最大内容元素完成绘制的时刻，通常落在首屏大图、主标题或视频封面上，这是 Core Web Vitals 的核心指标，目标是不超过 2.5 秒。第四段是 INP（Interaction to Next Paint），衡量交互响应，目标不超过 200 毫秒，它已经取代了过去的 FID。第五段是 CLS（Cumulative Layout Shift），累积布局偏移，目标不超过 0.1，字体切换和未设置尺寸的图片是主要肇事者。

测量要分成两套数据看。实验室数据（Lighthouse、WebPageTest、DevTools Performance 面板）用于定位问题和复现，现场数据（RUM）用于做决策，因为只有真实用户的设备和网络才代表真实体验。线上采集建议直接用 web-vitals 库，把 LCP、INP、CLS、TTFB 按页面类型、设备档位、网络类型和发布版本四个维度上报，并且只在标签页可见时累计、在首次交互后停止上报，避免后台标签页和"用户切走"的样本污染分布。

接下来要写性能预算，把它当作合同而不是愿望：P75 LCP 不超过 2.5 秒，P75 TTFB 不超过 600 毫秒，首屏内联关键 CSS 不超过 14KB，首屏 JS 传输体积不超过 170KB（Brotli 后），首屏字体文件不超过 2 个且总体积不超过 120KB。预算写进 CI，超过阈值直接让流水线失败，性能才不会随着需求迭代悄悄劣化。

二、网络与传输层：把 TTFB 和资源到达时间压到最低

这一层的收益往往最大也最容易被忽视。静态资源全部走 CDN 是基本功，进一步要开启 HTTP/3 配合 QUIC，减少握手往返，尤其在弱网和切换网络时收益明显；HTTP/2 的头部压缩与多路复用继续保留，两者并不冲突。

利用 Early Hints：服务端在开始处理 HTML 的同时，先返回 103 状态码，并带上 Link 头声明 rel=preload 的关键 CSS 和字体，浏览器就能在 HTML 主体到达之前提前开始下载。主流反向代理和边缘平台都已支持这个能力，配置成本很低，常见收益在首屏提前 100 到 300 毫秒。与此配套的是 preconnect 与 dns-prefetch：对首屏真正必需的第三方域提前建立连接，但要克制，每个 preconnect 都会占用连接资源，建议控制在 4 个以内，并把不再使用的域名及时清理。

缓存策略要区分对待。HTML 是入口文档，建议用 Cache-Control: no-cache 配合 ETag 做协商缓存，或者用 s-maxage=60, stale-while-revalidate=300 让 CDN 边缘先复用旧版本、后台异步回源刷新，用户几乎感知不到回源延迟；带内容哈希的 JS、CSS、图片则用 max-age=31536000, immutable，让它们彻底留在浏览器缓存里。压缩方面，文本资源用 Brotli 并在构建期做静态预压缩（q11），图片按需输出 AVIF 或 WebP，配合 srcset 与 sizes 让移动端不下载桌面尺寸的大图。首屏大图显式加 fetchpriority="high"，非首屏图片统一 loading="lazy" 与 decoding="async"，避免它们和首屏资源抢带宽。

举两个具体数字：某详情页把首屏主图从 780KB 的 PNG 换成 96KB 的 AVIF，LCP 从 3.4 秒降到 2.6 秒；同一个页面把 HTML 通过边缘缓存把 TTFB 从 1.2 秒压到 220 毫秒，FCP 直接提前了约 0.9 秒。这两件事加起来，几乎不碰业务代码就拿到了 1.7 秒的收益。

三、关键渲染路径：别让 CSS 和字体卡住第一帧

浏览器必须先构建 CSSOM 才能开始渲染，所以任何同步的样式表链接都会阻塞首屏。正确做法是提取首屏关键 CSS 内联进 head，控制在 14KB 以内（大致一个 TCP 慢启动窗口的大小），其余样式通过预加载再切换为样式表的方式异步加载，并保留 noscript 兜底。绝对不要在 CSS 里使用 @import，它会让请求变成串行，凭空多出一到两个 RTT。样式的 media 属性也要用起来，打印样式和只在窄屏生效的样式不应该阻塞首屏。

字体是中文站点最容易翻车的地方。首先只加载真正用到的字重和字符子集，中文字体全量动辄 5 到 10MB，必须按页面实际使用的字符集做子集化，或者干脆退回系统字体栈。其次设置 font-display: swap 或 optional，让文本先用回退字体显示。再次，在 @font-face 里用 size-adjust、ascent-override、descent-override 校准回退字体的度量，让替换前后行高和基线接近，这样才会出现"字体换了一次但页面没有跳动"的效果，CLS 能显著下降。对确实关键的首屏字体做 preload，但只 preload 一个，多了反而挤占带宽。

脚本方面，默认全部加 defer，无依赖的独立埋点脚本用 async，现代浏览器里的 module 脚本天然延迟执行，可以用 modulepreload 提前拉取入口依赖。HTML 结构上，首屏内容应该由服务端直接输出（SSR 或 SSG），不要等 JS 渲染，否则会出现"白屏加转圈"的假 LCP——真正的 LCP 元素可能是一张骨架屏的占位块，而用户看到的是空的。骨架屏可以改善感知速度，但必须固定尺寸，否则它自己就会变成 CLS 的元凶。

四、JavaScript：下载、解析、执行三笔账都要算

JS 的成本从来不只是文件大小，而是下载、解析编译、执行三段之和。一份 Brotli 后 170KB 的脚本，在中端安卓机上的解析加执行时间可能超过 1.5 秒，而这 1.5 秒里主线程完全无法响应用户。

第一件事是代码分割。按路由拆是最基本的，更进一步要按交互拆：评论区、地图、富文本编辑器、图表这类组件，在用户真正需要时再动态 import。首屏只加载首屏需要的代码，这条原则能砍掉一大半体积。第二件事是保证 tree shaking 真正生效，在 package.json 里正确声明 sideEffects，避免整包引入工具库；用 lodash-es 的具名导入或原生方法替代全量引入，日期格式化优先用 Intl.DateTimeFormat 而不是重量级日期库，图表库按需注册组件而不是全量注册。

第三件事是治理第三方脚本，这是最容易被忽略的"隐形杀手"。每一个第三方脚本都应该有明确的负责人和续期审批，长期没人维护的直接下线。对于分析、会话录制、A/B 测试这类脚本，可以用 Web Worker 沙箱方案（例如把脚本搬到 worker 里运行，主线程只保留一个通信桩），或者用 iframe 隔离。实测中，仅仅是把三四个分析脚本移出主线程，就能减少 300 到 600 毫秒的主线程阻塞时间。

第四件事是拆分长任务。一次性处理上万条数据、同步执行的大循环、递归渲染，都会产生超过 50 毫秒的长任务，直接拖垮 INP。用 scheduler.yield() 在任务之间主动让出主线程（不支持时降级到 setTimeout 或 requestIdleCallback），把大计算拆成小块，必要时整体迁移到 Web Worker。第五件事是控制水合成本：SSR 只解决"看得见"，交互还需要 hydration 重新执行一遍组件逻辑。用岛屿架构或服务端组件把客户端边界压到最小，只给真正需要交互的组件打上客户端标记，其余的保持纯服务端渲染。

最后一条原则是：不要用 JS 做 CSS 能做的事。滚动动画、悬停效果、进度条优先交给 CSS Animation 或滚动驱动动画，这些运行在合成线程上，不占主线程。

五、框架与构建：当前阶段的默认姿势

渲染模式要按页面类型选择，而不是全站一刀切。营销页、文档站、博客用 SSG 加 CDN，构建期生成静态 HTML，首屏几乎只剩网络时间；个性化首页用流式 SSR 配合 Suspense，先把页面外壳和骨架吐给浏览器，慢的数据请求后到并逐步填充；登录后的重交互应用可以考虑 CSR 加路由级预取，但要保证首屏外壳足够快。

流式渲染有个关键细节：把 await 数据请求推到尽可能深的叶子组件，绝不要在最外层 await 一整个大对象再渲染，那样会阻塞整个 HTML 流，流式渲染就退化成了普通 SSR。同时确认传输层使用分块编码，否则响应会被缓冲，流式的意义荡然无存。

预渲染是当下性价比很高的手段。用 Speculation Rules API 对"高概率被点击"的链接做 prerender，用户点击时几乎是瞬时切换。但一定要设置合理的触发积极性（保守或中等）和配额上限，避免在移动网络下把用户带宽吃光，也要避免触发不必要的埋点。构建侧则要定期检查产物体积，用 splitChunks 把框架、UI 组件库、业务代码拆成独立 chunk，保证日常业务改动不会让框架 chunk 的哈希失效，用户不必反复下载不变的部分。图片和字体尽量交给框架提供的组件处理，自动 srcset、格式协商和优先级声明比手写更不容易出错。

六、守住成果：监控、预算与回归防护

优化做完不等于结束，没有监控的性能优化通常会在三个迭代周期内反弹。第一，建立 RUM 看板，按版本对比 P75 指标，用发布版本号做关联，发布后 30 分钟自动对比上一个版本的 LCP，恶化超过 15% 就告警。第二，把性能预算接入 CI，对首屏路由跑三次 Lighthouse 取中位数，对 LCP、性能分数、JS 体积设阈值，超限阻止合并；注意 CI 机器性能波动大，阈值要留足余量，只看趋势而不是绝对分数。第三，做灰度验证，性能改动同样应该评估对转化率和停留时长的真实影响，而不是只盯着绿色分数。第四，沉淀一份团队性能守则：引入新依赖必须说明体积成本，新增第三方脚本必须审批，所有图片必须声明宽高，首屏路由的新增组件必须评估是否真的需要同步加载。把规则写下来，性能才从个人技能变成组织能力。

七、一份按收益排序的改造清单

如果你只有一个迭代周期，按下面的顺序做，收益最陡：把首屏图片转为 AVIF 或 WebP 并收敛尺寸、加 fetchpriority，通常能省 0.5 到 1.5 秒；开启边缘缓存与 HTTP/3，把 TTFB 从 1 秒以上压到 200 毫秒量级，省 0.5 到 0.8 秒；内联关键 CSS 并异步加载其余样式，省 0.3 到 0.6 秒；做路由级代码分割并把第三方脚本移出主线程，省 0.4 到 0.9 秒；字体子集化并校准回退度量，省 0.2 到 0.5 秒，中文站点收益更大；最后用流式 SSR 加组件级懒加载，同时改善 LCP 与 INP。

一个可参考的案例：某内容社区首页在 2026 年初的现场数据是 P75 LCP 5.2 秒。团队按上面的顺序推进：图片转 AVIF 并统一尺寸减少 1.1 秒，HTML 边缘缓存减少 0.9 秒，关键 CSS 内联加中文字体子集减少 0.6 秒，首屏 JS 从 420KB 降到 165KB 再减少 0.5 秒，最终 P75 LCP 稳定在 2.1 秒，跳出率下降约 12%，注册转化提升约 8%。更重要的是，每一项改动都是可独立回滚、可独立归因的，团队清楚知道每一秒是从哪里省出来的。

3 秒不是终点，而是一个可以被度量、被预算约束、被监控守住的工程目标。先把首屏拆成可测量的阶段，再去优化当下最贵的那一环，最后用预算和告警把成果锁死——这套流程比任何单点技巧都更接近"持续快"而不是"快