理解 Lighthouse 评分体系
Lighthouse 是 Google 开发的开源自动化审计工具，用来检查网页的性能、可访问性、SEO 与最佳实践。开发者最关心的性能评分（Performance Score），直接影响用户体验和搜索排名。自 2024 年 Lighthouse v12 发布以来，评分算法更加注重视觉体验和交互响应，对 Core Web Vitals 的权重进一步提升——换句话说，光把页面"加载完"已经不够，还要"加载得稳、响应得快"。
一个低于 50 分的网站，通常意味着首屏很慢、交互卡顿、页面乱跳，相当比例的用户会在前几秒就离开；优化到 90 分以上的站点，不仅在满意度上占优，在搜索结果里也往往能获得更好的表现。这篇文章给出从 50 分到 95 分的完整路径，并附带可落地的检查与验证方法。
一、Lighthouse 评分指标详解
1.1 六大核心指标
| 指标 | 缩写 | 权重 | 优秀阈值 |
|---|---|---|---|
| Largest Contentful Paint | LCP | 25% | < 2.5s |
| First Input Delay / Total Blocking Time | FID / TBT | 25% | < 50ms / < 200ms |
| Cumulative Layout Shift | CLS | 15% | < 0.1 |
| Speed Index | SI | 10% | < 3.4s |
| Time to Interactive | TTI | 10% | < 3.8s |
| First Contentful Paint | FCP | 15% | < 1.8s |
1.2 常见低分原因分析
| 问题 | 影响指标 | 常见场景 |
|---|---|---|
| 图片未优化 | LCP, SI | 未压缩的大图 |
| 渲染阻塞资源 | FCP, TTI | 未优化的 CSS/JS |
| 未使用 CDN | LCP, SI | 服务器响应慢 |
| 布局偏移 | CLS | 未指定图片尺寸，动态注入内容 |
| 长任务 | TBT, TTI | 主线程计算量大 |
1.3 怎么读分数
需要提醒一点：性能评分是一个 0-100 的加权综合值，它不是某个具体测出来的时间，而是把六大指标按权重折算后的结果。这意味着两个同样 80 分的网站，薄弱环节可能完全不同——一个卡在 LCP，一个卡在 CLS。看报告时先看每项指标的颜色（红/黄/绿），再针对性优化，比只看总分有效得多。Lighthouse 还会在报告中给出 Opportunities 和 Diagnostics 列表，直接告诉你该动哪里，照着做通常比凭经验猜测更高效。
二、分阶段优化方案
2.1 基础优化（50 分 → 70 分）
图片优化：
- 使用 WebP 或 AVIF 格式替代 JPEG/PNG，一张 1920px 的 Banner 从 JPEG 换成 WebP 通常能省 60%-80% 体积；
- 设置正确的图片尺寸，不要用 2000px 的图去展示 300px 的缩略图；
- 开启图片懒加载，首屏以下的图按需加载。
资源优化：
- 压缩 CSS 和 JavaScript 文件；
- 移除未使用的 CSS（使用 PurgeCSS）；
- 启用文本压缩（Gzip / Brotli），Brotli 对文本通常还能再省 15%-20%。
// 示例：使用 WebP 格式
const picture = document.createElement('picture');
picture.innerHTML = `
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="优化后的图片">
`;
2.2 进阶优化（70 分 → 90 分）
关键渲染路径优化：
- 内联关键 CSS（Critical CSS），把首屏样式直接放进 HTML；
- 异步加载非关键 JavaScript（
defer/async），避免脚本阻塞渲染； - 使用
<link rel="preload">预加载首屏关键资源。
网络优化：
- 部署 CDN 加速静态资源分发，把响应节点拉近到用户；
- 启用 HTTP/2 或 HTTP/3；
- 配置合理的缓存策略（Cache-Control），静态资源带上长缓存与内容哈希。
| 方案 | 复杂度 | 性能 | 可维护性 | 适用场景 |
|---|---|---|---|---|
| 图片格式转换 | 低 | 中 | 高 | 小型项目 |
| Critical CSS | 中 | 高 | 中 | 中型项目 |
| 服务端渲染优化 | 高 | 极高 | 低 | 大型项目 |
2.3 极致优化（90 分 → 95+ 分）
- 使用 CDN 边缘计算（如 Cloudflare Workers）把个性化逻辑搬到离用户最近的位置；
- 实现预测性预加载（Speculative Rules API），在悬停或点击前预取目标页面；
- 采用微前端架构拆分应用，按需加载业务模块；
- 使用流式 SSR 减少 TTFB，让首字节更早到达。
三、一个真实的优化案例
假设一个内容站的移动端评分卡在 52 分。按上面的路径走一遍，效果大致是这样的：
- 第一步，把所有 JPG 换成 WebP/AVIF 并补齐尺寸属性，LCP 从 6.1s 降到 3.8s，评分到 68；
- 第二步，内联首屏 CSS、给非关键脚本加
defer，FCP 降到 1.9s，评分到 79； - 第三步，接入 CDN 并把 TTFB 从 900ms 压到 350ms，加上缓存策略，评分到 88；
- 第四步，用 Performance Observer 在真实环境采集数据，针对性地优化长任务，最终稳定在 94 分左右。
每一步都建议先测量、再动手、再复测，而不是凭感觉同时改十处。
四、用代码持续监测
Lighthouse 是"实验室"数据，真实用户还会受到网络和机型影响，两者要结合着看。下面这段代码可以在浏览器里持续采集 Core Web Vitals：
// 使用 Performance Observer 监控 Core Web Vitals
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'largest-contentful-paint') {
console.log('LCP:', entry.startTime);
}
if (entry.entryType === 'layout-shift') {
console.log('CLS:', entry.value);
}
}
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });
observer.observe({ type: 'layout-shift', buffered: true });
更系统的真实用户监控（RUM）方案见前端 RUM 与 Core Web Vitals 监控；与指标直接相关的优化细节见Core Web Vitals 优化指南。
五、注意事项
- 移动端优先：Lighthouse 移动端评分通常更低，应优先优化移动端；
- 持续监控：性能优化不是一次性工作，需要在 CI/CD 中集成，每次部署跑一次 Lighthouse CI，低于阈值就拦截；
- 实际用户数据：结合 RUM（Real User Monitoring）数据验证优化效果，避免只盯着实验室分数；
- 避免过度优化：在性能和功能之间取得平衡，不要为了 1 分牺牲掉可维护性。
六、总结
从 50 分到 95 分的优化之路需要系统性的分析和持续的努力。建议从最容易实施的图片优化和资源压缩开始，逐步深入到关键渲染路径优化、网络层优化和应用架构优化。用 Lighthouse CI 在每次部署时自动审计，再配合 RUM 持续校准，确保性能不会退化——这也是网站性能优化真正的常态。
参考：Lighthouse 官方文档 https://developer.chrome.com/docs/lighthouse/overview
参考：web.dev Core Web Vitals 指南 https://web.dev/articles/vitals