Google Chrome Lighthouse性能得分为0，首次有效绘制耗时43秒求助

哇，43秒的First Meaningful Paint和0分的性能评分确实让人崩溃——尤其是你已经把压缩、懒加载、消除阻塞这些常规操作都做完了之后。别着急，咱们来梳理几个容易被忽略的排查方向：

• 先查服务器端的响应速度
  打开Chrome DevTools的Network面板，看初始HTML文档的Time to First Byte (TTFB)。如果这个值就超过了几秒甚至几十秒，那前端优化根本起不到作用。这时候要排查：服务器是不是配置有问题？数据库查询是不是太耗时？后端有没有同步阻塞的逻辑（比如某个接口在等第三方服务响应）？

• 揪出隐藏的渲染阻塞资源
  常规优化可能漏掉了一些“隐形”的阻塞项：

  • 字体文件：检查@font-face有没有设置font-display: swap，如果没有，浏览器会等字体加载完才渲染文本，严重拖慢FMP。
  • 隐藏的第三方脚本：比如某些嵌入的广告、统计工具，或者是你以为已经移除但还在加载的社交脚本，用Network面板筛选Script类型，看看有没有加载慢的资源。
  • 同步加载的非关键JS：哪怕是你自己的代码，如果首屏不需要用到，却用同步方式加载，也会阻塞渲染。

• 检查首屏内容的依赖逻辑
  是不是首屏渲染必须等待某个超大的数据请求完成？比如页面初始化时就拉取了几百KB甚至几MB的JSON，然后才能渲染内容。这种情况可以考虑：

  • 服务端渲染（SSR）：把首屏需要的数据直接渲染到HTML里，不用等前端异步请求。
  • 骨架屏：先渲染占位的骨架结构，等数据回来再替换，至少让用户看到页面在加载。

• 排查Lighthouse测试环境的干扰
  有时候问题出在测试本身：

  • 试试在Chrome隐身模式下跑Lighthouse，避免浏览器插件（比如广告拦截器、VPN）干扰加载。
  • 检查Lighthouse的网络模拟设置，是不是不小心选了Slow 3G但实际你的测试环境网络不稳定？改成No throttling先测本地性能。

• 用Performance面板抓主线程阻塞
  打开DevTools的Performance面板，点击录制，完整记录页面加载过程。看有没有红色的Long Tasks（执行时间超过50ms的任务），这些任务会完全阻塞主线程，导致渲染停滞。比如某个初始化函数在循环处理超大数组，或者频繁操作DOM导致重排重绘。

• 检查资源加载顺序的优先级
  确认首屏需要的CSS是不是放在<head>里，并且没有用@import（会阻塞加载）。关键JS有没有用async或defer，确保不会阻塞HTML解析。另外，看看有没有大图片被放在首屏，哪怕懒加载了，是不是初始加载时还是请求了？

如果这些方向都排查了还是找不到问题，可以把DevTools的Network和Performance面板的截图贴出来，这样更容易定位根源。

内容的提问来源于stack exchange，提问作者Adam