站点慢的性能排查：从 TTFB 到首屏的完整链路
作者：夸父
「网站慢」的系统性排查：TTFB（服务器响应）、资源加载、渲染阻塞、移动网络——按链路逐环测量与优化，附 Lighthouse 的正确用法。
排查链路：四段测量
打开浏览器 DevTools 的 Network 面板，按时间轴分四段测：
1. TTFB（Waiting/TTFB 时间）：第一字节到达的时间——静态导出站通常 <100ms（nginx 直出），若 >500ms 查服务器负载与 nginx 配置。2. 资源下载（Content Download）：CSS/JS/图片的传输时间——单文件过大（未压缩的 JS bundle、未优化的图片）在此暴露。3. 渲染阻塞：Lighthouse 或 Performance 面板看"first paint"前被什么阻塞（同步 script、未内联的关键 CSS）。4. 图片占比：Network 面板按 size 排序——图片通常占 60%+ 的传输量。
对应的优化动作
TTFB 优化：静态站上 CDN（见CDN 指南）——源站直出的 TTFB 受地理距离限制，CDN 边缘节点解决。资源优化：JS/CSS 已由构建压缩，图片转 WebP + 懒加载（next/image 已内置，自定义图片确认）；渲染优化：关键 CSS 内联、非关键 JS 延迟加载（next/script 的策略配置）。
静态站特有的"快"
静态导出站有天然的性能优势：HTML 直接命中（无服务端渲染等待）、CDN 友好（全站可缓存）、TTFB 稳定（无数据库查询）。如果你静态站的 TTFB 还慢，问题一定在部署环境（服务器负载/配置），不在应用——这是静态架构的红利，用满它。
移动端的单独测量
移动网络的加载是桌面 3~5 倍时间——用 DevTools 的 network throttling（Fast 3G/Slow 4G）模拟移动环境再测一遍，首屏控制在 3s 内（移动端适配的整体清单见移动适配指南）。
常见问题
先优化什么最划算？
按"对用户的感知权重"排：TTFB（第一字节来的快不快）→ 首屏关键资源（CSS/JS 是否阻塞）→ 图片体积（最大的一块）→ 其余。逐日 AI 静态站的 TTFB 天然优秀，重点是资源层。
Lighthouse 分数低就是慢吗？
分数是参考不是判决——真实用户的体验用"实际加载监控"看（统计工具的加载时长分布）。分数低但真实用户不慢的场景（如重交互页面）不必过度优化。