弱网和省流模式下的目录站：Save-Data 和 Client Hints 还要不要用
弱
服务端想在返回响应之前就知道用户的屏幕多宽、是不是想省流量，靠的是两类请求头：Save-Data 和 Client Hints。前者是用户主动开了省流模式，后者是浏览器按服务器要求上报设备信息。
两个机制都有实际价值，也都有明确的代价。先说清楚它们各自的现状，再谈该不该上。
图片来源：网络，版权归原作者所有，侵权请联系删除
Save-Data：只有 Chromium 系还认
用户开了省流模式之后，浏览器会在请求里带上 Save-Data: on。它是低熵提示，意思是不需要服务器用 Accept-CH 声明，客户端也会主动发送。
支持情况要坦诚讲：Chrome 从 49 起支持，Edge 79 起，Opera 35 起，安卓 WebView 和三星浏览器也支持；Firefox 和 Safari 都不支持。MDN 已经把它标为实验特性，并注明在多数主流浏览器引擎中不再默认支持。换句话说，它只能覆盖一部分用户，不能当成主力方案。
收到这个头之后，目录站能做的三件实事：
- 图片降档：把缩略图的质量参数调低、尺寸档位往下跳一档。这是收益最直接的一项。
- 关掉预取和自动播放：预加载下一页、自动播放的预览图、轮询接口，这几样在省流模式下都应该停。
- 减少首屏条目数：从一屏二十条降到十条，剩余靠滚动加载。
有一个必须做的事：响应里一定要加 Vary。MDN 的示例写得很清楚：
Vary: Accept-Encoding, Save-Data少了这一条，CDN 和浏览器缓存会把省流版本发给没开省流的用户，或者反过来。缓存串味的结果是有人发现自己的图片莫名变糊了。
Client Hints：要了才给，且只给同源
设备类的提示（宽度、DPR、视口宽度等）默认不发送。服务器要在响应里声明：
Accept-CH: Sec-CH-Width, Sec-CH-DPR, Save-Data
Vary: Sec-CH-Width, Sec-CH-DPR, Save-Data声明之后，后续请求才会带上这些头。这里有四个约束：
| 约束 | 具体表现 |
|---|---|
| 首屏拿不到 | 提示只在第二个请求开始携带，第一个请求没有 |
| 必须 HTTPS | 安全上下文是硬性要求 |
| 只给同源 | Chrome 从 67 起不再向第三方源发送，跨域图片 CDN 收不到 |
| 有时效 | 只在当前会话内有效，第三方需要额外委托 |
另外，老式的 Width 头已经被标准化为 Sec-CH-Width，旧名已弃用；它只在图片请求上发送，值是向上取整的物理像素数。
用户代理类的提示分两档：Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform 是低熵的，默认就发；Sec-CH-UA-Model、Sec-CH-UA-Full-Version-List 这类高熵的，同样需要 Accept-CH 请求。
算一笔账
收益侧：如果你的图片是自己 CDN 按 URL 参数实时生成的、没法预先生成多档文件，那 Sec-CH-Width 能让服务端直接输出刚好的尺寸，省掉 srcset 里那一堆候选。
代价侧：第一，首屏首次请求拿不到提示，第一次访问的用户享受不到（可以用 Critical-CH 让浏览器重试一次，代价是多一个往返）；第二，Vary 里每加一个头，CDN 的缓存键就多一维，命中率必然下降——这一条在多提示叠加时尤为明显；第三，跨域图片 CDN 收不到提示，等于在你的架构里这一套直接失效。
目录站的实际建议
srcset 加 sizes 仍是首选。浏览器端自己选尺寸，不依赖服务端协商，没有首屏盲区，也不污染缓存键。绝大多数目录站的缩略图场景，这一套已经够了。
Save-Data 值得做，但要降级处理。它只影响一部分 Chromium 用户，实现方式简单，收益也明确。做好了是加分，没做也不影响主体体验。记得加 Vary。
Client Hints 建议先观望。除非你的图片链路是自研实时处理、且能接受缓存键碎片化，否则收益撑不起复杂度。若一定要用，先只在图片请求上启用 Sec-CH-Width 一项，别一次全上。
还有个配套的小技巧：CSS 里有 prefers-reduced-data 这个媒体特性，可以在不经过服务端协商的前提下，对声明了省流偏好的用户做样式降级。它的支持面同样有限，但写法简单，作为渐进增强的一环加上无妨。
验收
用 curl 手动带上请求头看响应有没有变化：
curl -s -o /dev/null -w '%{size_download}\n' \
-H 'Save-Data: on' https://example.com/cate/1.html关键是对比：带 Save-Data 和不带，返回字节数必须有差别；同时确认两个版本的响应头里都带了 Vary。再清一次 CDN 缓存重测，否则拿到的可能是启用之前的版本。
最后提醒一句：这些机制优化的是「已经在访问的用户」的体验。如果用户因为首屏太慢在第一屏就走了，服务端拿到请求头的机会都没有——所以它们不能替代基础的首屏优化。