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 weight 2,48 MB up from 1,2 MB just , 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: onSupporting 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 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-DataClient 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 .
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.
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 ) 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 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.