Blog

Does Android’s Battery-Saver Degrade the Mobile Web Experience?

Tue, May 29th, 2018 | Utkarsh Goel

Modern websites rely on computationally-heavy Javascript, stylesheets, and imagery to generate aesthetically pleasing experiences for their users. To achieve maximum user engagement and yield a potential website conversion, a typical mobile website today downloads hundreds of resources from dozens of first- and third-party services. These resources help personalize the website to user interests as well as monitor the performance as the user interacts with the website. Indeed, in the last several years, mobile websites have grown drastically in both complexity and size, and this has led to even slower page loads and higher user frustration with the website. A study from 2014 suggests that only about 51% of mobile users tend to wait for more than two seconds for a web page to load before they abandon the website. As websites continue to grow in complexity and size, the key to improve website responsiveness is to build faster networks, optimize website content, and produce mobile devices with faster CPU. While many networks have already begun to deploy faster infrastructures, and most websites already employ a suite of website optimization techniques, mobile device hardware continues to remain a limiting factor to further improving mobile web performance.

Specifically, Android smartphones have battery-saver mode that lowers the battery consumption when charge levels drop to a certain threshold. Among other things, the battery-saver mode reduces the device’s performance by throttling the CPU clock speed, where it deactivates the power-hungry and faster processor cores and activates the battery-saving and slower processor cores. Since loading web pages require HTML parsing, downloading and processing of external resources, executing computationally-heavy JavaScript, and building the DOM and CSSOM, and since these all tasks make use of device’s CPU resources, does a throttled CPU clock speed under battery-saver mode degrade the mobile web performance? In other words, do mobile websites load slower on Android phones when battery charge levels drop to a certain threshold? Since this aspect of mobile web performance has not garnered much of the developer interest in the past, developers remain unaware of the impact that their website design choices might make on web performance, especially when mobile devices activate battery-saver modes and throttle the CPU clock speed.

Using a large-scale mobile web performance dataset collected via Akamai’s mPulse for websites loaded by real users, I discovered that under battery-saver mode, select phones from Huawei, Sony Xperia, and Samsung Galaxy series degrade mobile web performance metrics, such as the page load time, time to first paint, total LongTask time, time to interactive, and frame rate. The data also suggests that the battery-saver mode makes a higher impact on web performance when web pages load over faster mobile network conditions. The above findings demonstrate a clear need for new website design choices that would go hand in hand with the understanding of how user devices with low battery charge levels could degrade the end-user experience. Specifically, developers need to build websites that adapt to different battery situations to overcome any user-perceived responsiveness issues inflicted by the battery-saver mode. In this article, I discuss several techniques that developers could incorporate to potentially make their websites more responsive under low battery situations.

 

Measuring Website Performance

 

To understand how fast a website loads, I measured page load time (PLT), which is the time since the start of the page navigation until the trigger of the window.onLoad event. The website performance can also be measured by time to first paint (TTFP), which is calculated as the time since the start of the page navigation until the browser paints the first pixels. I also measure the total LongTask time, which is the time during which the browser main/UI thread is blocked and the user is unable to interact with the page. Finally, I measured the average frame rate of printing frames on the screen.  All of these should give insight into how battery-saver mode affects performance.

 

Measuring Page Load Time

 

 

Performance on Huawei Y6 Elite

 

In Figure 1, I show various percentile PLT values for a page loaded on Huawei Y6 Elite smartphone. From the figure we can observe that across all distributions, the PLT inflates as soon as the battery charge level drops to 15%, likely due to degraded CPU clock speeds triggered by the battery-saver mode. The figure also suggests that on most Huawei Y6 Elite smartphones, the default threshold for when the battery-saver mode initiates is set to 15%.

 

Figure 1. PLT distributions across different device battery charge levels, as measured for a page loaded on Huawei Y6 Elite mobile device.

 

In the table below, I summarize the analysis from Figure 1 to compare the PLT observed when battery charge levels are, for example, 8% and 50%. Note that the battery charge levels 8% and 50% are just two example representative points for comparing the performance under the battery-saver and normal modes.

