Lighthouse性能评分优化后反而下降了，哪里出问题？

萌新.嘉倪提问于 2026-02-09 22:18:28 阅读 49

工具

我给网站压缩了图片，移除了没用的JS代码，按理说性能应该更好，但Lighthouse评分从85直接掉到72，这是为啥？

之前优化时做了这些：img标签加了loading="lazy"，把多个CSS文件合并成一个，还用了WebP格式。测试环境用了Chrome开发者工具的模拟4G网络模式。

现在的Lighthouse报告说”消除渲染阻塞资源”得分降低，但首屏JS已经用async加载了：

<script src="app.js" async></script>

这个配置有问题吗？

另外发现 Largest Contentful Paint 时间反而多了300ms，明明图片尺寸减少了200KB…

性能测试

我来解答赞 2 收藏

反馈

2 条解答

Prog.若曦 Lv1

你合并CSS文件后可能把非首屏的样式也打包进去了，导致关键渲染路径变长。直接这样：拆出首屏用到的最小CSS，用 <style> 内联到HTML里。还有，LCP变慢大概率是图片懒加载搞的鬼，loading="lazy" 对首屏图片反而有害，移除它试试。



<head>

  <style>

    /* 只保留首屏样式 */

    .hero { background: #eee; }

    .title { font-size: 24px; }

  </style>

</head>

<body>

  <img src="hero.webp" />

</body>

对了，模拟4G网络测性能不靠谱，建议用真实设备或者至少调成Fast 3G再跑一遍。

2026-02-16 12:10

Good“梦轩 Lv1

你这问题很典型，优化反而降分，大概率是服务端和加载策略出了组合拳问题。

先说关键点：Lighthouse模拟的是真实用户感知性能，不是单纯看资源大小。你压缩图片、合并CSS这些操作理论上是对的，但实际跑分下降，说明可能触发了更严重的瓶颈。

第一个坑在 async。你写了 <script src="app.js" async></script> 没错，但如果这个 app.js 体积变大了（比如你把多个逻辑塞进一个文件），即使异步加载，它还是会抢占网络资源，延迟CSS和其他关键资源下载。更糟的是，如果它执行时修改了DOM或样式，照样会阻塞渲染。建议拆成真正核心的用 async，非核心用 defer 或动态加载。

第二个问题是 WebP + lazy loading 的组合陷阱。虽然WebP小，但如果你没配好服务端的格式协商（Accept头判断），浏览器请求WebP失败就会 fallback 到原图，反而多一次重试。加上 loading="lazy" 后，首屏图片如果被错误标记为“非关键”，LCP 图片可能就换了——原本是主图现在变成某个延迟加载的元素，时间自然拉长。

还有合并CSS这事，别一股脑全塞一个文件。你现在可能把首屏不需要的样式也打包进去了，就算CSS不阻塞JS，它依然要解析整个文件。你应该把首屏关键CSS内联，其余的用 media 分条件加载或者 preload。

最后查一下服务端是不是开了 Gzip/Brotli。你减了200KB图片，但如果传输没压缩，反而其他资源没开压缩，网络层浪费更大。

快速验证步骤：
1. 打开 Network 面板，看 Waterfall 里 CSS 和 JS 是否重叠严重
2. 检查 app.js 实际开始执行的时间和持续时长
3. 看 LCP 元素到底是谁，在 Performance 面板里找对应的 paint 记录
4. 用 curl 测试服务端是否正确返回 WebP（带 Accept: image/webp 请求头）

先把这几个点过一遍，大概率能找到罪魁祸首。

2026-02-09 22:23