单页应用又慢又贵：CDN 与源站先改哪几步

单页应用（SPA）上线后最常见的抱怨是：首屏白、切换慢、流量账单难看。先别同时改构建、网关、业务代码。按「浏览器 → CDN → 源站 → 业务」分层，每层只做能验证的几步。

你遇到的问题

2 分钟诊断

1. 打开 Network：HTML 与主 JS 的 TTFB、是否 HIT/MISS（看 CDN 响应头）。
2. 主 JS/CSS 是否带 内容哈希 且长缓存。
3. HTML 是否短缓存或协商缓存（SPA 需要能快速拿到新入口）。

分层解法

1. CDN：静态进边缘

• 何时需要：用户分布广，或源站带宽贵
• 做什么：_next/static、hashed js/css/img 走 CDN；配置合理 TTL
• 验收：静态资源 HIT 率上升；边缘 TTFB 明显低于直回源

注意：CDN 不是自动变快——缓存不到或 Key 太碎，会一直 MISS。

2. 源站：只扛动态与入口 HTML

• HTML / API / SSR 结果按业务设短缓存或私有缓存
• 压缩（gzip/br）、HTTP/2、连接复用
• 验收：HTML 更新后用户能较快拿到新版本；API 延迟稳定

3. 业务与构建：减少必须下载的字节

• 路由级拆包、去掉无用 polyfill、图片尺寸与格式
• 关键数据与关键渲染路径优先
• 验收：LCP / INP；主 bundle 体积对比

4. 国际化特殊点

• 静态资源可全球同一份；HTML/API 可能要按地区源站或 Edge
• 避免「所有语言的巨石包」一次性下发
• 验收：各语言首屏资源列表是否只含当前语言必需项

建议落地顺序（一周）

1. 给 hashed 静态资源长缓存，确认 CDN HIT。
2. 给 HTML 合理短缓存或始终回源校验。
3. 用分析工具砍主包（目标：关键路由可交互所需 KB 下降）。
4. 再考虑多区域源站——多数站点前三步更值钱。

如何验证

• 静态响应头可见缓存命中信息（视 CDN 厂商）
• 发版后旧哈希 404/替换策略符合预期，用户不卡死旧入口
• LCP 或「可交互时间」有前后对比
• 回源流量或带宽账单下降（或持平但体验更好）

下一步

1. 先抓一条慢页面的 HAR，标出最大的三个资源。
2. 只优化它们的缓存与体积，再谈架构升级。
3. 网关层超时与缓存可与 Nginx 排障文对照。