From the table we can observe that the relative difference in the page load decreases as the network performance degrades. Specifically, among the two battery levels, 8% and 50%, for page loads represented by the 10th percentile distribution (p10), the PLTs at 8% are higher by ~28% compared to the PLTs at 50%. Whereas, for the 90th percentile distribution (p90), the PLTs at 8% are higher by ~15% compared to the PLTs at 50%. This downward trend suggests that as we load websites on faster networks, the smartphone’s CPU becomes a more significant bottleneck for website performance. Indeed this trend is similar to a previous research study from Akamai that investigates how device performance impacts web performance.

Both PLT and TTFP metrics make direct impact on the user experience. As such, an increase in these metrics, due to degraded CPU clock speeds, represents a degradation in the user experience.

 

Performance on Huawei P8 Lite (2015)

 

Similarly to Figure 1, as shown in Figure 2, we observe a sudden inflation in PLTs when loading a web page on the 2015 model of Huawei P8 Lite smartphone. Since the inflation occurs when the battery charge level is at 10%, it appears that the battery-saver mode on the Huawei P8 Lite smartphone turns on for most users at 10%.

 

Figure 2. PLT distributions across different device battery charge levels, as measured for a page loaded on Huawei P8 Lite (2015) mobile device.

 

Additionally, as shown in the table below, when we compare the relative PLT differences across different distributions, we can observe that the impact of throttled CPU clock speeds on PLT appears to be more significant when pages are loaded in fast network conditions.

In my investigation, I observed similar trends in performance for other websites that loaded on Huawei P8 Lite smartphone, as shown in Figure 3. From the figure, we can observe that there is a sudden inflation in PLT values when the battery charge level drops below 10%.

 

Figure 3. PLT distributions across different device battery charge levels, as measured for another page loaded on Huawei P8 Lite (2015) mobile device.

 

Note that for the websites loaded on the 2017 model of Huawei P8 Lite smartphone, I do not observe sudden inflations in PLT or TTFP at any battery charge level, potentially because the 2017 model has a faster CPU that can handle the page load despite the drop in performance. Additionally, I noticed that the newer smartphones from the same family, such as Huawei P9 Lite and P10 Lite, also do not degrade website performance under low battery charge levels.

 

Performance on Sony Xperia Z5 Compact

 

In Figure 4 we observe that when pages load on Sony Xperia Z5 Compact smartphone, there is an upward slope indicating that page load times continue to rise as battery charge levels drop below 40%.

 

Figure 4. Page load time distributions across different device battery charge levels, as measured for a page loaded on Sony Xperia Z5 Compact mobile device.

 

I haven’t been able to identify the cause for such an upward slope, even though this device allows users to set a threshold at which the battery-saver mode activates. Perhaps, unlike other Android devices, this device has also a linear slowdown in the CPU clock speed when the battery charge levels reach 40%. I did not observe such a strong download slope for other Sony devices, such as Xperia X Compact, Xperia X Performance, and Xperia XZ. Additionally, there was no inflation in PLT for these devices.

 

Measuring the Time to First Paint

 

In Figure 5, I show various percentile time to first paint (TTFP) values for the same page as Figure 1, when loaded on Huawei Y6 Elite smartphone. From the figure we can observe that there exists a sudden inflation in the TTFP when the battery charge levels drop below 15%. This trend suggests that the time when the browser paints the first pixels also increases when the device enables the battery-saver mode.

 

Figure 5. TTFP distributions across different device battery charge levels, as measured for a page loaded on Huawei Y6 Elite mobile device.

 

Similarly to Figure 1, I also noticed sudden inflations in TTFP at battery charge level 15%, when loading websites on the 2015 model of Huawei P8 Lite smartphone.

 

Measuring LongTask Time

 

