In the last several years, mobile websites have grown drastically in both complexity and size (Everts, 2013, 2017). This growth has led to slower page loads and higher user frustration with the website (33). As websites continue to grow in complexity, the key to improve website responsiveness is to build faster networks, optimize website content, and produce mobile devices with faster CPUs. While many networks have already begun to deploy new infrastructure and support faster communication protocols (Belshe et al., 2015; Goel et al., 2016; Iyengar and Thomson, 2018; Nygren, 2015), and most websites already employ a suite of website optimization techniques (Grigorik, 2013), the mobile device CPU remains a limiting factor to mobile Web performance (Steiner and Gao, 2016). Unlike desktop and laptop CPUs, Mobile CPUs are designed for power efficiency.
Since the impact of battery-saver mode on mobile Web performance has not garnered much developer interest in the past, our goal with this paper is to bring awareness to the developer community about potential performance impacts and thus motivate the need for new website design goals and decisions that treat mobile devices differently, especially when battery-saver modes are active and the CPU clock speeds are throttled. We make the following contributions in the paper:
Dataset Richness: To investigate the impact of battery saver modes on mobile Web performance, we utilized a large-scale Web performance dataset collected by Akamai mPulse for websites loaded by real users on various mobile devices (22). Our dataset contains various Web performance metrics collected for 10 million pages, loaded on 300 different smartphone models, connected to 81 cellular ISPs in 39 countries, from July 2017 to March 2018.
Inferences Drawn: Using a large-scale mobile Web performance dataset, we discover 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 (PLT), time to first paint (TTFP), total LongTask time, time to interactive (TTI), and frame rate (35; 5; 30; 2). The data also suggest that the battery-saver mode makes a higher impact on Web performance when Web pages load in faster mobile network conditions. The above findings demonstrate a clear need for new website design goals that would go hand-in-hand with the understanding of how user devices with low battery charge levels could degrade the mobile Web experience. Specifically, developers might want to build websites that adapt to different battery situations to overcome any user-perceived responsiveness issues inflicted by the battery-saver mode. Additionally, to reduce utilization of the throttled CPU, users may use browsers that offload CPU-intensive computations to the cloud (50; 6; 8).
The rest of the paper is organized as follows. Section 2 gives a background on Android’s battery-saver modes. In Sections 3 and 4, we discuss our data collection methodology and the impact of battery-saver mode on various Web performance metrics. In Section 5, we discuss the related work. Finally, we conclude in Section 6.
The battery-saver mode, when activated, reduces the screen brightness, limits the use of WiFi, 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 (24; 25; 29; 42). These threshold values are 5% and 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% (Devine, 2014). 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% (14; 34). Note that even though there is an automated way to turn on 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 a user’s interest in saving battery charge.
Other 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 (21; 26). 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 turns on automatically to save power when the device screen is turned off (23). 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 WiFi (43). 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.
3. Data Collection Methodology
To analyze the different performance metrics pertaining to websites loaded on various real user smartphones, we utilized the data collected by Akamai’s mPulse product (22)
To investigate the Web performance experienced on devices with low battery charge levels, we calculate the median page load time (PLT) observed for page loads pertaining to 6-field buckets, comprised of: 1) the country name in which the page was loaded, 2) the ISP over which the page was loaded (note that the first two pieces of information are deduced from the MaxMind’s database of mapping IP addresses to geographical locations (MaxMind, 2018)), 3) the URL of the website loaded, 4) the smartphone model used to load the website, 5) the HTTP protocol version (HTTP/1.1 or HTTP/2) used, and 6) the device battery percentage, ranging from 1 to 100%. Note that we refer to PLT as the time from the start of page navigation until the loadEventStart event is triggered by the Web browser (35). Also note that 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.
In addition to calculating the median PLT for beacons in each bucket, we calculate the 10th, 25th, 75th, and 90th percentile PLT values. By calculating these percentile 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 network performance improves or degrades.
Finally, similarly to how we calculate PLT distributions, we also calculate the TTFP observed for loading different websites on different smartphones. Additionally, we 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 the LongTask, time to interactive, and frame rate metrics depend on the device hardware, as opposed to the network performance, for these metrics we do not calculate 10th, 25th, 50th, 75th, and 90th percentile values (because we represent percentile values as network speed) but instead plot the whole distributions in appropriate figures.
Note that the dataset we 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 10,000 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 9,000 beacons for each combination. The low number of combinations observed in the dataset is 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 reduce their Web browsing activities in favor of conserving battery charge.
4. Measuring Website Performance
To estimate the performance of a website, we analyze several Web performance metrics under different device battery charge levels, such as PLT and TTFP – the time since the start of the page navigation until the browser paints the first pixels. We also analyze the total LongTask time – the time during which the browser main/UI thread is blocked and therefore, the user cannot interact with the page (48). Finally, we measure the average rate of printing frames on the screen (Basques, 2018).
4.1. Measuring Page Load Time (PLT)
4.1.1. Performance on Huawei Y6 Elite
In Figure 1, we show various percentile PLT values for a page loaded on Huawei Y6 Elite smartphone. From the figure we can observe that across all percentiles, 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%.
In the Table 1, we 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 when websites are loaded 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 that investigates how device performance impacts Web performance (Steiner and Gao, 2016).
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.
4.1.2. Performance on Huawei P8 Lite (2015 model)
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%.
Additionally, as shown in Table 3, 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.
We observed similar trends in performance for other websites that loaded on Huawei P8 Lite smartphone, however, we do not show them due to page limits. Additionally, note that for websites loaded on the 2017 model of Huawei P8 Lite smartphone, we did not observe sudden inflation in PLT or TTFP metrics at any battery charge level, potentially because the 2017 model has a faster CPU that does not impact the page load despite the drop in CPU performance (9). Finally, we noticed that 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.
4.1.3. Performance on Sony Xperia Z5 Compact
In Figure 4 we show that when pages load on Sony Xperia Z5 Compact smartphone, there exists an upward slope indicating that page load times continue to rise as battery charge levels drop below 40%. We have not been able to identify the cause for such an upward slope, as opposed to a sudden increased in page load time, even though this device allows users to set a threshold at which the battery-saver mode activates. Perhaps, this device has a linear slowdown in the CPU clock speed when the battery charge levels reach 40%. Note that we did not observe such a strong upward slope for other Sony devices, such as Xperia X Compact, Xperia X Performance, and Xperia XZ and in fact, there was no inflation in PLT for these devices under low battery charge levels.
4.1.4. Performance on High-end Phones
We 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 5 we only show the PLT values calculated for the 50th percentile distribution at various battery charge levels. Additionally, note that for making the comparison easier to understand, in Figure 5, we compare the performance observed for Huawei Y6 Elite smartphone for the same website as the one used in Figure 1.
From Figure 5, we observe that when the website is loaded on newer devices with high-performance CPU, the PLT gets lower across all battery charge levels. 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, from Figure 5 we observe that PLTs on Note 8 do not experience sudden or gradual increase 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 manually activate the battery-saver mode, perhaps most users tend to not activate the battery-saver mode and therefore we do not observe any inflation in PLTs. Alternatively, since Galaxy Note 8 has octa-core processors built-in, perhaps even when the battery-saver mode is active, the throttled CPU clock speed is high enough to not negatively impact the page load process or the PLT (15). However, we 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.
4.2. Measuring TTFP
In Figure 6, we show various percentile 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. Similarly to Figure 1, we also noticed sudden inflation in TTFP at battery charge level 15%, when loading websites on the 2015 model of Huawei P8 Lite smartphone.
4.3. Measuring LongTask Time
LongTask is a relatively new Web performance measurement API that allows identification of resources that make websites unresponsive to user interactions (30). 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 long task prevents the page from responding to user actions, such as scroll, click, tap, key, wheel, etc, until the long task has finished executing. This is because when a long task is executing, all user actions are queued behind the long task.
In Figure 7, we 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 we 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.
4.4. Measuring Time to Interactive (TTI)
Not only does a LongTask delay user interactions, but events callbacks (such as onLoad) 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 many layers on the page can also cause poor responsiveness (K., 2016).
To investigate whether there is any impact of battery-saver mode on the time when the user could first interact with the website, we take a look at the time to interactive (TTI) metric. The TTI metric is calculated based on when the page was visually ready for the user and when the page was ready for interaction (5). Specifically, the former is calculated by calculating the maximum of time to first paint and time to domContentLoadedEventEnd event (41). Once the time to visually ready is calculated, the first time period of 500 milliseconds during which the browser UI/main thread was idle marks the TTI for the page.
In Figure 8, we 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.
4.5. 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 (51). Typically, 60 frames per second (FPS) is considered ideal for good user experience, which means that the browser has exactly 16.6 ms to produce a frame. However, if the browser needs to perform tasks that delay the frame generation, the FPS declines. Note that a low frame rate can degrade the user experience, because under low FPS the page becomes unresponsive to user interactions. Therefore, we investigate whether or not the battery-saver mode impacts the frame rate observed across different page loads. Using the mPulse Continuity plugin we gathered the frame rate observed under various battery charge levels (5). Note that we show analysis of frame rates only for one of the devices for which we observe a sudden rise in both the PLT and TTFP.
As shown in Figure 9, 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 declines - leading to a potentially poor user experience.
5. Related Work
Several tools and studies have relied on active measurements to identify Web performance bottlenecks (17; 7; 47; 49). Unlike passive measurements via real user monitoring systems (11; 22), active measurement practices inherit several limitations because pages loaded in controlled environments do not represent the characteristics of how pages load in the real world (Meenan, 2013). Steiner et al. used a real user monitoring system to compare the impact of CPU processors embedded in old and new smartphones on the web performance – suggesting that page loads on new devices with fast CPUs are significantly faster than page loads on old devices with slow CPU (Steiner and Gao, 2016). Like other studies (Nikravesh et al., 2015), the authors observed that faster CPUs on newer smartphones load webpages faster than those on old phones. Another study reveals that about 35% of the PLT is spent performing CPU-intensive tasks on user devices (Wang et al., 2013).
6. Discussion and Conclusion
Slow mobile device hardware is a bottleneck to mobile Web performance. We perform a large-scale measurement study to identify the impact of Android’s battery-saver (which throttles the CPU clock speed) mode on mobile Web performance. Our data suggests that under low-battery conditions, sudden rises in page load time, total LongTask time, and time to interactive metrics are observed on some devices. The average frame rate on some smartphones also declines, leading to unresponsive and paint-blocked websites.
The positions, strategies, or opinions reflected in this article are those of the authors and do not necessarily represent the positions, strategies, or opinions of Akamai.
-  (2018-Apr.) Accelerated Mobile Pages. Note: https://www.ampproject.org/learn/overview/ Cited by: §6.
-  (2018-Apr.) Analyze Frames Per Second. Note: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/#analyze_frames_per_second Cited by: §1, §4.
-  (2018-Apr.) Battery Status API. Note: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API Cited by: §3.
-  (2015-May.) Hypertext Transfer Protocol Version 2 (HTTP/2). Note: https://tools.ietf.org/html/rfc6146 Cited by: §1.
-  (2018-Apr.) BOOMR.plugins. Continuity. Note: https://akamai.github.io/boomerang/BOOMR.plugins.Continuity.html Cited by: §1, §4.4, §4.5.
-  (2018-Apr.) Cathpoint Synthetic Monitoring. Note: http://www.catchpoint.com/synthetic-monitoring/ Cited by: §5.
-  (2018-Sept.) How the Puffin Browser Works. Note: https://medium.com/coding-neutrino-blog/how-the-puffin-browser-works-440c91cece8f Cited by: §1, §6.
-  (2018-Apr.) Compare Specs. Note: https://www.gsmarena.com/compare.php3?idPhone1=7201&idPhone2=8516 Cited by: §4.1.2.
-  (2014-Jul.) How to use battery saver on the LG G3. Note: https://www.androidcentral.com/how-use-battery-saver-lg-g3 Cited by: §2.
-  (2018-Apr.) Dynatrace Real user monitoring (RUM). Note: https://www.dynatrace.com/capabilities/real-user-monitoring/ Cited by: §5.
-  (2013-Jun.) The average web page has almost doubled in size since 2010. Note: http://www.webperformancetoday.com/2013/06/05/web-page-growth-2010-2013/ Cited by: §1.
-  (2017-Aug.) The average web page is 3MB. How much should we care?. Note: https://speedcurve.com/blog/web-performance-page-bloat/ Cited by: §1.
-  (2018-Apr.) Extend battery life - Samsung Galaxy J5. Note: https://www.helpforsmartphone.com/public/en/samsung/galaxy-j5/android-5-1/guides/14/Extend-battery-life-Samsung-Galaxy-J5 Cited by: §2.
-  (2018-Apr.) Galaxy Note 8 Specs. Note: https://www.gsmarena.com/samsung_galaxy_note8-8505.php Cited by: §4.1.4.
-  (2016-Oct.) A Case for Faster Mobile Web in Cellular IPv6 Networks. In ACM MobiCom, Cited by: §1.
-  (2009-Nov.) Gomez Last-Mile Testbed. Note: https://goo.gl/BtwSWY Cited by: §5.
-  (2016-May.) Fast and resilient web apps: Tools and techniques - Google I/O 2016. Note: https://www.youtube.com/watch?v=aqvz5Oqs238&feature=youtu.be&t=19m45s Cited by: §1.
-  (2018-Apr.) Render-tree Construction, Layout, and Paint. Note: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction Cited by: §1.
-  (2013-Sept.) High Performance Browser Networking. O’Reilly Media, Inc.. Cited by: §1, §6.
-  (2018-Apr.) How do I use Power saving mode on my Samsung Galaxy S5?. Note: https://www.samsung.com/uk/support/mobile-devices/how-do-i-use-power-saving-mode-on-my-samsung-galaxy-s5/ Cited by: §2.
-  (2018-Apr.) How mPulse works. Note: https://learn.akamai.com/en-us/webhelp/mpulse/mpulse-help/GUID-EBEC9222-7876-46F9-81A8-2227CFA89851.html Cited by: §1, §3, §5.
-  (2018-Apr.) How To Boost Your Battery. Note: https://support.sonymobile.com/us/xperiaz5compact/dm/battery/ Cited by: §2.
-  (2018-Apr.) How to exten battery life on HUAWEI Y6 Elite?. Note: https://www.hardreset.info/devices/huawei/huawei-y6-elite/faq/tips-tricks/how-to-save-battery-life-on-android-phone/ Cited by: §2.
-  (2018-Apr.) How to Turn Battery Saver Mode On and Off on Alcatel Pixi 4. Note: https://support.bell.ca/Mobility/Smartphones_and_mobile_internet/Alcatel-Pixi-4.how_to_turn_battery_saver_mode_on_and_off_on_my Cited by: §2.
-  (2018-Apr.) How to Turn Power Saving Mode On and Off on Samsung Galaxy Note8. Note: https://support.bell.ca/Mobility/Smartphones_and_mobile_internet/Samsung-Galaxy-Note-8.how_to_turn_power_saving_mode_on_and_off_on_my Cited by: §2.
-  (2018-Aug.) QUIC: A UDP-Based Multiplexed and Secure Transport. Note: https://www.ietf.org/id/draft-ietf-quic-transport-14.txt Cited by: §1.
-  (2016-Feb.) Software vs. GPU rasterization in Chromium. Note: https://software.intel.com/en-us/articles/software-vs-gpu-rasterization-in-chromium Cited by: §4.4.
-  (2018-Apr.) LG G5 Using Power Saving Mode. Note: https://videotron.tmtx.ca/en/topic/lg_g5/using_power_saving_mode.html#step=4 Cited by: §2.
-  (2018-Aug.) Long Tasks API 1. Note: https://w3c.github.io/longtasks/ Cited by: §1, §4.3.
-  (2018-Apr.) Detect Online Fraud and Locate Online Visitors. Note: https://www.maxmind.com/en/home Cited by: §3.
-  (2013-Mar.) How Fast is Your Web Site?. In ACM Queue, Volume 11, issue 2, Cited by: §5.
-  (2016-Mar.) Mobile Trends in Retail. Note: https://www.kount.com/LiteratureRetrieve.aspx?ID=232433 Cited by: §1.
-  (2018-Apr.) Monitor and Extend Battery Life on Galaxy S6. Note: https://www.samsung.com/us/support/answer/ANS00066391/ Cited by: §2.
-  (2015-Aug.) Navigation Timing. Note: http://w3c.github.io/navigation-timing/ Cited by: §1, §3, §3.
-  (2015-05) Mobilyzer: An Open Platform for Controllable Mobile Network Measurements. In ACM MobiSys, Cited by: §5.
-  (2010-08) The Akamai Network: A Platform for High-performance Internet Applications. SIGOPS Oper. Syst. Rev. 44 (3). Cited by: §3.
-  (2015-Jun.) Three years since World IPv6 Launch: strong IPv6 growth continues. Note: https://blogs.akamai.com/2015/06/three-years-since-world-ipv6-launch-strong-ipv6-growth-continues.html Cited by: §1.
-  (2017-Jul.) Reliably Measuring Responsiveness in the Wild. Note: https://www.youtube.com/watch?v=y5qPix1tdOE Cited by: §4.3.
-  (2016-Sept.) Long Tasks API v2. Note: https://docs.google.com/document/d/125d69JAC7nyx-Ob0a9Z31d1uHUGu4myYQ3os9EnGfdU/edit Cited by: §4.3.
-  (2018-Apr.) PerformanceTiming.domContentLoadedEventEnd. Note: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/domContentLoadedEventEnd Cited by: §4.4.
-  (2015-Mar.) How to Turn on Battery Saver Mode in Android 5.0. Note: https://www.tomsguide.com/us/battery-saver-mode-android-5,news-20491.html Cited by: §2.
-  (2018-Apr.) Sony Xperia Z5 and Z5 Compact Tips and Tricks. Note: https://www.youtube.com/watch?v=T1BZNsNJBo4&feature=youtu.be&t=71 Cited by: §2.
-  (2008-Dec.) High Performance Web Sites: Essential Knowledge for Front-End Engineers. O’Reilly Media, Inc.. Cited by: §6.
-  (2009-Jun.) Even Faster Web Sites: Performance Best Practices for Web Developers. O’Reilly Media, Inc.. Cited by: §6.
-  (2016-Mar.) What slows you down? Your network or your device?. In arXiv:1603.02293, Cited by: §1, §4.1.1, §5.
-  (2018-Apr.) Test a website’s performance. Note: https://www.webpagetest.org/ Cited by: §5.
-  (2018-Apr.) Threading and Tasks in Chrome. Note: https://chromium.googlesource.com/chromium/src/+/lkgr/docs/threading_and_tasks.md Cited by: §4.
-  (2013-Apr.) Demystifying Page Load Performance with WProf. In USENIX NSDI, Cited by: §5.
-  (2018-Sept.) What Is Amazon Silk?. Note: https://docs.aws.amazon.com/silk/latest/developerguide/introduction.html Cited by: §1, §6.
-  (2018-Apr.) window.requestAnimationFrame(). Note: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame Cited by: §4.5.