TTI的两种计算方式区别在于：①首次CPU空闲时间要求主线程连续空闲≥5秒且完成FCP和DOMContentLoaded，反映最早可用时间；②稳定交互时间在此基础上还要求空闲窗口内进行中GET请求≤2个，确保资源加载收敛、交互更可靠。

TTI（Time to Interactive）是衡量页面何时真正“能用”的关键指标——不是内容刚出现，而是用户点击、输入、滚动时，页面能稳定响应。它比 FCP 或 LCP 更贴近真实操作体验，尤其对单页应用（SPA）和交互密集型 H5 页面至关重要。

TTI 的两种计算方式区别在哪

WebPageTest 和 Lighthouse 等工具提供两个密切相关但语义不同的值：

• 首次 CPU 空闲时间（First CPU Idle）：主线程第一次连续空闲 ≥5 秒，且此时已完成首次内容绘制（FCP）和 DOMContentLoaded。它反映“最早可能可用”的时间点，适合评估首屏响应意愿。
• 稳定交互时间（Consistently Interactive）：在满足首次 CPU 空闲基础上，额外要求该空闲窗口内“进行中的 GET 请求 ≤2 个”。这意味着资源加载已基本收敛，后续交互不易被网络请求阻塞，更贴近生产环境下的可靠可用性。

TTI 值高通常意味着什么

TTI 延迟不是单一原因导致的，而是主线程长期被占用的综合体现。常见根源包括：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 大量同步 JavaScript 执行（如未拆分的 bundle、阻塞渲染的初始化逻辑）
• 未优化的第三方脚本（分析 SDK、广告、埋点等在 onload 后集中执行）
• CSSOM 构建耗时过长（尤其是内联大段 CSS 或未提取关键 CSS）
• 首屏后仍触发长任务（如复杂图表渲染、未节流的数据处理、未延迟的非关键动画初始化）

如何在 HTML5 项目中有效监控 TTI

不能只依赖实验室工具（如 WebPageTest），需结合真实用户场景：

立即学习“前端免费学习笔记（深入）”；

• 使用 PerformanceObserver 监听 longtask 事件，定位耗时 >50ms 的 JS 任务，这是 TTI 推迟的直接信号
• 通过 Navigation Timing API 结合自定义打点（如记录 FCP、DOMContentLoaded、首个空闲窗口起始时间），估算首屏 TTI 下界
• 在 Vue/React 应用中，可在挂载完成、路由就绪、数据加载完毕后主动触发 performance.mark('tti_reached')，用于对比分析
• 接入 RUM（Real User Monitoring）平台时，将 TTI 与 FID 关联分析：若 TTI 低但 FID 高，说明交互逻辑本身有延迟；若两者均高，则主线程负载是共性瓶颈

优化 TTI 的实用切入点

不追求一步到位，优先解决影响面最大的环节：

• 把非关键 JS 改为 async 或 defer，避免阻塞解析和执行
• 对首屏外组件/逻辑做动态 import（代码分割），减少初始 JS 包体积
• 用 requestIdleCallback 延迟执行低优先级任务（如预加载非首屏图片、上报非紧急日志）
• 检查并精简第三方 SDK，禁用其自动初始化，改为按需加载或懒执行