Web Performance with Android's Battery-Saver Mode
WWeb Performance with Android’s Battery-Saver Mode
Utkarsh Goel
Akamai Technologies, [email protected]
Stephen Ludin
Akamai Technologies, [email protected]
Moritz Steiner
Akamai Technologies, [email protected]
ABSTRACT
A Web browser utilizes a device’s CPU to parse HTML,build a Document Object Model, a Cascading Style SheetsObject Model, and render trees, and parse, compile, andexecute computationally-heavy JavaScript. A powerful CPUis required to perform these tasks as quickly as possible andprovide the user with a great experience. However, increasedCPU performance comes with increased power consumptionand reduced battery life on mobile devices. As an optionto extend battery life, Android offers a battery-saver modethat when activated, turns off the power-hungry and fasterprocessor cores and turns on the battery-conserving andslower processor cores on the device. The transition fromusing faster processor cores to using slower processor coresthrottles the CPU clock speed on the device, and thereforeimpacts the webpage load process.We utilize a large-scale data-set collected by a real usermonitoring system of a major content delivery networkto investigate the impact of Android’s battery-saver modeon various mobile Web performance metrics. Our analysissuggests that users of select smartphones of Huawei andSony experience a sudden or gradual degradation in Webperformance when battery-saver mode is active. Battery-saver mode on newer flagship smartphones, however,does not impact the mobile Web performance. Finally, weencourage for new website design goals that treat slow (andthrottled-CPU) devices kindly in favor of improvingend-user experience and suggest that Web performancemeasurements should be aware of user device battery chargelevels to correctly associate Web performance.
In the last several years, mobile websites have growndrastically in both complexity and size [32, 33]. This growthhas led to slower page loads and higher user frustration withthe website [3]. As websites continue to grow in complexity,the key to improve website responsiveness is to build fasternetworks, optimize website content, and produce mobiledevices with faster CPUs. While many networks havealready begun to deploy new infrastructure and supportfaster communication protocols [28, 34, 38, 43], and mostwebsites already employ a suite of website optimizationtechniques [35], the mobile device CPU remains a limiting factor to mobile Web performance [50]. Unlike desktop andlaptop CPUs, Mobile CPUs are designed for power efficiency.More specifically, Android smartphones have a battery-saver mode that lowers the battery consumption when thecharge level drops below a certain threshold. Among otherthings, the battery-saver mode reduces the device’s perfor-mance by throttling the CPU clock speed, where it deac-tivates the power-hungry and faster processor cores andactivates the battery-saving and slower processor cores [36].The process of loading Web pages includes HTML parsing,downloading and processing of JavaScript, Cascading StyleSheets (CSS), image resources, executing computationally-heavy JavaScript, and building the Document Object Model(DOM), CSS Object Model (CSSOM), and render tree [37].Since all these tasks make use of the device’s CPU resources,in this paper we seek to investigate whether or not a throt-tled CPU clock speed under an active battery-saver mode de-grades the mobile Web performance for the end-user. Simplyput, do mobile websites load slower on Android phones whenthe battery charge levels drop below a certain threshold?Since the impact of battery-saver mode on mobile Webperformance has not garnered much developer interest in thepast, our goal with this paper is to bring awareness to the de-veloper community about potential performance impacts andthus motivate the need for new website design goals and de-cisions that treat mobile devices differently, especially whenbattery-saver modes are active and the CPU clock speeds arethrottled. We make the following contributions in the paper:
Dataset Richness : To investigate the impact of batterysaver modes on mobile Web performance, we utilized alarge-scale Web performance dataset collected by AkamaimPulse for websites loaded by real users on various mobiledevices [13]. Our dataset contains various Web performancemetrics collected for 10 million pages, loaded on 300 differ-ent smartphone models, connected to 81 cellular ISPs in 39countries, from July 2017 to March 2018.
Inferences Drawn:
Using a large-scale mobile Web perfor-mance dataset, we discover that under battery-saver mode,select phones from Huawei, Sony Xperia, and SamsungGalaxy series degrade mobile Web performance metrics, suchas the page load time (PLT), time to first paint (TTFP), totalLongTask time, time to interactive (TTI), and frame rate [2,6, 19, 27]. The data also suggest that the battery-saver modemakes a higher impact on Web performance when Web pages a r X i v : . [ c s . PF ] M a r oad in faster mobile network conditions. The above findingsdemonstrate a clear need for new website design goals thatwould go hand-in-hand with the understanding of how userdevices with low battery charge levels could degrade themobile Web experience. Specifically, developers might wantto build websites that adapt to different battery situations toovercome any user-perceived responsiveness issues inflictedby the battery-saver mode. Additionally, to reduce utilizationof the throttled CPU, users may use browsers that offloadCPU-intensive computations to the cloud [25, 29, 30].The rest of the paper is organized as follows. Section 2gives a background on Android’s battery-saver modes. InSections 3 and 4, we discuss our data collection methodologyand the impact of battery-saver mode on various Webperformance metrics. In Section 5, we discuss the relatedwork. Finally, we conclude in Section 6. The battery-saver mode, when activated, reduces the screenbrightness, limits the use of WiFi, disables power-consuminglocation-sharing services, and reduces the applicationbackground activity. Android smartphones, such as LGG5, Huawei Y6 Elite, Alcatel Pixi 4, and many others,provide two user-configurable options for the battery chargelevel threshold at which the battery-saver mode turns onautomatically [15, 16, 18, 47]. These threshold values are 5%and 15%. However, other Android smartphones, such LGG3 and LG VS985, provide four user-configurable optionsfor this threshold, which are 10%, 20%, 30%, and 50% [31].Similarly, Samsung phones, such as Galaxy S6, Galaxy J5,and others, also provide four user-configurable options forthis threshold, which are 5%, 10%, 20%, and 50% [10, 20]. Notethat even though there is an automated way to turn on thebattery-saver mode every time the battery charge level dropsbelow a certain threshold, the activation of this feature on thedevice depends on a user’s interest in saving battery charge.Other smartphones, such as Samsung Galaxy S8, Note8, and Galaxy S5, do not provide a way to set a threshold,which means that the activation and deactivation of thepower-saving modes must be done manually by users everytime they want to save power [12, 17]. The activation ofthe power-saving modes on these devices may even belower compared to the devices that offer a threshold forautomatically activating the power-saving mode.Sony’s Xperia Z5 Compact has several power-savingmodes, such as the Doze mode, that turns on automaticallyto save power when the device screen is turned off [14].Other power-saving modes, such as the Stamina mode,allow users to set a battery charge level threshold at whichpower-saving mode activates. Moreover, the power-savingmode on Sony Xperia Z5 Compact also allows users to decide whether or not the CPU clock speed should bethrottled, in addition to, or instead of, disabling mobile dataand WiFi [22]. As such, some users may choose to activatepower-saving mode without throttling the CPU clock speed,while others may choose to throttle the CPU clock speed.
To analyze the different performance metrics pertaining towebsites loaded on various real user smartphones, we utilizedthe data collected by Akamai’s mPulse product [13]. mPulseembeds a lightweight JavaScript snippet to some HTML re-sponses and leverages the Web browser-exposed NavigationTiming API to collect performance-related information toestimate the time taken to load a page [2]. mPulse also uti-lizes the browser exposed Battery Status API to associate themeasured website performance data with the device’s batterycharge level information at the time of measurement [5]. Thecollected data is reported back to Akamai servers [44], whichwe analyze to assess the impact of battery saver modes onpage load performance. Our data consists of a total of 10 mil-lion page load transactions for 480 unique websites loadedon 300 different smartphone models connected to 81 cellularISPs in 39 countries from July 2017 through March 2018.To investigate the Web performance experienced ondevices with low battery charge levels, we calculate themedian page load time (PLT) observed for page loadspertaining to 6-field buckets, comprised of: 1) the countryname in which the page was loaded, 2) the ISP over whichthe page was loaded (note that the first two pieces ofinformation are deduced from the MaxMind’s databaseof mapping IP addresses to geographical locations [40]),3) the URL of the website loaded, 4) the smartphone modelused to load the website, 5) the HTTP protocol version(HTTP/1.1 or HTTP/2) used, and 6) the device batterypercentage, ranging from 1 to 100%. Note that we refer toPLT as the time from the start of page navigation until the loadEventStart event is triggered by the Web browser [2].Also note that bucketing the data with this approach helpsto precisely understand how fast a given website loads ona given ISP network under specific constraints, such as theuser’s country, user’s ISP, website URL, the smartphone, andthe HTTP protocol, and thus mitigate the influence of manyfactors that might affect the analysis of Web performance.In addition to calculating the median PLT for beaconsin each bucket, we calculate the 10 th , 25 th , 75 th , and 90 th percentile PLT values. By calculating these percentile valuesfor each of the 6-field bucket, we could assume that the10 th percentile PLT tends to represent page loads in fastcellular networks, and that the 90 th percentile PLT tendsto represent page loads in slower cellular networks. Thiscategorization would help us understand how the impactf battery-saver mode changes as network performanceimproves or degrades.Finally, similarly to how we calculate PLT distributions,we also calculate the TTFP observed for loading differentwebsites on different smartphones. Additionally, we collectthe total LongTask time, the time to interactive, and theframe rate observed when loading websites under variousbattery charge levels. Note that since the LongTask, timeto interactive, and frame rate metrics depend on the devicehardware, as opposed to the network performance, for thesemetrics we do not calculate 10 th , 25 th , 50 th , 75th, and 90 th percentile values (because we represent percentile valuesas network speed) but instead plot the whole distributionsin appropriate figures.Note that the dataset we prepared consists of 25 uniquecombinations (comprising of country, ISP, URL, smartphonename, and HTTP protocol) for which mPulse library was exe-cuted on at least 100 page loads for each of the battery chargelevels ranging from 1% to 100% - a total of at least 10,000 bea-cons for each combination. Additionally, the dataset consistsof 63 unique combinations for which mPulse library was ex-ecuted on at least 100 page-load transactions, for at least 90battery charge levels - a total of at least 9,000 beacons for eachcombination. The low number of combinations observed inthe dataset is a consequence of the fact that only about 2.5%of the total page loads occurred when battery charge lev-els were below 15%, which yielded less than 100 beaconsfor some battery charge levels on some combinations. Addi-tionally, the low number of page loads under battery chargelevels less than 15% may suggest that either most users keeptheir phones charged over 15% at all times or that when bat-tery charge levels drop below 15%, users reduce their Webbrowsing activities in favor of conserving battery charge. To estimate the performance of a website, we analyze sev-eral Web performance metrics under different device batterycharge levels, such as PLT and TTFP – the time since the startof the page navigation until the browser paints the first pixels.We also analyze the total LongTask time – the time duringwhich the browser main/UI thread is blocked and therefore,the user cannot interact with the page [24]. Finally, we mea-sure the average rate of printing frames on the screen [27].
In Figure 1, we showvarious percentile PLT values for a page loaded on HuaweiY6 Elite smartphone. From the figure we can observe thatacross all percentiles, the PLT inflates as soon as the batterycharge level drops to 15%, likely due to degraded CPU clockspeeds triggered by the battery-saver mode. The figure also Battery Level (%) P L T ( m s ) p10 p25 p50 p75 p90 Figure 1: PLT distributions across different device bat-tery charge levels, as measured for a page loaded onHuawei Y6 Elite mobile device.Table 1: Summary of PLT distributions on Huawei Y6Elite phone. suggests that, on most Huawei Y6 Elite smartphones, thedefault threshold for when the battery-saver mode initiatesis set to 15%.In the Table 1, we summarize the analysis from Figure 1to compare the PLT observed when battery charge levelsare, for example, 8% and 50%. Note that the battery chargelevels 8% and 50% are just two example representative pointsfor comparing the performance under the battery-saver andnormal modes.From the table we can observe that the relative differencein the page load decreases as the network performancedegrades. Specifically, among the two battery levels, 8% and50%, for page loads represented by the 10 th percentile distri-bution (p10), the PLTs at 8% are higher by 28% compared tothe PLTs at 50%. Whereas, for the 90 th percentile distribution(p90), the PLTs at 8% are higher by 15% compared to thePLTs at 50%. This downward trend suggests that whenwebsites are loaded on faster networks, the smartphone’sCPU becomes a more significant bottleneck for websiteperformance. Indeed this trend is similar to a previousresearch study that investigates how device performanceimpacts Web performance [50]. Battery Level (%) P L T ( m s ) p10 p25 p50 p75 Figure 2: PLT distributions across different device bat-tery charge levels, as measured for a page loaded onHuawei P8 Lite (2015) mobile device.Figure 3: Summary of PLT distributions onHuawei P8 Lite phone.
Both PLT and TTFP metrics make direct impact on theuser experience. As such, an increase in these metrics, dueto degraded CPU clock speeds, represents a degradation inthe user experience.
Similarlyto Figure 1, as shown in Figure 2, we observe a suddeninflation in PLTs when loading a Web page on the 2015model of Huawei P8 Lite smartphone. Since the inflationoccurs when the battery charge level is at 10%, it appears thatthe battery-saver mode on the Huawei P8 Lite smartphoneturns on for most users at 10%.Additionally, as shown in Table 3, when we compare therelative PLT differences across different distributions, wecan observe that the impact of throttled CPU clock speedson PLT appears to be more significant when pages areloaded in fast network conditions.We observed similar trends in performance for other web-sites that loaded on Huawei P8 Lite smartphone, however,we do not show them due to page limits. Additionally, notethat for websites loaded on the 2017 model of Huawei P8 Litesmartphone, we did not observe sudden inflation in PLT orTTFP metrics at any battery charge level, potentially becausethe 2017 model has a faster CPU that does not impact thepage load despite the drop in CPU performance [8]. Finally,we noticed that newer smartphones from the same family, Battery Level (%) P L T ( m s ) p10 p25 p50 p75 p90 Figure 4: Page load time distributions across differentdevice battery charge levels, as measured for a pageloaded on Sony Xperia Z5 Compact mobile device. such as Huawei P9 Lite and P10 Lite, also do not degradewebsite performance under low battery charge levels.
In Figure 4we show that when pages load on Sony Xperia Z5 Compactsmartphone, there exists an upward slope indicating thatpage load times continue to rise as battery charge levelsdrop below 40%. We have not been able to identify the causefor such an upward slope, as opposed to a sudden increasedin page load time, even though this device allows users toset a threshold at which the battery-saver mode activates.Perhaps, this device has a linear slowdown in the CPU clockspeed when the battery charge levels reach 40%. Note that wedid not observe such a strong upward slope for other Sonydevices, such as Xperia X Compact, Xperia X Performance,and Xperia XZ and in fact, there was no inflation in PLT forthese devices under low battery charge levels.
We compare thewebsite performance for pages loaded on various new andold Samsung flagship smartphones under different batterycharge levels. Note that for the purposes of comparingperformance across different Samsung devices, in Figure 5we only show the PLT values calculated for the 50 th percentile distribution at various battery charge levels.Additionally, note that for making the comparison easierto understand, in Figure 5, we compare the performanceobserved for Huawei Y6 Elite smartphone for the samewebsite as the one used in Figure 1.From Figure 5, we observe that when the website isloaded on newer devices with high-performance CPU, thePLT gets lower across all battery charge levels. For example,the PLTs on Note 8 are about 4 seconds, whereas the PLTson Galaxy S6 are about 5.5 seconds. Similarly, PLTs onGalaxy S5 are about 6.5 seconds, and the PLTs on Y6 Eliteunder non-throttled CPU hardware are about 8 seconds.The performance differences across devices show that the Battery Level (%) P L T ( m s ) Note 8
Galaxy S7
Galaxy S6
Galaxy S5
Y6 Elite
Figure 5: PLT distributions across different device bat-tery charge levels, as measured for a page loaded onvarious Samsung smartphones and Huawei Y6 Elite. Battery Level (%)
TTF P ( m s ) p10 p25 p50 p75 p90 Figure 6: TTFP distributions across different devicebattery charge levels, as measured for a page loadedon Huawei Y6 Elite mobile device. website performance can be improved by upgrading thedevice hardware, regardless of the battery charge level.Additionally, from Figure 5 we observe that PLTs onNote 8 do not experience sudden or gradual increase at anybattery charge level. Since Samsung Note 8 does not providea default user configurable option to enable the battery-savermode when the battery charge level reaches a certain thresh-old and that users must manually activate the battery-savermode, perhaps most users tend to not activate the battery-saver mode and therefore we do not observe any inflation inPLTs. Alternatively, since Galaxy Note 8 has octa-core pro-cessors built-in, perhaps even when the battery-saver modeis active, the throttled CPU clock speed is high enough tonot negatively impact the page load process or the PLT [11].However, we acknowledge that a better understanding of theinner workings of the device would help bear this out. Forother devices, such as Galaxy S7 and S6, we do not observeany inflation in PLT regardless of the battery charge level.Similarly to Note 8, perhaps the throttled CPU clock speedson these devices are high enough to not impact the PLT.
Battery Level (%) T o t a l Long T a sk T i m e ( m s ) Figure 7: LongTask time distributions across differentdevice battery charge levels, as measured for a pageloaded on P8 Lite (2015) smartphone.
In Figure 6, we show various percentile TTFP values forthe same page as Figure 1, when loaded on Huawei Y6 Elitesmartphone. From the figure we can observe that thereexists a sudden inflation in the TTFP when the batterycharge levels drop below 15%. This trend suggests that thetime when the browser paints the first pixels also increaseswhen the device enables the battery-saver mode. Similarlyto Figure 1, we also noticed sudden inflation in TTFP atbattery charge level 15%, when loading websites on the 2015model of Huawei P8 Lite smartphone.
LongTask is a relatively new Web performance measure-ment API that allows identification of resources that makewebsites unresponsive to user interactions [19]. Morespecifically, Web developers could use the LongTask API todetect the presence of tasks that block the browser UI/mainthread for at least 50 milliseconds. When a website loadsresources that block the browser UI/main thread, the useris unable to interact with the page. Specifically, a long taskprevents the page from responding to user actions, suchas scroll, click, tap, key, wheel, etc, until the long task hasfinished executing. This is because when a long task isexecuting, all user actions are queued behind the long task.Poorly designed JavaScript code is one example of whatmight cause a browser main thread to block for over50ms [46]. Since the current LongTask API (v1) does notreveal the URL of the long task (though the second versionof the API will provide such detail, including the linenumber that caused the long task [45]), it is unclear as towhat particular resources block the browser main thread.Therefore, we only focus on investigating whether or notwe observe a rise in the total LongTask time when deviceCPU clock speed reduces when battery charge levels dropbelow a certain threshold, as opposed to discussing the root
Battery Level (%) TT I ( m s ) Figure 8: TTI distributions across different device bat-tery charge levels, as measured for a page loaded onP8 Lite (2015) smartphone. cause of a large or small total LongTask time. Also notethat since LongTask time, time to interactive, and the framerate metrics do not depend on network speed and insteaddepend on the device CPU performance, we use boxplotdistributions in Figures 7-9 instead of plotting differentpercentile values as we did for previous graphs.In Figure 7, we show the boxplot distributions of thetotal LongTask time across different battery charge levelswhen loading a website on the 2015 model of the HuaweiP8 Lite smartphone. From the figure we can observe thatthe total LongTask time inflates when device battery chargelevel drops below 10%. The rise in the total LongTask timeindicates that when the device CPU clock speed is throttledto minimize battery consumption, LongTasks block themain thread for longer than usual time. Note that we didnot observe inflation in the total LongTask time on the2017 model of Huawei P8 Lite smartphone, likely due to thefact that faster processors on the device do not impact thetotal LongTask time when their speeds are throttled by thebattery-saver mode.
Not only does a LongTask delay user interactions, butevents callbacks (such as onLoad) are also delayed. In manypages where many LongTask exists as the page loads, thetime at which the user could first interact with the pagecould also get delayed. Additionally, note that even thoughLongTask is the prime cause for poor responsiveness to userinteractions, other tasks, such as image decoding, heavyrasterization work, or presence of many layers on the pagecan also cause poor responsiveness [39].To investigate whether there is any impact of battery-saver mode on the time when the user could first interactwith the website, we take a look at the time to interactive(TTI) metric. The TTI metric is calculated based on whenthe page was visually ready for the user and when the page Battery Level (%) F r a m e R a t e ( F PS ) Figure 9: FPS distributions across different device bat-tery charge levels, as measured for a page loaded onP8 Lite (2015) smartphone. was ready for interaction [6]. Specifically, the former iscalculated by calculating the maximum of time to first paintand time to domContentLoadedEventEnd event [21]. Oncethe time to visually ready is calculated, the first time periodof 500 milliseconds during which the browser UI/mainthread was idle marks the TTI for the page.In Figure 8, we show the boxplot distributions for TTIvalues observed for loading a website on Huawei P8 Litesmartphone under different battery charge levels. From thefigure we can observe that the TTI values inflate as soon asthe battery charge levels drop below 10%. The sudden rise inTTI values indicates that users on this smartphone, and othersimilar smartphones, likely experience janks when interact-ing with the website, thus leading to poor user experience.
The new requestAnimationFrame
API allows Web develop-ers to strategically schedule paint events on the screen withthe goal of achieving a high frame rate during the websiteload [26]. Typically, 60 frames per second (FPS) is consid-ered ideal for good user experience, which means that thebrowser has exactly 16.6 ms to produce a frame. However,if the browser needs to perform tasks that delay the framegeneration, the FPS declines. Note that a low frame rate candegrade the user experience, because under low FPS the pagebecomes unresponsive to user interactions. Therefore, weinvestigate whether or not the battery-saver mode impactsthe frame rate observed across different page loads. Usingthe mPulse Continuity plugin we gathered the frame rate ob-served under various battery charge levels [6]. Note that weshow analysis of frame rates only for one of the devices forwhich we observe a sudden rise in both the PLT and TTFP.As shown in Figure 9, the FPS observed on the 2015 modelof Huawei P8 Lite drops as soon as the device battery chargelevels drop below 10%. This indicates that for websitesloading on this device, as the CPU performance degrades,he rate at which the browser paints on the screen alsodeclines - leading to a potentially poor user experience.
Several tools and studies have relied on active measurementsto identify Web performance bottlenecks [1, 7, 23, 51]. Unlikepassive measurements via real user monitoring systems [9,13], active measurement practices inherit several limitationsbecause pages loaded in controlled environments do notrepresent the characteristics of how pages load in the realworld [41]. Steiner et al. used a real user monitoring system tocompare the impact of CPU processors embedded in old andnew smartphones on the web performance – suggesting thatpage loads on new devices with fast CPUs are significantlyfaster than page loads on old devices with slow CPU [50].Like other studies [42], the authors observed that faster CPUson newer smartphones load webpages faster than those onold phones. Another study reveals that about 35% of the PLTis spent performing CPU-intensive tasks on user devices [51].
Slow mobile device hardware is a bottleneck to mobile Webperformance. We perform a large-scale measurement studyto identify the impact of Android’s battery-saver (whichthrottles the CPU clock speed) mode on mobile Web perfor-mance. Our data suggests that under low-battery conditions,sudden rises in page load time, total LongTask time, andtime to interactive metrics are observed on some devices.The average frame rate on some smartphones also declines,leading to unresponsive and paint-blocked websites.Through this paper we hope we motivate the needfor new website design goals that improve mobile Webexperience for slow mobile devices. The Web performancecommunity has developed numerous best practices fordevelopers to deliver high-performance experiences to endusers [4, 25, 29, 30, 35, 48, 49].
DISCLOSURE
The positions, strategies, or opinions reflected in this articleare those of the authors and do not necessarily represent thepositions, strategies, or opinions of Akamai.
REFERENCES
ACM MobiCom , Oct.2016.[35] I. Grigorik.
High Performance Browser Networking
ACM Queue, Volume 11,issue 2 , Mar. 2013. [42] A. Nikravesh, H. Yao, S. Xu, D. Choffnes, and Z. M. Mao. Mobilyzer:An Open Platform for Controllable Mobile Network Measurements.In
ACM MobiSys , May 2015.[43] E. Nygren. Three years since World IPv6 Launch: strongIPv6 growth continues. https://blogs.akamai.com/2015/06/three-years-since-world-ipv6-launch-strong-ipv6-growth-continues.html, Jun. 2015.[44] E. Nygren, R. K. Sitaraman, and J. Sun. The Akamai Network: APlatform for High-performance Internet Applications.
SIGOPS Oper.Syst. Rev.
High Performance Web Sites: Essential Knowledge for Front-End Engineers . O’Reilly Media, Inc., Dec. 2008.[49] S. Souders.
Even Faster Web Sites: Performance Best Practices for WebDevelopers . O’Reilly Media, Inc., Jun. 2009.[50] M. Steiner and R. Gao. What slows you down? Your network or yourdevice? In arXiv:1603.02293 , Mar. 2016.[51] X. S. Wang, A. Balasubramanian, A. Krishnamurthy, and D. Wetherall.Demystifying Page Load Performance with WProf. In