preload="none" 并非完全不加载，而是延迟加载——仅当video已插入DOM、src已设且未调load()、用户未触发播放时才真正省流量，适合非首屏或低点击率视频。

preload="none" 不是“完全不加载”的保险开关，而是告诉浏览器：别主动发起任何请求——但你得自己管好后续加载时机，否则用户点播放时会卡住。

preload="none" 什么时候真正省流量

它只在以下情况生效：video 元素已插入 DOM、src 已设置、但尚未调用 load()，且用户还没触发播放。此时浏览器连 DNS 查询都跳过，零字节发出。

• 适合视频列表页中大量非首屏视频（比如第 5 条以后的卡片）
• 适合明确知道用户大概率不点播的视频（如“相关推荐”里的备用项）
• 配合 loading="lazy" 使用时，可进一步延迟解析 video 标签本身（注意：IE 和部分旧 Android WebView 不支持该属性）

写了 preload="none" 却还是发了请求？常见原因

这不是 bug，是行为预期被破坏的典型信号：

• autoplay 属性同时存在 → 浏览器直接忽略 preload，并立即开始加载
• src 是在 DOM 加载后 JS 动态赋值的 → 多数浏览器会立刻触发加载（哪怕 preload 是 none），因为这是“首次感知资源”
• 服务端返回了 Accept-Ranges: bytes，但视频文件没做 faststart 优化 → 浏览器为读取元数据被迫下载前几 MB，看起来像“没生效”

如何让 preload="none" 真正可控地加载

必须显式干预，不能依赖属性本身：

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

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

• 首次设置 src 后，**不要**立刻调用 load()；等 IntersectionObserver 检测到视频进入视口再调
• 监听 scroll 或 resize 时，检查 video.getClientRects().length 是否 > 0，再调 load()
• 移动端微信内置浏览器对首次 load() 有静默丢弃风险，建议加 setTimeout(() => video.load(), 16) 微调
• 调用 load() 后，需等待 loadedmetadata（封面/时长就绪）或 canplay（可播放）事件，再启用控件或自动播放

iOS Safari 下 preload="none" 的特殊事实

它确实“最守约”——但代价是彻底放弃预加载能力：

• 所有 preload 值（包括 auto）都会被 Safari 静默降级为 none，不是 bug，是策略
• video.readyState 在用户点击前永远是 0（HAVE_NOTHING），别用它判断是否已加载
• 即使你手动调 load()，Safari 也只在用户手势（tap/click）上下文中才允许解码和播放，纯 JS 触发 autoplay 仍会被拦截

真正难的不是设成 none，而是在它生效后，准确判断“该不该 load、何时 load、load 失败怎么兜底”。尤其当多个视频共存、网络波动、用户快速滚动时，load() 的调用节奏比 preload 属性本身重要得多。