LongTask is a new web performance measurement API that allows identification of resources that make websites unresponsive to user interactions. More specifically, web developers could use the LongTask API to detect the presence of tasks that block the browser UI/main thread for at least 50 milliseconds. When a website loads resources that block the browser UI/main thread, the user is unable to interact with the page. Specifically, a LongTask prevents the page from responding to user actions, such as scroll, click, tap, key, wheel, etc, until the LongTask has finished executing. This is because when a LongTask is executing, all user actions are queued behind the LongTask.

Poorly designed JavaScript code is one example of what might cause a browser main thread to block for over 50ms. Since the current LongTask API (v1) does not reveal the URL of the LongTask (though the second version of the API will provide such detail, including the line number that caused the LongTask), it is unclear as to what particular resources block the browser main thread. Therefore, in my analysis, I only focus on investigating whether or not we observe a rise in the total LongTask time when device CPU clock speed throttles when battery charge levels drop below a certain threshold, as opposed to discussing the root cause of a large or small total LongTask time.

 

Figure 6. LongTask time distributions across different device battery charge levels, as measured for a page loaded on P8 Lite (2015) smartphone.

 

In Figure 6, I show the boxplot distributions of the total LongTask time across different battery charge levels when loading a website on the 2015 model of the Huawei P8 Lite smartphone.  From the figure we can observe that the total LongTask time inflates when device battery charge level drops below 10%. The rise in the total LongTask time indicates that when the device CPU clock speed is throttled to minimize battery consumption, LongTasks block the main thread for longer than usual time. Note that I did not observe inflation in the total LongTask time on the 2017 model of Huawei P8 Lite smartphone, likely due to the fact that faster processors on the device do not impact the total LongTask time when their speeds are throttled by the battery-saver mode.

 

Measuring Time to Interactive

 

Not only does a LongTask delay user interactions, but events callbacks (such as onLoad etc.) are also delayed. In many pages where many LongTask exists as the page loads, the time at which the user could first interact with the page could also get delayed. Additionally, note that even though LongTask is the prime cause for poor responsiveness to user interactions, other tasks, such as image decoding, heavy rasterization work, or presence of too many layers on the page can also cause poor responsiveness.

 

Figure 7. TTI distributions across different device battery charge levels, as measured for a page loaded on P8 Lite (2015) smartphone.

 

To investigate whether there is any impact of battery-saver mode on the time when the user could first interact with the website, I used mPulse Continuity plugin that collects the time to interactive (TTI) metric. mPulse Continuity plugin calculates TTI based on whether the page was visually ready for the user and whether the page was ready for interaction. Specifically, the former is calculated by calculating the max of the time to first paint and the time to the domContentLoadedEventEnd event. Additionally, the continuity plugin can be configured to take into account the time to load specific resources that are critical for user interactions. These resources could be images or JavaScript libraries. Once the time to visually ready is calculated, the continuity plugin searches for the first time period of 500 milliseconds during which the browser UI/main thread was idle. The start of this time period marks the TTI for the page.

In Figure 7, I show the boxplot distributions for TTI values observed for loading a website on Huawei P8 Lite smartphone under different battery charge levels. From the figure we can observe that the TTI values inflate as soon as the battery charge levels drop below 10%. The sudden rise in TTI values indicates that users on this smartphone, and other similar smartphones, likely experience janks when interacting with the website, thus leading to poor user experience.

 

Measuring Frame Rate per Second

 

The new requestAnimationFrame API allows web developers to strategically schedule paint events on the screen with the goal of achieving a high frame rate during the website load. Typically, 60 frames per second (FPS) is considered ideal for good user experience, which means that the browser has exactly 16.6 milliseconds to produce a frame. However, if the browser needs to perform tasks that delay the frame generation, the FPS reduces. Note that a low frame rate can degrade the user experience because under low FPS, the page becomes unresponsive to user interactions. Therefore, I investigate whether or not the battery-saver mode impacts the frame rate observed across different page loads. Once again using the new mPulse Continuity plugin, I gathered the frame rate observed under various battery charge levels. Note that I show analysis of frame rates only for one of the devices for which I observe a sudden rise in both the PLT and TTFP.

 

