lcp、fid、cls是chrome真实采集的硬性体验门槛，未达标（lcp>2.5s/fid>100ms/cls>0.1）即标记“体验不佳”，影响seo与留存；lcp卡顿主因首屏图片未preload、格式陈旧、误用lazy、ttfb过高；fid高源于主线程被长任务阻塞；cls超标多因img/video缺失width/height导致布局跳动。
LCP、FID、CLS 不是“建议优化项”，而是 Chrome 实际采集、真实影响 SEO 和用户留存的硬性门槛——LCP > 2.5s / FID > 100ms / CLS > 0.1 的页面，会被标记为“体验不佳”。
为什么 LCP 总卡在 3s 以上？关键资源没抢到渲染队列
LCP 不是你写的 <img> 或 <h1></h1> 哪个先写就选哪个，而是浏览器在视口中动态识别出“最大内容元素”（比如 board_wide.webp 这类海报图）并记录它完成渲染的时间。常见卡点不是代码没写，而是资源被挤在后面：
- 首屏图片用
src普通加载，没加<link rel="preload" as="image" href="assets/screenshots/board_wide.webp">，浏览器不知道它该优先下载 - 图片仍是
.jpg格式，体积比.webp大 40%–60%，解码也更慢 -
loading="lazy"错误地加在首屏图片上，浏览器直接跳过预加载逻辑 - TTFB > 500ms（比如后端未启用 HTTP/2、CDN 缓存未命中），首字节延迟直接抬高 LCP 底线
FID 高 ≠ JS 写得烂，主线程正被长任务锁死
FID 测的是用户第一次点击/输入，到浏览器真正开始处理之间的时间差。它不关心你逻辑多优雅，只看主线程有没有空档。Stremio-web 中常见陷阱是把“一次性重活”塞进初始化阶段：
-
use-notifications.ts在挂载时同步遍历几百条通知做去重+排序，阻塞主线程超 200ms - 第三方脚本（如分析 SDK）没加
async或defer，插入即执行，打断 HTML 解析 - 键盘快捷键监听器（如
onShortcut.ts）在每个组件里重复addEventListener，事件分发链变长 - 本地日志聚合、通知匹配等计算仍在主线程跑，没交给
Web Worker
CLS > 0.1？90% 是因为 <img> 没写 width 和 height
CLS 不是动画卡顿，是布局“跳位”。浏览器渲染时发现 <img> 没设尺寸，先按 0×0 占位；等图片加载完，突然撑开高度，下方所有元素往下蹿——用户正要点“播放”，按钮滑走了。
- 仅靠 CSS 设置
max-width: 100%不行，必须有内联width和height属性（哪怕只是占位值） -
<video></video>同样要带width/height，否则播放器控件加载后也会触发偏移 - 广告或推荐模块异步插入 DOM 时，没预留容器高度，插入瞬间拉低已有内容
- 字体加载替换（
@font-face）导致文本重排，需用font-display: optional或提前声明 fallback 尺寸
真正难的不是知道该加 preload 或写 width，而是在 SSR 渲染、图片尺寸协商、动态模块注入这些环节里，保持尺寸信息不丢失、资源加载顺序不紊乱——这些地方一松动，LCP/FID/CLS 就会集体反弹。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
