“慢”不是诊断结果
页面感觉很慢时，第一个有用的问题不是“哪个框架该负责”，而是：时间究竟花在了哪里？ 一次请求会跨过多个边界，每个边界需要不同的测量方法。
| 阶段 | 常见工作 | 值得观察的信号 |
|---|---|---|
| 边缘节点 | 路由与缓存查找 | 缓存状态、Age 和节点区域 |
| 服务器 | 获取数据并生成 HTML | 首字节时间 |
| 网络 | 建立连接与传输 | 协议和载荷大小 |
| 浏览器 | 解析、样式、布局和绘制 | Navigation Timing 与视觉稳定性 |
从一个小测量开始
const navigation = performance.getEntriesByType(
'navigation',
)[0] as PerformanceNavigationTiming
const serverWait = navigation.responseStart - navigation.requestStart
const download = navigation.responseEnd - navigation.responseStart
const interactivePath =
navigation.domContentLoadedEventEnd - navigation.startTime
console.table({ serverWait, download, interactivePath })
这些数字只是线索。至少运行几次，保持路由不变，并记录每次响应是否命中缓存。
推荐的排查顺序
- 确认服务器返回的 HTML 已经包含有意义的内容。
- 记录一次冷请求和至少三次热请求。
- 从响应头检查缓存身份、新鲜度和节点。
- 比较 HTML、最大样式表和脚本大小。
- 测试真实文章页，而不只是首页。
- 在窄屏和较慢网络下再测一次。 常见的有效改进并不复杂：
- 把已经验证过的公开内容缓存到读者附近。
- 为上游 API 设置明确超时。
- 不为完全静态的组件发送多余客户端代码。
- 为图片预留尺寸，避免布局跳动。
- 每次只改一件事，并记录前后结果。 MDN 对 PerformanceNavigationTiming 有完整说明。真正重要的习惯，是让每个数字都对应一个具体系统边界。
“100 毫秒”究竟代表什么？
它不是所有网站必须完成的指标，而是一个问题：为了让这个 URL 如此迅速、同时仍然返回正确且足够新鲜的内容，系统需要满足什么条件？