HTML5无需安装，浏览器卡顿源于video/audio标签的性能问题；应合理设置preload属性、确保H.264+AAC编码兼容、避免无交互autoplay、改用requestVideoFrameCallback优化监控。
HTML5 不是“安装”的软件，浏览器卡顿和所谓“安装 HTML5”没有因果关系——现代浏览器（Chrome、Edge、Firefox、Safari）早已原生支持 HTML5，无需额外安装。你遇到的卡顿，实际是页面中使用了 HTML5 <video></video> 或 <audio></audio> 标签播放媒体时的性能问题，根源在资源加载、解码、渲染或兼容性环节。
检查 preload 属性是否误设为 "auto"
很多开发者默认写 <video src="a.mp4" preload="auto" controls></video>，这会让浏览器在用户还没点播放时就拼命下载整个视频文件，尤其在弱网或高分辨率场景下，直接吃光带宽、阻塞主线程、拖慢页面响应。
-
preload="metadata"是更安全的选择：只拉取时长、宽高、封面等元数据，不加载视频帧 -
preload="none"更激进，适合列表页中大量视频缩略图场景，点击后再手动调用video.load() - 移动端慎用
preload="auto"，iOS Safari 会直接忽略它；Android Chrome 虽支持，但可能触发后台预加载导致内存飙升
确认视频格式与编码是否真正兼容
不是所有 MP4 都叫“HTML5 友好 MP4”。浏览器只认 H.264 + AAC 编码的 MP4 容器，若你的视频是 H.265（HEVC）、AV1 或 ProRes 编码，即使后缀是 .mp4，也会触发软解（CPU 解码），造成严重卡顿甚至白屏。
- 用
ffprobe your-video.mp4检查编码：Stream #0:0(und): Video: h264 (High)才稳妥 - 转码推荐命令：
ffmpeg -i in.mp4 -c:v libx264 -crf 23 -preset fast -c:a aac -b:a 128k out.mp4 - 避免在
<source></source>中堆砌无意义的多格式回退，比如 WebM（VP9/AV1）虽压缩好，但低端 Android 设备解码极慢，反而更卡
警惕 autoplay + play() 自动触发引发的卡顿链
用户未交互就调用 video.play()，现代浏览器会静音拦截并抛出 NotAllowedError，但部分旧版 WebView 或 Electron 壳里会强行硬启，导致解码线程抢占、音频上下文初始化失败、甚至触发反复重试逻辑，页面瞬间变卡。
立即学习“前端免费学习笔记（深入）”；
- 永远用用户手势（
click、touchstart）作为play()的触发条件 - 不要在
DOMContentLoaded或load事件里直接play()，哪怕加了muted - 检查是否无意中在滚动监听里频繁调用
play()，例如“进入视口自动播放”，没做防抖或状态锁，会导致同一视频被反复play()→pause()切换，触发大量解码-销毁循环
用 requestVideoFrameCallback 替代轮询判断播放状态
有些监控逻辑写成 setInterval(() => { console.log(video.currentTime) }, 100)，看似无害，实则每秒强制读取布局+触发同步计算，在低端设备上极易引发 forced synchronous layout，拖慢整个页面渲染。
- 改用原生 API：
video.requestVideoFrameCallback((now, metadata) => { /* 处理当前帧 */ }) - 它只在浏览器真正渲染视频帧时回调，零额外开销，且与渲染管线对齐
- 注意兼容性：Chrome 94+、Edge 94+、Firefox 99+ 支持；Safari 尚未支持，需降级为
requestAnimationFrame+ 时间差校验
真正卡住你的，从来不是“HTML5”本身，而是对 <video></video> 标签背后加载、解码、合成、事件调度这些链条缺乏控制意识。一个没设 preload 的 4K 视频标签，比十个 jQuery 插件还容易让页面窒息。
