load事件仅在页面所有资源加载完成时触发一次,适合进度条收尾但无法实现动态百分比;document.readystate仅有三个静态状态,不能反映真实加载进度;推荐用performanceobserver监听resource事件估算进度,或服务端配合content-length+流式响应实现主文档进度监控。

如何用 window.addEventListener('load') 监控页面完全加载
页面完全加载完成(包括图片、CSS、JS、iframe 等所有资源)后才触发,适合做「进度条收尾」。但注意:load 事件不提供中间进度,无法实现动态百分比——它只在 100% 时 firing 一次。
常见误用:有人试图在 load 里反复读取 document.readyState 或轮询资源状态,这无效,因为该事件本身无进度参数。
- 仅适用于「加载完成后的收尾动作」,比如隐藏进度条、启用按钮
- 若页面含大量第三方 iframe 或异步图片,
load可能延迟数秒甚至失败(如某资源 404 或跨域阻塞) - 推荐搭配
DOMContentLoaded使用:前者管资源,后者管 DOM 结构就绪
为什么 document.readyState 不能直接驱动进度条
document.readyState 只有三个值:'loading'、'interactive'、'complete',它不反映资源加载比例,也不随图片/脚本下载实时更新。把它当进度信号,会导致进度条卡在 0% 或突跳到 100%。
典型错误写法:
setInterval(() => {
if (document.readyState === 'loading') bar.style.width = '30%';
else if (document.readyState === 'interactive') bar.style.width = '70%';
else bar.style.width = '100%';
}, 200);
- 该逻辑无法区分「DOM 解析中」和「图片还在下载」,视觉进度严重失真
-
interactive和complete之间可能间隔很久,用户看到进度条停在 70% 十几秒,体验极差 - 现代 SPA(如 React/Vue)中,
readyState很快到complete,但首屏内容仍为空白,此时进度条已消失
用 PerformanceObserver 监控资源加载耗时(现代方案)
真正可行的进度感知,得靠浏览器 Performance API 主动上报资源加载事件。用 PerformanceObserver 订阅 'resource' 类型,能捕获每个 <img>、<script></script>、<link> 的加载耗时与状态。
实操要点:
- 需在
尽早初始化 observer,否则会漏掉早期资源(如预加载的 CSS) - 统计已成功加载的资源数 / 总资源数,可粗略估算进度;但要注意:动态插入的资源(如懒加载图片)不会被初始 observer 捕获,需重新 observe 或结合
MutationObserver - 避免直接用
entry.duration做加权,因 CDN 缓存、本地缓存会让某些资源 duration ≈ 0,导致权重失衡 - 示例关键逻辑:
const obs = new PerformanceObserver(list => { list.getEntries().forEach(entry => { if (entry.entryType === 'resource' && entry.name.startsWith('https://')) { loadedCount++; updateProgressBar(loadedCount / totalExpected); } }); }); obs.observe({entryTypes: ['resource']});
服务端配合:用 Content-Length + 流式响应估算加载进度
纯前端无法知道 HTML 主文档体大小,但如果你控制服务端(如 Node.js / Nginx),可在响应头写入 Content-Length,再用 XMLHttpRequest 或 fetch + ReadableStream 监听 progress 事件。
限制很明确:
-
fetch本身不暴露原生 progress,必须用response.body.getReader()手动读 chunk,并累加已读字节数 - 需服务端开启
Transfer-Encoding: chunked或明确设置Content-Length,否则无法计算百分比 - 只监控主文档(HTML)加载,不包含后续资源,需额外叠加
PerformanceObserver补全 - 兼容性注意:Safari 对
ReadableStream的progress支持较晚,iOS 16.4+ 才稳定
真实项目中,多数团队选择「骨架屏 + 资源加载事件 + 超时兜底」组合策略,而不是强求精确百分比——因为用户感知的“慢”,往往来自白屏时间或交互延迟,而非数字是否精准。