Figure 8. FPS distributions across different device battery charge levels, as measured for a page loaded on P8 Lite (2015) smartphone.

 

As shown in Figure 8, the FPS observed on the 2015 model of Huawei P8 Lite drops as soon as the device battery charge levels drop below 10%. This indicates that for websites loading on this device, as the CPU performance degrades, the rate at which the browser paints on the screen also reduces - leading to a potentially poor user experience.

 

Impact of Battery-saver Mode on High-end Phones

 

In this section, I investigate whether the impact of battery-saver mode on website performance diminishes as the CPU clock speeds improve with the newer smartphone hardware. Specifically, I compare the website performance for pages loaded on various new and old Samsung flagship smartphones under different battery charge levels. Note that for the purposes of comparing performance across different Samsung devices, in Figure 9 I only show the PLT values calculated for the 50th percentile distribution. Additionally, note that for making the comparison easier to understand, In Figure 9, I also compare the performance observed for Huawei Y6 Elite smartphone for the same as the website used for Figure 1.

 

Figure 9. PLT distributions across different device battery charge levels, as measured for a page loaded on various Samsung smartphones and Huawei Y6 Elite.

 

Overall, from Figure 9 we can observe that the PLT decreases when the website is loaded on newer devices with high-performance CPU. For example, the PLTs on Note 8 are about 4 seconds, whereas the PLTs on Galaxy S6 are about 5.5 seconds. Similarly, PLTs on Galaxy S5 are about 6.5 seconds, and the PLTs on Y6 Elite under non-throttled CPU hardware are about 8 seconds. The performance differences across devices show that the website performance can be improved by upgrading the device hardware, regardless of the battery charge level.

Additionally, we can observe from the figure that PLTs on Note 8 do not inflate at any battery charge level. Since Samsung Note 8 does not provide a default user configurable option to enable the battery-saver mode when the battery charge level reaches a certain threshold and that users must turn the battery-saver mode on manually, perhaps most users tend to not activate the battery-saver mode, which is why we do not observe any inflation in PLTs. Alternatively, since Galaxy Note 8 has octa-core processors built-in, perhaps even if some users activate the battery-saver mode, the throttled CPU clock speed is high enough to not impact the PLT. However, I acknowledge that a better understanding of the inner workings of the device would help bear this out. For other devices, such as Galaxy S7 and S6, we do not observe any inflation in PLT regardless of the battery charge level. Similarly to Note 8, perhaps the throttled CPU clock speeds on these devices are high enough to not impact the PLT.

Although we do not see an inflation in PLT for Galaxy S5 in Figure 9, however, if we zoom in on its distribution, we do see that the PLTs rise when battery charge levels drop below 50%. This trend can be observed in Figure 10, where we see an upward slope starting from battery charge level 50%. At battery level 50%, the median PLT is 6.2 seconds, whereas at battery level 1%, the median PLT is 6.8 seconds.

 

Figure 10. PLT distributions across different device battery charge levels, as measured for a page loaded on Samsung Galaxy S5.

 

Given that Galaxy S5 does not provide an option for the user to set the threshold for when the battery-saver mode activates automatically, it is likely that users turn on the battery-saver mode at different battery charge levels. In fact, some users may not even have the mode turned on at all when loading websites. Therefore, it is likely that the cause of the upward slope is due to some users activating the battery-saver mode at different battery charge levels. Alternatively, it is possible that the device has a built-in system that linearly degrades the CPU performance as battery charge level drops.

 

Discussion

 

The web performance community has developed and evangelized numerous best practices for developers that could deliver high-performance experiences to end users. What remains open as a question to the community is what could we be doing to improve user experiences when web performance degrades due to reduced CPU clock speed when device battery charge levels drop below a certain threshold?

