如何借助 navigator.connection.saveData 为终端访客自动节省手机流量

saveData 是 navigator.connection 提供的只读布尔值，反映用户是否启用系统级“数据节省模式”，它不主动省流，仅作为前端决策信号；需三层防护安全读取，并配合图片降级、视频预加载策略等实现真实流量优化。

saveData 是什么，它真的能省流量吗

navigator.connection.saveData 是一个只读布尔值，由浏览器根据用户是否在系统/浏览器层面开启了“数据节省模式”（如 Chrome 的 Data Saver、Android 的 Data Saver、iOS 的 Low Data Mode）来决定。它不控制任何行为，只是告诉你当前环境是否倾向于省流。

• 它不能主动开启省流，也不能强制压缩资源；它只是一个信号
• 值为 true 时，通常意味着用户处于移动网络、资费敏感或信号较弱的场景
• 并非所有浏览器都支持：Safari 从 iOS 14.5 / macOS 11.3 才开始支持，旧版 Safari 返回 undefined；IE 不支持

所以别指望靠它“自动省流”，它只负责传递意图——你得自己响应。

怎么安全地读取 saveData 并避免报错

直接访问 navigator.connection 可能在部分环境（如某些 WebView、老版安卓浏览器、禁用 Network Information API 的隐私模式）下抛出 TypeError: Cannot read property 'saveData' of undefined。

必须做三层防护：

• 检查 navigator.connection 是否存在
• 检查 navigator.connection.saveData 是否为布尔值（有些浏览器返回 undefined 或字符串）
• 建议加个 fallback：当无法判断时，默认不启用省流策略（保守更安全）

const shouldSaveData = () => {  if (!navigator.connection) return false;  const saveData = navigator.connection.saveData;  return saveData === true;};

不要写成 !!navigator.connection.saveData——这会把 undefined 变成 false，看似没问题，但掩盖了 API 不可用的事实，不利于后续调试。

哪些前端操作值得配合 saveData 做降级

saveData 为 true 时，应优先减少请求体积和请求数量，而不是牺牲核心功能：

• 图片：用 srcset + sizes 切换低分辨率图，或 fallback 到 webp → jpeg → svg 降级链；避免 JS 动态加载高清图
• 视频：默认不自动播放，禁用 preload="auto"，改用 preload="metadata"
• 字体：跳过自定义字体（用系统字体栈），或只加载 font-display: swap + woff2 子集
• 第三方脚本：延迟加载非关键 SDK（如分析、广告），或完全跳过（需业务侧确认）
• 动画：关闭 CSS prefers-reduced-motion 之外的富交互（如轮播图自动切换、粒子动效）

注意：不要在 saveData 下停用错误监控、基础埋点或登录态校验——省流不该以不可观测、不可登录为代价。

服务端也能用？别依赖客户端传的 saveData

有人想在请求头里加 X-Save-Data: on，然后后端据此返回压缩 JSON 或低清图。这不可靠：

• 请求头可被任意篡改，不是可信信号
• 服务端无法验证该 header 是否真实来自浏览器原生 API
• 移动 CDN（如 Cloudflare）虽支持 Save-Data 请求头，但仅限于明确开启该特性的边缘规则，且仍依赖客户端真实发送

更稳妥的做法是：前端检测到 saveData === true 后，拼接带标记的 URL（如 ?sd=1），再由后端识别并走轻量逻辑——至少 URL 参数不可伪造（相比 header 更易审计）。

真正难的不是读这个值，而是判断哪些资源可以安全降级、降多少、降完是否影响转化或上报。很多团队卡在这里：测了图片压缩率，却忘了首屏文字渲染延迟 200ms 就让跳出率涨了 3%。