S14-J04 · SPA 首屏为什么慢：三阶段拆解

适用读者：首屏慢、但只会"再压一压"的人。
前置：S14-J02、J03。
实测环境：Vite 5.4.21 / Vue 3.5（2026-11-05）。
覆盖旧文：392(164) 300(23) = 187 点。
覆盖扩展：E-S14-010（首屏三阶段）。
上一篇：S14-J03 · 预压缩与 CDN
下一篇：S14-A01 · 前端部署与缓存策略。

1. 一句话结论

首屏时间 = 下载 + 解析执行 + 渲染三阶段之和。多数人只优化"下载"（压缩/CDN），但这常常不是最大项。

① 下载 HTML → ② 下载 JS/CSS → ③ 解析执行 JS → ④ 首屏渲染
   网络         网络               CPU            浏览器

阶段	优化手段	收益
① HTML	减少阻塞资源、内联关键 CSS	中
② 资源下载	压缩（J03）、CDN、HTTP/2	高（但边际递减）
③ 解析执行	拆包 + 懒加载（J02）	高（尤其低端机）
④ 渲染	骨架屏、SSR/SSG	高（体验）

2. 为什么"压缩到极致"仍然慢（E-S14-010）

实测数据（J02/J03）：

指标	数值
vendor 原始	65,849 B
gzip -6	25,913 B
gzip -9	25,886 B

"压缩已经到底了"：-6 到 -9 只差 27 B。继续压没有意义，要换阶段：

换阶段	手段
减少要执行的代码	路由懒加载、组件按需引入
减少要下载的代码	manualChunks + 只加载首屏需要的 chunk

判据："JS 体积已经 gzip 到 100 KB 以内了吗？" 是 → 别再压，去看解析与执行。

3. 首屏优化的优先级（按收益/成本）

#	手段	说明
1	路由懒加载	首屏只下首页 chunk（J01）
2	关键 CSS 内联	避免 CSS 阻塞渲染
3	预连接/预加载	`<link rel="preload">`
4	骨架屏	感知性能提升
5	SSR/SSG	真正减少首屏 JS 依赖
6	CDN + HTTP/2	见 J03

"SSR 是不是必须"：不是——SSR 增加服务端复杂度（S07-A02 的 WebFlux 取舍同理）。内容型站点（博客）SSG 更划算。

4. 用 AI 检查页面设计（A-300）

用途	说明
生成初稿	快速出布局
检查清单	对比度、间距一致性、焦点状态
局限	不了解业务约束、不懂可访问性细节

判据："AI 输出的是"可用的草稿"还是"可上线的实现"？" 前者 → 直接用；后者 → 必须人工过一遍可访问性与响应式。

5. 五个误区

误区	真相
"首屏慢就是资源大"	解析执行常才是 CPU 瓶颈
"压到 -9 就最快"	边际收益近零（实测）
"SSR 一定能解决首屏"	增加服务端复杂度
"骨架屏是骗用户"	提升感知性能，是正当手段
"AI 生成的设计能直接上线"	需人工校验可访问性与响应式

6. 自检

首屏的四个阶段？
为什么"继续压缩"没有意义？
优化优先级前三条？
什么时候该用 SSG 而不是 SSR？
AI 生成设计的正确用法？

7. 下一篇

S14-A01 · 前端部署与缓存策略

首屏讲完，进架构师层：index.html 与 assets 为什么必须用不同缓存策略。

本篇属于系列《S14 · 前端与可视化》。旧文来源：A-392/300；扩展点 E-S14-010。压缩数据沿用 J03 实测。