Lighthouse 37 分到 95 分，做完这五个动作就够了｜出海Day29

袁锐钦

发布于 2026-06-03 13:07:46

优化不是追 100 分，是按 ROI 做动作——做完前五个就够了。

我第一次跑 Lighthouse 的时候，看到那个红彤彤的 37 分，心态是崩的。

「怎么这么低？」「是不是哪里搞错了？」「我得把所有红的地方全修掉。」

后来我发现——绝大部分人开 Lighthouse 的第一反应都是这样。然后就开始对着那几十条建议一条条修，修到 90 分才敢停。

但这件事最讽刺的地方是：你把 Lighthouse 修到 100 分，用户打开你网站可能反而更慢了。

不是开玩笑。举一个最常见的坑——首屏有张 800KB 的 PNG，Lighthouse 建议你用 WebP。你换了，分涨了 5 分。但你没想到把加载方式从 blocking 改成 lazy ——这张图对用户来说还是在那，加载时间一点没少。

Lighthouse 是体检报告，不是手术方案。 今天我把十个标准动作拆开，按投入产出比排序。做完前五个，你的网站就已经比 80% 的工具站快了。

先搞清楚三个指标

Lighthouse 性能分数主要由 Core Web Vitals 决定。2026 年的标准：

指标	含义	好的标准	差的红线
LCP	最大内容渲染时间	≤2.5 秒	>4.0 秒
INP	交互响应延迟	≤200 毫秒	>500 毫秒
CLS	累计布局偏移	≤0.1	>0.25

简单翻译：

• LCP 慢 = 用户盯着白屏等
• INP 高 = 用户点了按钮但没反应
• CLS 高 = 用户正要点的东西突然跳走了

2026 年 3 月 Google 核心更新后，这三个指标的权重更大了。CrUX 数据显示 2026 年只有 51% 的移动端站点全绿——也就是说，你只要全绿，就比一半的网站强了。

十个标准动作，按 ROI 排

以下动作是我在自己工具站上实测过的。投入时间是我花在实际改代码+部署上的时间。

🔥 ROI 第一梯队：做一件就涨 10-20 分

动作 1：图片转 WebP + 指定尺寸（投入 30 分钟）

这是性价比最高的动作。一张未经压缩的截图 PNG 可能 2MB，转成 WebP 后只剩 120KB——体积缩小 94%。

怎么做：

• 用 cwebp 命令行或在线工具把 PNG/JPG 转成 WebP，质量设 80 就够了
• 同时生成 AVIF 作为备选（体积更小，但 Safari 老版本不支持）
• <img> 标签写上 width 和 height——不写的话 CLS 直接炸





<img src="hero.webp" width="1200" height="630" alt="封面图" loading="lazy">

一个常被忽略的点：首屏的 LCP 图片不能用 loading="lazy"。LCP 图片是用户第一眼看到的最大那张，你让它懒加载等于让用户多看半秒白屏。给它加 fetchpriority="high"：





<img src="hero.webp" width="1200" height="630" alt="封面" fetchpriority="high">

做完这个动作，LCP 通常能从 8 秒降到 2 秒以内。

动作 2：开启 Gzip/Brotli 压缩（投入 10 分钟）

这不是代码层面的，是你服务器/部署平台的配置。

• Vercel / Cloudflare Pages：默认已开，不需要你做任何事
• Nginx：加一行 gzip on;
• Node 服务器：用 compression 中间件

验证：打开 Chrome DevTools → Network → 看 Response Headers 里有没有 content-encoding: br（Brotli）或 content-encoding: gzip。

一个 200KB 的 JS 文件压缩后只剩 40KB。这是零代码改动、最大收益的动作。

🔥 ROI 第二梯队：做两件稳 80 分以上

动作 3：移除未使用的 CSS/JS（投入 1 小时）

你装了 20 个 npm 包，每个都带了自己的一套样式。用户打开你的页面时，浏览器下载了一堆它根本用不到的 CSS。

怎么做：

• Chrome DevTools → Coverage 面板 → 点录制 → 刷新页面 → 看红条（未使用的代码）
• 红色超过 60% → 需要处理
• 用 PurgeCSS（Tailwind 自带）或 @fullhuman/postcss-purgecss 自动删除未使用的 CSS
• JS 用动态 import 做代码分割：





// 不好的写法——整个库打包进首屏
import HeavyChart from 'heavy-chart-library';

// 好的写法——用户需要时才加载
const HeavyChart = React.lazy(() => import('heavy-chart-library'));

Lighthouse 的「Remove unused JavaScript」和「Remove unused CSS」两项，修完至少涨 15 分。

动作 4：字体优化（投入 20 分钟）

Google Fonts 是 LCP 杀手。浏览器加载页面→遇到字体链接→去 Google 服务器下载字体→下载完才能渲染文字。这个过程可能吃掉 1.5 秒。

三种方案，从简单到彻底：

方案 A（最快）： 用 font-display: swap，让浏览器先用系统字体渲染，字体下载完后再切换。用户不会看到白屏，只是字体闪一下。





@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
}

方案 B（更好）： 把字体文件下载到本地，放在自己的服务器上。少一次外部 DNS 查询，少一次 HTTPS 握手。

方案 C（最彻底）： 用系统字体栈。现代系统字体渲染质量已经很好，而且零下载开销。





body {
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
}

动作 5：给图片和视频预留空间（投入 15 分钟）

你的页面加载时，图片还没出来，文字先渲染了。然后图片突然插入，文字被挤到下面——这就是 CLS。

最简单的修法：给所有图片容器设 aspect-ratio，浏览器在图片加载前就知道要留多大空间。





img {
  aspect-ratio: attr(width) / attr(height);
  max-width: 100%;
  height: auto;
}

广告位、嵌入的 iframe 同理——预留占位空间，别让它们把页面布局炸了。

🔧 ROI 第三梯队：做不做看情况

动作 6：关键 CSS 内联（投入 30 分钟）

把首屏渲染必须的 CSS 直接写在 <head> 的 <style> 标签里，而不是等外部 CSS 文件下载完。要做的话用 critical 或 penthouse 工具自动提取。

动作 7：DNS 预解析 + 预连接（投入 10 分钟）

如果你的页面加载了外部域名的资源（CDN、分析脚本、字体），告诉浏览器提前建立连接：





<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">

动作 8：使用 CDN（投入 30 分钟）

静态资源放 CDN，用户从离他最近的节点加载。Cloudflare 免费版就够用。

动作 9：启用缓存（投入 10 分钟）

设置 Cache-Control 头，让浏览器知道哪些资源可以缓存多久。不常变的资源（logo、CSS、JS）设 max-age=31536000，常变的设 no-cache。

动作 10：减少第三方脚本（投入：看你用了多少）

Google Analytics、Hotjar、Facebook Pixel……每一个第三方脚本都是一次外部网络请求。问自己：这个我真需要吗？砍一个脚本，LCP 可能少 300 毫秒。

做完前五个就够了

回顾一下投入产出：

动作	投入	预计提分
图片转 WebP + 尺寸	30 分钟	10-20 分
Gzip 压缩	10 分钟	5-10 分
移除未使用 CSS/JS	1 小时	10-15 分
字体优化	20 分钟	5-10 分
图片占位	15 分钟	5-10 分