lcp 必须在首屏 js 执行前用 performanceobserver 实时监听，注册需置于 顶部 script 中且显式指定 entrytypes: ['largest-contentful-paint'] 并启用 buffered: true，否则易漏报；entry.starttime 是唯一可靠指标，移动端需兼容旧 webview 回退方案。
LCP 必须用 PerformanceObserver 实时监听，且注册时机越早越好——首屏 JS 执行前就该完成，否则大概率漏掉真实 LCP。
为什么不能等 DOMContentLoaded 后再注册
FCP 通常在 300–800ms 就触发，而 LCP 元素（比如大图、主标题）往往紧随其后；如果等到 DOMContentLoaded（常在 1s+）才初始化 PerformanceObserver，浏览器早已把 LCP 条目从缓冲区清掉了。即使加了 buffered: true，也只对注册前已存在的条目有效，前提是注册足够早。
常见错误现象：list.getEntries() 始终为空，或只在刷新后偶现一次 LCP 数据。
- 最佳实践：把注册代码放在
内最顶部的<script></script>中，不加defer或async - 不要依赖第三方加载器（如 require.js、webpack runtime）来启动监听
- 若用 React/Vue 等框架，需在
index.html的 script 标签里直接写，而非组件生命周期中
largest-contentful-paint 类型必须显式指定 entryTypes
PerformanceObserver 不会自动推断你要监听什么，漏写 entryTypes 或拼错类型名（比如写成 lcp 或 largest-contentful-paints）会导致完全无回调。
正确写法：
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log('LCP 时间:', entry.startTime.toFixed(2) + 'ms');
}
});
observer.observe({ entryTypes: ['largest-contentful-paint'], buffered: true });
注意点：
-
entryTypes是数组，即使只监听一种类型也要写成['largest-contentful-paint'] -
buffered: true必须带上，否则注册前已发生的 LCP 无法捕获 - 不要混用
observe({ type: '...' })—— 这是旧版 API，已废弃
如何拿到稳定、可上报的 LCP 值
entry.startTime 是唯一可靠的时间字段，单位毫秒，相对页面 timeOrigin；entry.duration 和 entry.size 与用户体验延迟无关，不能用于降级判断。
典型误用场景：
- 用
entry.size判断“是否够大”，结果在高 DPR 设备上数值翻倍，逻辑错乱 - 监听多次 LCP 回调后取最后一次——LCP 只会报告一次最终值，重复回调是异常（如 SPA 路由切换后新内容触发）
- 未过滤 iframe 场景：主页面和 iframe 都可能触发 LCP，需检查
entry.element?.ownerDocument === document
安全上报建议：
navigator.sendBeacon('/log', JSON.stringify({
metric: 'LCP',
value: entry.startTime,
url: entry.url || '',
element: entry.element?.tagName || ''
}));
移动端特别要注意的兼容性陷阱
部分 Android WebView（尤其旧版 UC、QQ 浏览器）不支持 largest-contentful-paint 类型，'largest-contentful-paint' in PerformanceObserver.supportedEntryTypes 返回 false。
不能简单跳过，得有 fallback：
- 检测失败时，退回到用
performance.getEntriesByType('paint')查entry.name === 'largest-contentful-paint'（但仅限已触发的，无法监听后续） - 更稳妥的做法：同时监听
paint和largest-contentful-paint，优先取后者，缺失时用 FCP + 启发式估算（如主图加载完成时间）补位 - 注意 iOS Safari 15.4+ 才完整支持
entry.element，低版本只能靠entry.url或日志推测
LCP 不是“渲染完就算”，而是浏览器认定的“最大内容元素首次出现在视口内”的时刻；这个判定本身受滚动、图片解码、字体加载影响，所以哪怕监听到位，数值波动仍不可避免——重点不是压到某个固定值，而是识别出哪类资源/操作反复拖慢它。
