> ## Content Index > Fetch the complete content index at: https://www.ctrl.blog/llms.txt > Use this file to discover other available public pages before exploring further. # New Save-Data HTTP header tells websites to reduce their data usage - URL: https://www.ctrl.blog/entry/http-save-data/ - Published: 2017-05-23T14:19:00.000Z - Updated: 2026-08-23T22:11:34.000Z - Description: The new HTTP Save-Data request header can help websites determine the bandwidth constraints of their visitors. Plus, a browser extension for users to adopt it. - Author: Daniel Aleksandersen - Tags: Compression, Hypertext, WebPerf Some users are okay with a slightly degraded user experience and lower image quality in exchange for lower data usage and costs savings. There haven’t been a standard way of letting websites know about this preference before, but the new `Save-Data` HTTP request header introduces just such a method. Now it’s up to web developers to adopt it to serve their audience the best way they can. By default, every website should use as little bandwidth as possible while still delivering the user experience they want to give their users. The average website at the end of 2016 weight 2,48 MB up from 1,2 MB just four years earlier, according to HTTP Archive. This trend isn’t good news for the data usage conscious web surfer. The new `Save-Data` HTTP request header introduces a standard method for visitors to express their preference to the websites they visit. Websites have previously been making decisions about bandwidth usage — I suspect those decisions have often been made uninformed — in total isolation from their visitors and their needs. The new request header is a clear and actionable signal for websites that data usage is at a premium, and that **the best way to deliver a good user experience is to reduce their bandwidth footprint.** Web browsers and other clients and apps can tell web servers about their preference for data-savings by including an additional HTTP request header: ``` Save-Data: on ``` Supporting web servers who understand this request can make whatever adjustment they feel are necessary to “save data” in their responses. There’s **no standard for how websites should handle these requests.** However, the intention is for websites to reduce their data footprint in whatever way they think will impact their audience the least. Some ideas may be to return an empty favicon, increase image compression rates at the expense of image quality, avoid preloading full image galleries and images far down on the page, stop auto-buffering and auto-playing video and audio, and maybe even reduce ads and third-party embedded widgets. Of course, the website should consider always doing these things as it would boost their loading performance. Websites could even deploy even more transforming alterations removing some images entirely. For example, an news site could display images for their top ten news stories on their front page, and rely on headlines and ingresses for articles further down the page. A news app or feed reader could likewise drop images for older stories. Any resource that vary depending on the `Save-Data` request header must include a `Vary: Save-Data` response header to inform caches about the varying. See [Explaining the HTTP Vary response header](https://www.ctrl.blog/entry/http-vary-explained/) for details. The following example response shows a resource that varies based on supported compression methods, `Do-Not-Track` requests, and `Save-Data` requests: ``` Vary: Accept-Encoding, DNT, Save-Data ``` ### Client support You may have heard of the compression proxy service called Turbo mode in the Opera browser and Yandex.browser, or the Data Saver option in Google Chrome for Android. When users enable these features, their HTTP traffic is sent to compression proxy servers operated by their parent companies who perform aggressive compression on behalf of their users. These services don’t process encrypted HTTPS websites; which is quickly becoming the default across the web as browsers are moving to label HTTP as insecure. When users enable these options, however, they’ll start including the `Save-Data: on` header with all their requests — including to HTTPS websites. It’s up to each individual website to handle these requests, the same way websites might handle the Do-Not-Track request and other specialized request headers. No client that I’m aware of sends the Save-Data header by default everywhere. However, I believe we might see it on by default in the future in mobile applications and browsers when they detect they’re on EDGE or other legacy mobile networks. This option may also show up by default in less powerful devices and devices with lower resolutions screens like budget E-readers and lower-end phones. The Data Saver option (which includes the compression proxy service) is also available for Google Chrome on the desktop, Opera, Vivaldi, and other Chromium based web browsers as an extension. Google have discontinued this extension as of 2019-06-16. If you want to enable the `Save-Data: on` request header in your web browser without the use of a compression proxy service, you can install my aptly named `Save-Data: on` extension for Firefox, and for Google Chrome, Vivaldi, Opera, and other Chromium based web browsers. [![Get this Mozilla Firefox add-on](https://cdn.synaps.media/control/content/images/2026/08/get-firefox-extension.svg)](https://addons.mozilla.org/en-US/firefox/addon/save-data/?src=external-addonsbadge-ctrl.blog&ref=ctrl.blog)[![Get this Microsoft Edge extension](https://cdn.synaps.media/control/content/images/2026/08/get-msedge-extension.svg)](https://microsoftedge.microsoft.com/addons/detail/ikpocbechgonkffflodoiadeddajhfli?ref=ctrl.blog)[![Get this Google Chrome extension](https://cdn.synaps.media/control/content/images/2026/08/get-chrome-extension.svg)](https://chrome.google.com/webstore/detail/save-data-on/nholpkfnmjbinlhcfihkhiehdaohlibg?ref=ctrl.blog)[![Get source on GitHub](https://cdn.synaps.media/control/content/images/2026/08/get-github-source.svg)](https://github.com/da2x/save-data?ref=ctrl.blog) ### Website adoption Websites that have out-sourced their performance decisions to Google already support the `Save-Data` request header for image compression levels. Websites using the Google PageSpeed module version 1.11.33.1 (released in March 2016) or newer for Apache or nginx web servers who haven’t disabled the default rewrite\_images module serve lower quality images to visitors who request data savings. The PageSpeed module by Google is installed on more than 8500 websites, according to BuiltWith. However, over a year after the first version with `Save-Data` support was released, very few websites seem to be running a recent enough version to take advantage of it. It’s interesting to note that Google’s own Data Saver compression proxies are powered by the same open-source libraries that are used to make the PageSpeed module. The behavior and image quality should be very similar for images compressed using Google’s proxy servers and the images served with a self-hosting Google PageSpeed module instance. I went through the `Vary` response headers that listed `Save-Data` across the web in April 2017 as recorded by the HTTP Archive to see what deployments where out there. When I exclude my humble blog, I only found four other websites that had implemented support for the `Save-Data` request header without the use of the Google PageSpeed module. Considering how easy it’s to support and how beneficial it can be to users’ wallets, I’m frankly surprised that the number was so low. It seems web developers should pay closer attention to developments in new HTTP standards. I hope that you’ll consider adding support in your website or app now that you’ve spent all this time reading down to the end of my little introductory article. #### Sources - [HTTP Client Hints](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-04?ref=ctrl.blog), 2017-04-18, HTTP Working Group, Internet Engineering Task Force - [Image Filter and Option Reference](https://www.modpagespeed.com/doc/reference-image-optimize?ref=ctrl.blog), PageSpeed documentation, Google - [Release notes for 1.11.33.0-beta](https://www.modpagespeed.com/doc/release%5Fnotes?ref=ctrl.blog#release%5F1.11.33.0-beta), 2016-03-30, PageSpeed Release Notes, Google - [Data Saver](https://web.archive.org/web/20171114184320/https://developer.chrome.com/multidevice/data-compression), Chrome for a Multi-Device World, Google Developer - [\[HTTP\] Trends](https://httparchive.org/reports/state-of-the-web?start=2012%5F01%5F15&end=2016%5F11%5F15&ref=ctrl.blog), 2016-11-15, HTTP Archive - [Avoiding the Not Secure Warning in Chrome](https://developer.chrome.com/blog/avoid-not-secure-warn/?ref=ctrl.blog), 2016-10, Eric Lawrence, WebFundamentals, Google - [Google PageSpeed Module trends](https://web.archive.org/web/20170517034511/https://trends.builtwith.com/framework/Google-PageSpeed-Module), 2017-05-17, BuiltWith - [HTTP Archive dump for 2017-04-15](https://web.archive.org/web/20180324094933/http://httparchive.org/downloads.php), 2017-04-15, HTTP Archive