不推荐直接在HTML中嵌入RUM脚本，因其易导致采集失效、指标失真或阻塞渲染；根本原因在于RUM依赖的API需页面导航完成且DOM初始化后才可用，同步加载会阻塞解析、缺乏错误隔离，且自定义performance.mark无法替代Web Vitals真实计算逻辑。
直接在 HTML 中嵌入 RUM 监控脚本是可行的，但「可行」不等于「推荐」——它容易导致采集失效、指标失真或阻塞页面渲染。
为什么不能只靠 <script> 标签硬塞 RUM 代码
很多团队把 RUM SDK 的 <script> 片段丢进 <head> 就以为万事大吉，结果发现：LCP 偏高、CLS 漏报、FID 为 0、甚至某些低版本 iOS 或旧安卓 WebView 根本没上报数据。
根本原因在于：
- RUM 依赖
PerformanceObserver和Navigation Timing API，而这些 API 在页面未完成导航（navigationStart未触发）或 DOM 尚未初始化时不可用 - 同步加载的
<script>会阻塞 HTML 解析，拖慢 FCP/LCP，尤其当 CDN 延迟高或脚本体积大时 - 没有错误隔离机制：SDK 自身报错（如
TypeError: Cannot read property 'observe' of undefined）会导致后续指标采集中断，且无法被上层错误监控捕获
performance.mark() 和 performance.measure() 不是 RUM 的替代方案
有人试图用自定义 performance.mark() 打点 + 定时上报模拟 RUM，这只能覆盖极小部分场景，且严重偏离 Web Vitals 定义：
立即学习“前端免费学习笔记（深入）”；
-
LCP是浏览器自动计算的最大内容元素渲染时间，无法靠mark模拟；手动标记 img/div 的load或DOMContentLoaded时间点，和真实 LCP 值偏差常超 300ms -
CLS需要监听 layout shift，并累积计算偏移分数，必须依赖LayoutShiftentry 类型，不是靠getBoundingClientRect()对比就能还原 -
FID已被INP取代，而 INP 要求捕获并聚合**所有**交互延迟（点击、键盘、滚动），需持续监听event.preventDefault()前的调度时机，普通打点完全无法支撑
真正能落地的 HTML RUM 集成方式
不是“怎么往 HTML 里加代码”，而是“如何让 RUM 在 HTML 生命周期中稳定生效”。关键动作如下：
- 使用
async加载 SDK，但必须配合defer级别初始化逻辑：把 SDK 的init()调用包裹在document.readyState === 'interactive'或DOMContentLoaded回调中，确保PerformanceObserver可注册 - 在
<head>最顶部注入最小化引导脚本（≤1KB），仅做两件事：检测是否已加载 SDK、若未加载则动态创建<script async src="...">并监听onload后触发初始化 - 对关键指标（如 LCP、CLS）启用
buffered: true选项，避免因 SDK 加载晚于指标触发而丢失首屏数据 - 必须设置采样率（如
sampleRate: 0.1），否则在高流量页面可能触发浏览器内存限制，导致PerformanceObserver停止投递 entry
最容易被忽略的兼容性断点
你以为用户用的是 Chrome 120，但真实环境里仍有大量设备卡在老旧内核：
- iOS 14.5 以下 Safari 不支持
PerformanceObserver的layout-shifttype，CLS 必须降级为 DOM 变更轮询（精度下降但至少有值） - Android UC 浏览器 13.x 会静默丢弃
longtaskentry，INP 计算需 fallback 到FirstMeaningfulPaint+ 交互事件耗时估算 - 所有 IE11 及更低版本、部分国产双核浏览器的极速模式，
navigationStart可能为 0，此时必须用Date.now()回退打点，否则 TTFB/LCP 全部归零
这些不是边缘 case——在东南亚、拉美、非洲市场，这类设备占比仍超 12%（2026 Q1 数据）。漏掉它们，RUM 报表里的 P95 就只是“高端机用户的 P95”。
