For many users, internet access is slow and expensive. To reduce costs many users opt-in to use optimization services (proxies) that fetch and optimize resources on their behalf - e.g. re-encode images at lower quality, compress text resources, etc. However, this model has several limitations:
Proxies cease to function when user is accessing content over HTTPS.
Origin sites (accessed over HTTP and HTTPS) may be willing to help provide an improved “save data” experience but don't have a reliable and well defined way to detect such user preference.
The “Save-Data” request header is an end-to-end header that addresses both of the above limitations: it is advertised by the browser based on user opt-in, and it is sent to all origins. The presence of the header is an indicate of explicit user opt-in into a "reduced data usage" mode.
Note: the fact that Save-Data is an indication of explicit user opt-in is important. This allows the user to opt-out from such experience - e.g. user may be on slow or expensive network but may still want to fetch high resolution images for one reason or another.
An example implementation in Google Chrome:
Save-Data header is appended to all requests when user enables Chrome Data Compression.
Save-Data request header is end-to-end: requests that pass through Chrome Data Compression proxy pass through the header, allowing the site to optimize the experience at the origin.
Save-Data header does not communicate anything about the "quality levels" of certain content types (e.g. images), or similar preferences. It may be useful to communicate that information as well, but that should be done via separate mechanism (e.g. other headers).
For many users, internet access is slow and expensive. To reduce costs many users opt-in to use optimization services (proxies) that fetch and optimize resources on their behalf - e.g. re-encode images at lower quality, compress text resources, etc. However, this model has several limitations:
The “Save-Data” request header is an end-to-end header that addresses both of the above limitations: it is advertised by the browser based on user opt-in, and it is sent to all origins. The presence of the header is an indicate of explicit user opt-in into a "reduced data usage" mode.
Note: the fact that Save-Data is an indication of explicit user opt-in is important. This allows the user to opt-out from such experience - e.g. user may be on slow or expensive network but may still want to fetch high resolution images for one reason or another.
An example implementation in Google Chrome:
Save-Data
header is appended to all requests when user enables Chrome Data Compression.Save-Data
request header is end-to-end: requests that pass through Chrome Data Compression proxy pass through the header, allowing the site to optimize the experience at the origin.Save-Data
header does not communicate anything about the "quality levels" of certain content types (e.g. images), or similar preferences. It may be useful to communicate that information as well, but that should be done via separate mechanism (e.g. other headers).