如何用document.readyState优化脚本加载时机以提升白屏加载体验-js教程-PHP中文网

document.readystate 有 loading、interactive、complete 三种值：loading 表示 html 正在解析；interactive 表示 dom 构建完成、body 可访问但外部资源仍在加载；complete 表示所有资源加载完毕。

如何用document.readystate优化脚本加载时机以提升白屏加载体验

document.readyState 有哪些可能值，分别代表什么阶段

document.readyState 是浏览器同步暴露的文档加载状态标识，共三种取值：loading、interactive、complete。它们不是时间戳，而是 DOM 构建过程中的关键里程碑：

loading：HTML 文档正在解析中，<script></script> 同步执行时常见于此阶段；此时 document.body 可能还不存在
interactive：DOM 构建完成（即 DOMContentLoaded 已触发），但外部资源（如图片、样式表、异步脚本）仍在加载；document.body 和大部分节点已可安全访问
complete：所有资源（包括图片、iframe 等）全部加载完毕；等价于 window.onload 触发时机，通常较晚

白屏优化的关键，是尽早获取可操作的 DOM 节点并启动渲染逻辑，而不是等整个页面“彻底加载完”——所以 interactive 是最值得盯住的状态。

为什么不能只靠 `DOMContentLoaded` 或 `window.onload`

这两个事件看似覆盖了加载流程，但存在实际偏差：

DOMContentLoaded 不保证 document.body 已挂载（尤其在内联脚本位于且 DOM 尚未解析到时，document.body 为 null）
window.onload 会等待所有资源（含第三方 tracker 图片、字体文件等），极易被阻塞，白屏时间不可控
某些构建工具（如 Vite）或 SSR 框架（如 Nuxt）会在首屏注入 hydration 脚本，若依赖 document.body 却没做存在性检查，直接报 Cannot read property 'appendChild' of null

而 document.readyState === 'interactive' 是一个更早、更稳定、且与 DOM 可用性强相关的信号——它意味着 HTML 解析结束、document.body 必然存在，且 JS 执行不会打断渲染主线程。

如何安全地在 `interactive` 阶段执行初始化逻辑

不能简单轮询或只判断一次，需结合状态监听与降级兜底：

立即检查当前状态：若已是 interactive 或 complete，直接执行初始化函数
否则监听 readystatechange 事件，只响应一次 interactive 状态到达（避免重复触发）
加 5s 超时兜底：防止极端情况（如解析卡死、事件未触发），超时后强制执行（至少保障功能可用）
务必包裹 if (document.body) 判断，即使状态是 interactive，极少数 iframe 场景或特殊 polyfill 下仍可能短暂为空

示例精简写法：

function runWhenInteractive() {
  if (document.readyState === 'interactive' || document.readyState === 'complete') {
    initApp();
    return;
  }
  let triggered = false;
  const handler = () => {
    if (triggered) return;
    if (document.readyState === 'interactive') {
      triggered = true;
      initApp();
      document.removeEventListener('readystatechange', handler);
    }
  };
  document.addEventListener('readystatechange', handler);
  setTimeout(() => {
    if (!triggered && document.body) {
      triggered = true;
      initApp();
    }
  }, 5000);
}

和 `defer`、`async` 脚本的配合要点

defer 脚本本身就在 DOM 解析完成后执行，天然接近 interactive 阶段，但仍有细节差异：

defer 脚本的执行时机 ≈ DOMContentLoaded，不等于 interactive —— 因为多个 defer 脚本按顺序执行，若前一个耗时长，后一个仍会延迟
把核心初始化逻辑放在 defer 脚本里，再用 document.readyState 判断，比纯靠 defer 更可控
async 脚本完全不可预测，可能在 loading 阶段就执行，此时 document.body 极大概率不存在，必须避免在此类脚本中直接操作 DOM
服务端渲染（SSR）场景下，hydration 脚本建议设为 defer，并在内部用 document.readyState 做双保险，防止客户端首次 render 时因 DOM 未就绪而失败