Who Opts-in to Save-data?
In Summary
Save-data is a client hint which indicates that your users want you to send less content to them. It is an option on Google Chrome Mobile and it's used predominantly in Asia, Africa and South America. There is a strong relationship between the value of a user's device and their likelihood to opt-in to save-data: the more expensive the device, the less likely they are to opt-in. While the opt-in rate is highest on cheaper devices and in less economically developed countries, this is not an absolute delineation. For example: users in Canada have an opt-in rate of over 34% (compared to ~7% in the US) and users on the latest Samsung flagship have an opt-in rate of almost 18% globally. Income inequality is a factor in national opt-in rate in most countries.
Google Chrome Mobile will use this hint to provide a proxied web experience in some scenarios, but this process is quite opaque. It may also defer scripts, force font-display: swap and force lazy loading of iframes and images.
Website owners should not rely on the browser to make these optimizations, but instead should allow users to opt-in to a data-saving experience. Save-data is a 'set-and-forget' setting which is rarely changed; providing a UI to allow users to opt-in or out of a 'lite' mode is a great progressive enhancement for modern websites.
Introduction
Save-data (often conflated with Data-Saver Mode / Chrome Lite Pages / Chrome Lite mode) is a client preference for reduced data consumption. The hint is currently available to JavaScript via the Network Information API and as an HTTP request header. The preference is set in browser settings, with Chrome mobile suggesting that you enable it when you go first open the application:
The save-data hint in itself does nothing, but there are a number of scenarios where service providers and website owners can react to the hint to deliver a better experience:
- Google Chrome may force interventions such as deferring external scripts and lazyloading iframes and images
- Google Chrome may proxy requests to improve performance for users who have opted in to 'Lite Pages' and have a poor network connection
- Website owners can deliver lighter versions of their applications, e.g. by lowering image quality, delivering a server-side rendered page or reducing the amount of third-party content
- ISPs can transform HTTP images to reduce size on the last-mile
There have already been a number of posts looking into Chrome Lite Pages, I'd recommend you take a look at Tim Kadlec's blog post for a great introduction to the feature and the problem it is trying to solve. In this post we're going to focus on the users who choose to opt-in.
Collecting Data
Akamai mPulse collects performance data from a range of sources in the browser, including the Network Information API. This API provides information about the device's current connectivity, as well as a saveData property. The open source mobile plugin for boomerang provides access to the API, and the data is available in Akamai mPulse as well as the open source boomerang.
The data is only available in Chromium-based browsers which support Lite pages, for now. A quick review of the data retreived in May shows that only four browsers have a reported save-data rate above 0.1%:
| Browser Name | Save-data Rate | Relative Traffic Share |
|---|---|---|
| Chrome | 0.61% | 26% |
| Chrome Mobile | 28.14% | 15% |
| Yandex Browser | 2.92% | 0.42% |
| Puffin | 35.23% | 0.003% |
We will be looking at Chrome Mobile hits in the following research, this represents the largest population of opted-in traffic and allows comparitive analysis of opted-in vs opted-out.
It is worth noting that this data is aggregated from mPulse beacons, which will show a natural weighting towards North America and Europe due to the customer base. The data is taken from a time period in May with a total of about two billion user experiences.
By Country
This section reviews the save-data opt-in rate by country. Analysis by country allows us to compare the opt-in rate against a number of factors which are accessible by country, such as cost of data and average income. The opt-in rate is the percentage of pageviews which had the saveData property set to true. Scroll down to move through various dimensions of analysis.
Average Cost per GB
When considering why people might opt-in to save data, the first answer that came to mind was the cost of the data. If the cost of data is high, then you are more likely to try to reduce your data usage, you might assume. I pulled the latest data for the average price paid for 1GB of data, normalized to USD, and compared it with the save-data opt-in rate by country.
Looking at this first scatter plot we can see that there is no immediately obvious correlation between cost of data in a country and the opt-in rate. A positive correlation would look like the points forming a line diagonally from bottom-left to top-right.
The result do show a few interesting points. The strongest correlating factor for save-data appears to be continent. The split in the data at around 40% opt-in separates Asia, Africa and South America (with high opt-in rates) versus North America, Europe and Oceania. The exceptions to this are Japan in Asia, which creeps below 40% mark at just 34.1% and Mexico in North America which is well above 40% at 66.4%.
Another standout feature of this chart is India. It is high on the y-axis at 62% opt-in, but almost zero on the x-axis at an average cost of $0.09 per GB. I first thought this was an error but it turns out that data really is that cheap in India!
Whilst this chart does give us some interesting information about why people might opt-in to save data, it does not show the strong correlation that I had expected.
Average Individual Income
The separation between continents in the first chart led me to a second hypothesis, that save-data opt-in rate is correlated with the wealth of a country. I pulled the latest income per capita values available from the World Bank and plotted this against opt-in rate.
Whilst again there is a clear separation between continents, this has become more pronounced. The countries that are less likely to opt-in to save-data are clustered towards the right-hand-side of the chart, on the higher end of average personal income. The countries that are more likely to opt-in are fairly evenly spread across the x-axis, with a slight positive trend which disagrees with the hypothesis.
UAE, at $43k GDP per capita, is near the right-hand-side of the chart but has a 64% opt-in rate. Compared this to Canada at $46k and 34% respectively.
One country that exhibits strange behavior here is Ireland. At $79k GDP per capita it is one of the richest countries in the world, but the average income of $44k gives it a income / GDP ratio of 0.56, one of the lowest globally. Compare this to the Netherlands which has a similar income but lower GDP at $53k, making an income / GDP ratio of 0.83. This isn't necessarily related to save-data, but interesting nonetheless and is perhaps a symptom of the tax advantages for basing technology companies in the country.
Saudi Arabia shows that a high average individual income does not necessarily correlate with low save-data opt-in. We know the dangers of taking averages, and this may highlight the impact of wealth disparity amongst some countries.
Income Inequality
This chart plots income inequality, as the percentage of total income earned by the bottom 50% of earners. A higher number represents a more even distribution of income.
The plot shows that the countries where save-data opt-in rates are higher, have greater income inequality - or relatively a greater population of low earners. Here we can see that at just 7.8% of income going to the bottom earners, Saudi Arabia has a significant wealth divide. This helps to explain the high opt-in rate.
Hours Worked for 1GB
Using the data collected above, we can calculate the average number of hours required to work to earn enough to purchase 1GB of data (assuming 2,000 working hours per year). This measure should get more close to the perceived cost of mobile data. My hypothesis is that the higher the relative cost of data in a country, the greater the likelihood for opt-in to save-data. This would look like a rough line from top-left to bottom-right (note that the x-axis is reversed).
The two obvious extremes here are Malawi on the far left and Israel on the far right of the chart. Malawi has an average annual income of $312 and an average data cost of $27 per GB, meaning that the average Malawian would have to work 256 hours to earn enough for 1GB of mobile data. In Israel, the average income is $36k and the average cost for 1GB is 11¢. This makes the hours required for one GB 0.006, just 22 seconds!
The left-hand-side of the chart is populated almost wholly by African countries, where salaries are low and data is expensive. The data generally agrees with the hypothesis, but does not show a direct correlation.
Average Network Speed
So far we have looked primarily at financial motivators for saving data, which has shown a rough correlation between relative cost of data and the likelihood to opt-in to save-data. Another motivator might be network performance. The Chrome Lite Pages opt-on prompt promises up to 60% reduced data and faster page loads, if a user knows that their connection is poor they might be more likely to opt-in to Lite Mode, and thus save-data.
The data shows that countries with an average mobile connection speed of less than 20Mbps have a much higher save-data opt-in rate, and countries with faster speeds are less likely to have high opt-in rates. One obvious outlier is Norway, with the highest average speed at 48.2Mbps but a high opt-in rate of 37%. On the other end of the spectrum, Belarus has an average speed of 7.7Mbps but an opt-in rate of 20%.
4G Network Availability
Much like the download rate correlation, 4G availability shows little correlation with opt-in rate. In fact a stark difference can be observed between Ireland, at 63.7% 4G penetration and 25% opt-in versus The Netherlands with at 92.8% penetration and 25.4% opt-in rate.
India is an outlier at 62% opt-in rate, but with one of the best 4G availability rates at 91%! This indicates that 4G penetration on its own is not a critical factor in likelihood to opt-in to save-data.
By Device
We've filtered the results down to Chrome Mobile in this analysis, which limits us to Android devices. But Android is a diverse ecosystem: from the $50 Alcatel 1 through to the $2,500 Huawei Mate XS. Device specifications and network capability vary greatly across the spectrum of devices, meaning that simply looking at Chrome Mobile covers a diversity of capability.
The chart below shows the top devices in the dataset, from the top 25 manufacturers:
The results show that users of cheaper devices are more likely to opt-in to save-data. Take a look at Samsung devices for example. The highlighted devices are the Galaxy S9, the Galaxy A50 and the Galaxy J7 Prime. These phones represent three reasonably similar devices from Samsung across their flagship, premium and budget product lines respectively. The J range is marketed to younger or more cost-conscious users and has relatively low specifications. The A series devices tend to inherit the components of the S series with an ~18 month delay.
The J7 was released 1.5 years before the S9, almost three years before the collection of this data. A such, this is likely to be purchased at a discount or used by those on pre-paid connections. The A50 was released in 2020, the same year of this analysis, so is likely purchased as a good value premium device or offered as a contract upgrade. The S9 was a flagship device released at ~$800 one year prior to the analysis, so is likely owned by users on a high-cost contract which includes a large amount of included data.
The difference in save-data opt-in is stark: just 17.7% for the premium S9 vs 36% for the A50 and 64% for the budget J7. Could this be users trying to keep their device feeling fast as it ages? Or budget-conscious users preserving small data budgets?
Another clear difference can be observed between premium and budget manufacturers. For example: Google devices average 21% opt-in, whilst Realme devices average 67%!
By Connectivity
It is a fair assumption that folks on poorer connections are more likely to opt-in to save-data, so let's look at the data! In the same API that gives us the save-data preference, we can also get the browser's current estimated downlink speed and network latency. This data is rounded and sometimes randomized to prevent fingerprinting, but is generally a good indicator of network quality. Take a look at your current advertised data below:
waiting...
The effectiveType is derived from the rtt and downlink values, you can see the derivation in the API Documentation. Perhaps confusingly, 4g is effectively infinite speed - any connection faster than 0.7Mbps and 270ms RTT is given this effective type.
When we extract that data and plot it with the save-data opt-in rates we see very little correlation. The majority of experiences fall into the 4g bucket, with the Cable/DSL (e.g. home wifi) bucket showing a 21.7% average opt-in rate, vs. ~31.6% opt-in rate for Dialup and Cellular. There are a large number of hits in the Not Set connection group, these are from connections which cannot be classified through NetInfo or IP lookup.
The results imply that users who do not have a home wifi connection are more likely to use the save-data hint.
The differences here are much smaller than between devices, which is likely due to the fact that save-data is a set-and-forget setting. Users are unlikely to change it based on their connectivity.
Performance
It may seem strange that I haven't mentioned performance results yet, given my interests! The reason is that it is impossible to separate correlation from causation with aggregated real user monitoring data. If a page is slow with save-data set, it is difficult to determine the cause of the slow performance. We do not know if any interventions are used by Chrome or the website.
To have a go at analyzing the data, we can separate out a single device and plot the performance of page loads with save-data set or not. The following chart is a five-number summary showing the 5th, 25th, 50th, 75th and 95th percentiles of DOM Ready time for the most common device in the dataset: the Samsung Galaxy S9. The results show that the value of th save-data flag makes zero appreciable difference to the performance, as measured by DOM Ready. This is as expected for the majority of sites which do not react to the hint, and thus deliver the same content. It is also unclear whether beacons are sent for cloud-rendered pages delivered by Google, so it is possible that these pages will be faster but not included in the data set.
Let's not Forget Lite Pages
Lite pages are proixed through Google Servers to improve performance and reduce size over the network. Google will optimize non-secure images and force performance interventions on the users device (e.g. lazy loading images and iframes). It can also redirect you to a 'cloud rendered' version of the page...
Interesting. What's the analytics / reporting outcome if a Lite Page is served (cloud rendered)? Are the rendered versions cached? Will analytics scripts fire? Does the cloud browser have a unique UA? Can you track Lite -> full sessions?
— Simon Hearne (@simonhearne) July 1, 2019
I've got so many questions!
You can try this for yourself (if you have a device with Chrome Mobile) by enabling "Lite Mode" in your settings and overriding effective connection type to 2G in chrome://flags:
The logic as to when Chrome will serve a Lite Page is not necessarily consistent, and Lite Pages will not be served for authenticated sessions. I believe analytics tags will not fire on Lite Pages although I'm happy to see data showing otherwise, or indeed any information from Google on the matter.
You can use the Reporting API to see if your pages are being proxied by Chrome Lite pages. Set a Report-To endpoint and look out for a report with the type intervention and an id LitePageServed:
{
"type":"intervention",
"url":"https://yoursite.com/page",
"body":{
"id":"LitePageServed",
"message":"Modified page load behavior on the page because the page was expected to take a long amount of time to load. https://www.chromestatus.com/feature/5148050062311424"
}
}Opting-out of Save-data
You may find that users complain that your page is broken in Lite Mode, or you may just not like Chrome making this intervention on your behalf. Some pages do not render quite right, as can be seen below for the BBC.
Developers can opt-out of cloud-rendered Lite Pages by including the cache-control: no-transform response header. This should prevent any intermediary (e.g. ISP, Chrome, CDN) from modifying the response, but it is a heavy-handed approach. no-transform may also interfere with CDN optimizations such as HTML minification and dynamic script injection.
Next Steps
Getting the data
Before doing anything about save-data, you need to know how many of your current users are sending the client hint. You can collect this data in your analytics tool of choice, for example with Google Analytics:
ga('create', 'UA-XXXX-Y', 'auto');
ga('set', 'savedata', navigator.connection.saveData);
ga('send', 'pageview');
Preferably, collect this data with your performance analytics tool. You can configure this easily in the mPulse UI:
Reacting to the hint
If more than 1% of your users are sending the save-data hint, it makes sense to do something about it. This can be anything from delivering lighter images through your CDN to delivering a static version of your site.
Images are the biggest source of transferred bytes on most web pages, so are the obvious candidate for saving data.
As we have seen earlier in the analysis, save-data is not limited to low-end devices. This means that you are likely sending 2x or 3x images to devices which have opted-in to save-data. A simple change to reduce size would be to only send 1x images to devices with save-data. If you have a CDN or image delivery service, it is likely possible to automate this! For example, Cloudinary can automatically reduce image quality if the save-data hint is set to true. Akamai Image Manager can even reduce quality based on network connectivity, with endless possibilities for custom behaviors based on the save-data client hint.
One of the biggest bottlenecks on the web is JavaScript. If your site is one of the 50% that ship more than 417kB of JS, sending a page without it will likely be a far superior experience for users with limited connectivity and under-powered devices.
Do you need to ship your whole framework for a landing page?
For even more creative ideas on this topic, I highly recommend watching Tim Vereecke's talk Data-S(h)aver Strategies from London Web Performance in 2019:
Something that Tim recommends is to allow users to opt-out of the lite mode without having to disable save-data. This can be achieved with a UI toggle and a cookie which overrides the save-data preference. This option, like dark theme toggles, allows users to choose the experience that best suits their current situation. It is quite possible that a large number of users opted-in to save-data when they first configured Chrome Mobile and have not thought about it since, and that an equally large number of users ignored the intial prompt and don't know that the feature exists.
Conclusion
We have seen that there can be many reasons for users to opt-in to save-data, and that the performance delivered to devices doesn't (yet) vary much based on the hint. A lack of awareness from both developers and web users mean that a potentially valuable web platform feature is under utilized. We currently rely on Chrome to make interventions on our behalf, potentially resulting in broken layouts, missing analytics and an unknown result with ad impressions. Could this be because Chrome is the only browser to embrace Save-Data?
Mindful observation of the save-data hint can provide a better user experience and save your visitors' data budgets. If you're not reacting to it now, think about what can be done to proactively reduce the data sent to your users.
