saveData 是 navigator.connection 提供的只读布尔值,反映用户是否启用系统级“数据节省模式”,它不主动省流,仅作为前端决策信号;需三层防护安全读取,并配合图片降级、视频预加载策略等实现真实流量优化。
navigator.connection.saveData 是一个只读布尔值,由浏览器根据用户是否在系统/浏览器层面开启了“数据节省模式”(如 Chrome 的 Data Saver、Android 的 Data Saver、iOS 的 Low Data Mode)来决定。它不控制任何行为,只是告诉你当前环境是否倾向于省流。
true 时,通常意味着用户处于移动网络、资费敏感或信号较弱的场景undefined;IE 不支持所以别指望靠它“自动省流”,它只负责传递意图——你得自己响应。
直接访问 navigator.connection 可能在部分环境(如某些 WebView、老版安卓浏览器、禁用 Network Information API 的隐私模式)下抛出 TypeError: Cannot read property 'saveData' of undefined。
必须做三层防护:
navigator.connection 是否存在 navigator.connection.saveData 是否为布尔值(有些浏览器返回 undefined 或字符串) const shouldSaveData = () => { if (!navigator.connection) return false; const saveData = navigator.connection.saveData; return saveData === true;};
不要写成 !!navigator.connection.saveData——这会把 undefined 变成 false,看似没问题,但掩盖了 API 不可用的事实,不利于后续调试。
saveData 为 true 时,应优先减少请求体积和请求数量,而不是牺牲核心功能:
srcset + sizes 切换低分辨率图,或 fallback 到 webp → jpeg → svg 降级链;避免 JS 动态加载高清图 preload="auto",改用 preload="metadata" font-display: swap + woff2 子集 prefers-reduced-motion 之外的富交互(如轮播图自动切换、粒子动效)注意:不要在 saveData 下停用错误监控、基础埋点或登录态校验——省流不该以不可观测、不可登录为代价。
有人想在请求头里加 X-Save-Data: on,然后后端据此返回压缩 JSON 或低清图。这不可靠:
Save-Data 请求头,但仅限于明确开启该特性的边缘规则,且仍依赖客户端真实发送 更稳妥的做法是:前端检测到 saveData === true 后,拼接带标记的 URL(如 ?sd=1),再由后端识别并走轻量逻辑——至少 URL 参数不可伪造(相比 header 更易审计)。
真正难的不是读这个值,而是判断哪些资源可以安全降级、降多少、降完是否影响转化或上报。很多团队卡在这里:测了图片压缩率,却忘了首屏文字渲染延迟 200ms 就让跳出率涨了 3%。