preload="none"本身不减少服务器带宽，它只推迟请求——真正省带宽的前提是用户没点播放，服务器就完全收不到请求；设为none后浏览器跳过DNS查询、TCP握手、TLS协商及任何HTTP请求，服务器日志无访问记录，自然零带宽消耗。
preload="none" 本身不减少服务器带宽，它只推迟请求——真正省带宽的前提是：用户没点播放，服务器就完全收不到请求。
为什么preload="none"在服务端几乎零消耗
设为 none 后，浏览器连 DNS 查询都跳过，更不会发 TCP 握手、TLS 协商或任何 HTTP 请求。服务器日志里根本看不到该视频资源的访问记录，自然不产生带宽消耗。
常见错误现象：
- 写了
preload="none"却在页面加载时用 JS 调用了video.load()或设置了video.src—— 这等于主动取消了none的效果 - 视频
src是动态拼接的（比如带 token），但提前写死在 HTML 里，导致解析时就触发预连接 - 误以为微信内嵌页自动降级就安全，结果 X5 内核在某些版本下对空
src+load()有静默重试逻辑，可能发两次请求
preload="none" 必须配合 src 延迟注入
光写属性没用，关键在控制资源 URL 的注入时机。只有当用户即将可见或明确触发交互时，才把真实 src 赋值给 video 元素。
立即学习“前端免费学习笔记（深入）”；
- 信息流场景：用
IntersectionObserver监听进入视口，再赋值video.src = "xxx.mp4" - 卡片式布局：点击“播放”按钮后，再设置
src并调用video.load() - 避免在
DOMContentLoaded或ready回调里提前赋值src，哪怕只是字符串拼接也触发预加载 - 如果必须用占位符，用空字符串
src=""，别用src="about:blank"或src="data:"，部分 Android WebView 会误判并发起请求
Chrome 对小 MP4 的静默预读怎么防
即使 preload="none"，Chrome 桌面版和部分安卓 WebView 在遇到本地路径或同域 HTTP/2 连接复用的小 MP4（≤ 1MB）时，可能仍会静默发一个 Range: bytes=0-2047 请求，只为快速获取宽高——这虽只几 KB，但对计费按请求次数或固定带宽包的服务器仍有影响。
- 最稳方案：把视频域名与主站分离（如
media.example.com），断开 HTTP/2 连接复用 - 次选方案：服务端对
Range请求返回416 Range Not Satisfiable，并确保响应头不含Accept-Ranges: bytes - 不推荐方案：靠 JS 删除
src再设回来——多数浏览器已缓存连接，无效
真正决定服务器带宽的，从来不是 preload 属性本身，而是 src 第一次被赋予有效 URL 的那个瞬间。这个瞬间，必须由用户行为驱动，且不能被任何隐式逻辑绕过。
