PageSpeed Insights报告中真正该盯住的是LCP、CLS、TBT三项核心指标：LCP＞2500ms影响“页面多久能看”，CLS＞0.1导致“页面突然跳动”，TBT＞300ms引发“交互卡顿”，它们比总分更能决定用户是否划走。
直接在 https://pagespeed.web.dev/ 输入网址就能分析，但光点“分析”不等于拿到有效结论——多数人卡在看不懂报告、改了没效果、或误优化拖慢首屏。
PageSpeed Insights 报告里哪些项真该盯住
别被总分带偏。真正决定用户是否划走的是「实验室数据」里的三个指标：LCP（最大内容绘制）、CLS（累积布局偏移）、TBT（总阻塞时间）。它们对应着“页面多久能看”“会不会突然跳动”“交互是否卡顿”。移动端报告比桌面端更关键，因为 PSI 默认用移动设备模拟器跑测试，且真实用户中移动端占比更高。
-
LCP > 2500ms：大概率是首屏图片没压缩、没懒加载，或关键 CSS/JS 阻塞了渲染 -
CLS > 0.1：常见于图片/广告/iframe 没设宽高、字体闪跳、动态插入 DOM 未预留空间 -
TBT > 300ms：说明 JS 执行太久，尤其是第三方脚本（统计、客服、广告）没做延迟加载
为什么改了 HTML 还是扣分：render-blocking 资源的识别逻辑
PSI 不是静态扫描 HTML 文件，而是模拟浏览器加载过程。它把所有出现在 <head> 里、没加 defer 或 async 的 <script>，以及所有 <link rel="stylesheet"> 默认标为 render-blocking——哪怕你本地测着很快，只要它阻塞了 HTML 解析，就会扣分。
- 内联脚本（
<script>...</script>）即使只有一行，也会阻塞，必须加defer或移到<body>底部 - CSS 文件哪怕只有 1KB，只要外链且没做异步加载，就计入阻塞资源；内联 CSS 超过 ~14KB 反而触发 Chrome 延迟解析，得不偿失
- 注意 polyfill.io、Google Fonts 等服务可能动态注入未标记的
<script>，Network 面板看Initiator列才能揪出来
优化后怎么验证不是假快
本地刷新看 F12 的 Network 面板，重点核对三件事：
立即学习“前端免费学习笔记（深入）”；
- 首屏 HTML 是否在 1 秒内完成
DOMContentLoaded？如果不是，检查 TTFB（Time to First Byte），这由服务端决定，和 HTML 本身无关 - 首屏必需的 CSS 是否已内联？其余 CSS 是否通过
rel="preload"+onload注入，且<link>标签已移除？ - 所有非首屏 JS（含第三方）是否用了
import()动态导入，或封装成loadScript在requestIdleCallback里加载？
PSI 的“实验室数据”每次都是干净环境重跑，但真实用户有缓存。如果优化后 LCP 变差，大概率是内联 CSS 太大导致 HTML 体积激增，或 CDN 缓存策略没配好，让旧资源反复回源。