Below I briefly mention a few potential optimizations, but suggestions from others are welcomed:

 

  • For websites that make heavy use of JavaScript, when possible, developers could deliver websites with lighter JavaScript to minimize the use of throttled CPU in low-battery situations.
  • For websites with lots of third-party resources, when possible, developers could deliver websites with minimal or no third-party resources embedded, as these resources could inflate the page load times up to 50% and impact the user experience if some third-parties are unresponsive. Removal of third-party resources from websites could reduce the impact of lower CPU clock speeds on web performance.
  • If images are not optimized for best user experience, one could leverage an intelligent image generation system, such as Akamai’s Image Manager, that optimizes images based on the user’s device capabilities for both maximum visual quality and performance while reducing the cost and effort to transform images. Although we should always be using optimized images regardless of battery charge levels, if developers desire to not use lower resolution images on their websites, perhaps they could be delivering optimized images in at least low-battery situations.

 

 

Conclusion 

 

To conclude this article, below I highlight some of the key findings that I think are most important to web developers:

 

  • Some Android smartphones throttle the CPU clock speed when the device battery charge levels drop below a certain threshold. This threshold varies across devices. Under low-battery conditions, sudden rises in page load time, total LongTask time, and time to interactive can be observed on some devices.
  • The rise in page load time, LongTask time, and the time to interactive depends also on the mobile device in use. For example, CPU throttling on the latest phones, such as Samsung Note S8 and Galaxy S7 may not impact the website performance (when battery-saver modes are turned on), likely because the throttled CPU clock speed is high enough to not degrade the performance. Whereas, on other devices, such as select Huawei phones, Sony Xperia Z5 Compact, and Samsung Galaxy S5, page load time and the total LongTask time increases when CPU clock speeds are throttled.
  • The average frame rate on some Huawei smartphones could also reduce under battery-saver mode, leading to unresponsive websites.
  • The relative differences in website performance observed for battery charge levels lower and higher than the threshold value increases as the network performance improves. This trend suggests that as we improve the network performance, the device CPU becomes a bigger bottleneck to website performance when the device activates its battery-saver mode.
  • Finally, I discuss a few potential optimizations that developers could incorporate to improve web performance when device battery charge levels drop below a certain threshold.

 

 

Appendix

 

 

Battery-saver mode

 

The battery-saver mode, when activated, reduces the screen brightness, limits the use of Wi-Fi, disables power-consuming location-sharing services, and reduces the application background activity. Android smartphones, such as LG G5, Huawei Y6 Elite, Alcatel Pixi 4, and many others, provide two user-configurable options for the battery charge level threshold at which the battery-saver mode turns on automatically. These threshold values are 5% or 15%. However, other Android smartphones, such LG G3 and LG VS985, provide four user-configurable options for this threshold, which are 10%, 20%, 30%, and 50%. Similarly, Samsung phones, such as Galaxy S6, Galaxy J5, and others, also provide four user-configurable options for this threshold, which are 5%, 10%, 20%, and 50%. Note that even though there is an automated way to turn the battery-saver mode every time the battery charge level drops below a certain threshold, the activation of this feature on the device depends on users’ interest in saving battery charge.

Android smartphones, such as Samsung Galaxy S8, Note 8, and Galaxy S5, do not provide a way to set a threshold, which means that the activation and deactivation of the power-saving modes must be done manually by users every time they want to save power. The activation of the power-saving modes on these devices may even be lower compared to the devices that offer a threshold for automatically activating the power-saving mode.

Sony’s Xperia Z5 Compact has several power-saving modes, such as the Doze mode, that turn on automatically to save power when the device screen is turned off. Other power-saving modes, such as the Stamina mode, allow users to set a battery charge level threshold at which power-saving mode activates. Moreover, the power-saving mode on Sony Xperia Z5 Compact also allows users to decide whether or not the CPU clock speed should be throttled, in addition to or instead of disabling mobile data and Wi-Fi. As such, some users may choose to activate power-saving mode without throttling the CPU clock speed, while others may choose to throttle the CPU clock speed.

 

Data Collection Methodology

 

