index.html页面加载百分比：HTML5状态反馈设计
原生progress标签不会自动更新加载百分比，需手动操作DOM属性。推荐使用PerformanceObserver追踪资源加载耗时计算进度，或以资源数量计数作为轻量方案。动画建议用transform:scaleX()提升性能。核心难点在于清晰定义“加载完成”的标准。
许多开发者误以为在页面中插入一个 ，加载进度就会从 0 自动走到 100——这个想法基本是错误的。需要明确一个核心判断：原生 标签本身只是一个空壳，浏览器不会主动将 HTML 解析、CSS 下载、图片加载等过程映射到它的 value 上。你看到的那个静止不动的 0%，就是它最诚实的状态。
要让进度条动起来，必须手动跟踪资源、计算比例、更新 value。实际项目中，有几个特别容易踩坑的地方需要注意。
为什么
简单来说， 只识别两个数字属性：value 和 max，并且必须手动赋值。更关键的是，setAttribute("value", "30") 这种写法是无效的——它只修改 HTML attribute，不会触发 DOM 属性的更新和渲染。正确做法是直接操作 DOM 属性：el.value = 30。
实际项目中常见的翻车点包括：第一，没有设置 max="100"，依赖默认值，结果后端返回小数（如 0.73）时直接赋值，进度条可能跑飞或卡死；第二，在 img.onload 回调中写 progress.value = count / total * 100，却忘记加 Math.round()，小数精度问题导致进度停留在 99.99999999999999% 的情况很常见；第三，有人用 document.readyState 判断，但它只有 "loading"、"interactive"、"complete" 三种状态，无法线性映射到 0–100%。
使用 PerformanceObserver 捕获真实资源加载占比
从技术实现角度，PerformanceObserver 是目前最接近“真实进度”的方案，尤其适合 Chrome 80+ 及现代 Edge。它能捕捉到每个资源的 startTime 和 duration，结合 navigationStart 可以估算出相对耗时占比。
不过，这个方案有几个关键实操点。首先，必须在 最早的位置初始化，否则会错过首屏 CSS、字体等关键资源。其次，要过滤掉 initiatorType === "xmlhttprequest" 的条目——那些是 API 请求，不属于页面初始加载的资源。真正需要统计的是 entry.initiatorType === "navigation"、"link"、"script" 这一类，也就是 HTML、CSS、同步 JS、内联脚本。另外，动态插入的资源，如懒加载的 img、import() 等，需要单独监听 load 事件并计入总完成数。
示例片段可以参考如下（已做简化处理）：
const observer = new PerformanceObserver((list) => {
const entries = list.getEntries().filter(e =>
e.entryType === "resource" &&
["navigation", "link", "script"].includes(e.initiatorType)
);
const totalDuration = entries.reduce((sum, e) => sum + e.duration, 0);
const loadedDuration = entries.filter(e => e.duration > 0)
.reduce((sum, e) => sum + e.duration, 0);
const percent = Math.round((loadedDuration / Math.max(totalDuration, 1)) * 100);
progress.value = Math.min(percent, 100);
});
observer.observe({ entryTypes: ["resource"] });
采用资源数量比例作为轻量级 fallback 方案
如果目标环境不支持 PerformanceObserver（例如旧版 Safari），或者页面资源结构比较简单（比如以图片为主），可以退而使用数量计数法。原理很简单：预先列出关键资源，监听它们的 load 或 error 事件。
边界条件需要仔细处理：第一，只统计 document.querySelectorAll('img, link[rel="stylesheet"], script:not([async]):not([defer])')，忽略 async/defer 脚本，因为它们不阻塞解析，不属于“页面加载”主路径。第二，link[rel="preload"] 需要单独加入队列，否则进度会提前结束。第三，图片的 srcset 或 picture 中的多个源，按实际加载的那个算 1 个，避免重复计数。此外，务必增加超时兜底机制，例如 8 秒后强制设为 100%，防止某个资源挂起导致进度条卡死。
transform: scaleX() 相比 width 更稳定的动画写法
使用 JavaScript 频繁修改 width 会触发重排，尤其在低端安卓手机上容易掉帧；transform: scaleX(n) 是合成层操作，性能更优。但兼容细节需要注意：iOS 15 之前对 scaleX(0) 存在渲染 bug，起始值建议设为 scaleX(0.001)。同时，不要在 load 回调中直接修改样式，先用变量缓存当前百分比，再用 requestAnimationFrame 统一提交。
话说回来，如果使用 ，其内部 track 渲染由浏览器控制，不需要手动添加 transform；但自定义