performance.mark 本身不能直接测量 tti，因为 tti 是需结合长任务检测、主线程空闲观察和交互验证的合成指标，而非静态打点可覆盖；chrome performance api 也不提供原生 tti 类型接口。
performance.mark 本身不能直接测量 TTI（Time to Interactive），它只是打点工具；TTI 是一个合成指标，需结合长任务、主线程空闲、可交互状态等条件推断。Chrome 的 Performance API 不提供 performance.getEntriesByType('tti') 这样的原生接口。
为什么不能只靠 performance.mark 算 TTI
TTI 的定义是：页面完成首次渲染后，主线程连续 5 秒内无长任务（>50ms），且能响应用户输入（如 click、keydown）的最早时间点。它依赖运行时观察，不是静态打点能覆盖的。
-
performance.mark('app-loaded')只代表 JS 执行完，不等于主线程已空闲 - 组件挂载完成（如 React 的
useEffect(() => {}, [])）也不代表事件监听器已绑定或 DOM 已可响应 - 第三方脚本、懒加载资源、异步初始化逻辑可能在标记之后才触发长任务
如何用 performance.mark 配合真实 TTI 推算逻辑
你可以把 performance.mark 当作「锚点」，配合主动探测 + 主线程监控，构建可上报的近似 TTI。关键不是打点本身，而是打点位置是否对齐可交互前提：
- 在所有业务组件完成挂载、关键事件监听器绑定完毕后，立即调用
performance.mark('tti-candidate') - 启动一个
setTimeout或requestIdleCallback循环，每 100ms 检查一次：performance.now()与上一次检查间隔是否 >50ms（即有长任务打断）；若连续 50 次未被打断（≈5 秒），则认为达到 TTI - 此时调用
performance.mark('tti-confirmed')，再执行performance.measure('tti', 'navigationStart', 'tti-confirmed') - 务必在
tti-confirmed后立刻验证一次交互能力，比如模拟dispatchEvent(new MouseEvent('click'))并监听是否触发 handler
上报大盘时容易漏掉的三个硬伤
很多团队把「首屏渲染完成时间」或「React root render 结束时间」当成 TTI 上报，导致大盘失真。真正影响体验的是用户第一次能点击/输入的时间，这三点常被忽略：
- 第三方 SDK（如 Sentry、AppInsight）的初始化通常在
DOMContentLoaded后异步注入，它们的脚本解析+执行会制造长任务，但不在你自己的代码控制范围内 - 字体加载（
font-display: swap）虽不影响渲染，但 FOUT 后的重排可能触发隐式长任务，且不触发performance.getEntriesByType('layout') - 移动端 WebView 中，
requestIdleCallback兼容性差，需 fallback 到setTimeout+performance.now()差值检测，但要注意 iOS Safari 的计时精度降级问题
TTI 大盘的价值不在数字本身，而在识别「哪些组件/SDK/路由让主线程卡住超过 5 秒」。与其追求绝对精确的 TTI，不如固定打点位置（如 'tti-phase-1-init'、'tti-phase-2-listeners'、'tti-phase-3-idle-check-start'），用 performance.measure 切分阶段耗时，再结合 Chrome DevTools 的「Main thread activity」火焰图交叉验证。