I utilized the website performance data collected via Akamai mPulse which embeds a lightweight Javascript code on some websites served by Akamai’s infrastructure to measure performance. mPulse uses the Web browser exposed Navigation Timing API to gather performance-related information as to how fast the website loaded on the user’s device. mPulse also utilizes the browser-exposed Battery Status API to associate the measured website performance data with the device’s battery charge level information at the time of measurement. The data I analyzed consists of a total of about 10 million page-load transactions for 480 unique websites loaded on 300 different smartphone models connected to 81 cellular ISPs in 39 countries. The time of the data collection spans from July 2017 through March 2018.

To investigate the web performance experienced on devices with low battery charge levels (and presumably, throttled CPU clock speeds), I calculate the median page load time (PLT) observed for beacons pertaining to 6-field buckets, comprised of:

 

  • the user’s country name in which the page was loaded
  • the user’s ISP over which the page was loaded
  • the URL of the website
  • the smartphone model used to load the website
  • the HTTP protocol version (HTTP/1.1 or HTTP/2) used to load the website
  • the device battery percentage, ranging from 1 to 100%.

 

In addition to calculating the median PLT for beacons in each bucket, I calculate the 10th, 25th, 75th, and 90th percentile PLT values. Note that I refer to the PLT as the time since the start of the page navigation until the trigger of the window.onLoad event. To offer a better understanding of the data, an example representation of data looks as follows:

Note that in the above table, the first five columns remain the same when looking at website performance across different battery charge levels. Bucketing the data with this approach helps to precisely understand how fast a given website loads on a given ISP network under specific constraints, such as the user’s country, user’s ISP, website URL, the smartphone, and the HTTP protocol, and thus mitigate the influence of many factors that might affect the analysis of web performance.

By calculating the 10th, 25th, 50th, 75th, and 90th percentile PLT values for each of the 6-field bucket, we could assume that the 10th percentile PLT tends to represent page loads in fast cellular networks, and that the 90th percentile PLT tends to represent page loads in slower cellular networks. This categorization would help us understand how the impact of battery-saver mode changes as we improve or degrade network performance.

Finally, similarly to how I calculate PLT distributions, I also calculate the time to first paint observed for loading different websites on different smartphones. Additionally, for my investigation, I collect the total LongTask time, the time to interactive, and the frame rate observed when loading websites under various battery charge levels. Note that since LongTask, time to interactive, and the frame rate metrics depend on the device hardware, as opposed to the network performance, for these metrics I do not calculate 10th, 25th, 50th, 75th, and 90th percentile values but instead plot the whole distributions in appropriate figures.

Note that the dataset I prepared consists of 25 unique combinations (comprising of country, ISP, URL, Smartphone name, and HTTP protocol) for which mPulse library was executed on at least 100 page loads for each of the battery charge levels ranging from 1% to 100% - a total of at least 10000 beacons for each combination. Additionally, the dataset consists of 63 unique combinations for which mPulse library was executed on at least 100 page-load transactions, for at least 90 battery charge levels  - a total of at least 9000 beacons for each combination. The low number of combinations observed in my dataset is perhaps a consequence of the fact that only about 2.5% of the total page loads occurred when battery charge levels were below 15%, which yielded less than 100 beacons for some battery charge levels on some combinations. Additionally, the low number of page loads under battery charge levels less than 15% may suggest that either most users keep their phones charged over 15% at all times or that when battery charge levels drop below 15%, users’ web browsing activities reduce significantly likely in favor of conserving battery charge.

 

About the Author

 

Utkarsh Goel is an architect in Akamai's Web Performance business unit who likes to build unilateral technologies to improve the current state of web performance. He is a member of Akamai's Foundry, the cutting-edge arm for applied R&D that believes in the “fail fast, succeed faster” philosophy and focuses on exploring new technology opportunities to improve all forms of Internet performance.

Thanks to Akamai’s Stephen Ludin and Moritz Steiner and for brainstorming some research ideas and providing feedback on an early version of this article.