三秒钟。你只有这么多时间。
研究反复表明，如果一个页面加载超过 3 秒，超过一半的访客会离开。他们不会等。不会回来。他们直接点下一个搜索结果。
Google 知道这一点。所以页面速度从 2010 年起就是排名因素，Core Web Vitals 在 2021 年成为排名信号。
响应时间 vs 页面加载时间——有什么区别？
响应时间（TTFB） — Time To First Byte，首字节时间。服务器收到请求后开始发送数据需要多长时间。衡量的是服务器性能。
页面加载时间 — 完整页面变得可用需要多长时间。包括下载 HTML、CSS、JavaScript、图片，以及渲染所有内容。
两者都重要，但 TTFB 是基础。如果你的服务器花 2 秒才响应，你怎么优化其他东西都没法让页面感觉快。
什么导致响应时间慢
| 原因 | 典型影响 |
|---|---|
| 共享主机过载 | 流量高峰时 TTFB 飙升 |
| 数据库查询未优化 | 服务器等待慢查询完成 |
| 没有缓存层 | 每个请求都从头重建页面 |
| 服务器离用户太远 | 物理距离增加延迟 |
| 太多服务端重定向 | 每次重定向都增加一个完整往返 |
| 未优化的图片 | 巨大的文件传输很久 |
| 阻塞渲染的 JavaScript | 浏览器必须等脚本执行完才能显示内容 |
Core Web Vitals 的关联
Google 的 Core Web Vitals 包含三个指标：
- LCP（最大内容绘制） — 主要内容何时变得可见。慢 TTFB 直接影响 LCP。
- INP（交互到下一次绘制） — 页面响应用户操作的速度。重 JavaScript 影响这个。
- CLS（累积布局偏移） — 页面加载时跳动的程度。没有设置尺寸的图片会导致这个。
Core Web Vitals 不达标不会一夜之间摧毁你的排名，但它是决胜因素。两个相似的页面之间，更快的那个赢。
快速提升的方法
使用 CDN。 从离用户近的服务器提供内容，而不是从一个中心位置。
启用缓存。 不要为每个访客都重建页面。缓存静态和半静态内容。
优化图片。 使用现代格式（WebP、AVIF），压缩它们，为每个设备提供合适的尺寸，延迟加载首屏以下的图片。
减少阻塞渲染的资源。 内联关键 CSS，延迟非必要的 JavaScript。
全站测量响应时间
单个页面可能很快，但其他 500 个呢？需要一个爬虫来：
- 记录每个页面的响应时间
- 标记高 TTFB 的页面（超过 600ms）
- 识别模式——是整个部分都慢，还是只有特定页面？
- 跨多次审计跟踪响应时间以发现退化
Kaitico 测量每个爬取页面的响应时间，在审计报告中标记慢页面，帮你发现全站的性能瓶颈。