Web Performance with Android's Battery-Saver Mode
In 2019 the average price for a smartphone in North America was about 480€. 380€ in Europe and the Middle East and Africa, it was 230€. We know that a browser needs CPU to go through the sequence of steps to paint a pixel. We need to build the Document Object Model (DOM), the Cascading Style Sheets Object Model, the Rendering Tree and processing JavaScript.
I wrote a blog post about the Critical Rendering Path. Check it out if you want to know more.
I recently read a scholarly article posted in the web performance slack channel about Web Performance with Android’s Battery-Saver Mode. I recommend you read the full scholarly article by Utkarsh Goel, Stephen Ludin, Moritz Steiner.
Tl;dr
In this article, you read an overview of the scholarly article Web Performance with Android’s Battery-Saver Mode.
Table of Contents
The Saver Mode is a great feature for mobile device users to extend the battery life, but it is a massive bottleneck for mobile web performance. The scholarly article describes a large-scale measurement study to identify the impact.
What metrics did they use?
To have meaningful results from their large dataset, they measured the following metrics.
- Page Load Time (PLT)
- Time to First Paint (TTFP)
- LongTask Time (LTT)
- Time to Interactive (TTI)
- Frame Rate per Second (FPS)
Page Load Time (PLT)
The time it takes for the browser to display the page. Starting from navigation till the page finishes loading in the browser
Time to First Paint (TTFP)
The time it takes for the browser to paint the first pixel.
LongTask Time (LTT)
The time JavaScript code blocks the main thread and therefore makes the page unusable to the user even if it looks ready. Long tasks are also CPU heavy and reduce the battery status of the mobile device.
Time to Interactive (TTI)
The Time to Interactive shows us how long it takes until the website is fully interactive to the user and his input. A page is fully interactive, when the user sees content on the page, event handlers are registered, and the page responds to user interactions within 50ms.
Frame Rate per Second (FPS)
Frame Rate per Second means the rate of printing frames per second on the screen. Responsive user interfaces aim to have a frame rate of 60 frames per seconds. The user perceives 60 FPS as smooth. For the browser, this means it hat 16ms to do its work like script parsing, recalculate styles, layout and painting. As the browser also has to do some housekeeping, it is better to aim for 10ms for one task.
What did they measure?
Page Load Time (PLT)
On most of the tested devices, the Page Load Time rises as the battery charge level drops to 15%. The table below shows the “Summary of PLT distributions on Huawei Y6 Elite phone”.
| PLT distributions | PLT when battery charge level = 8% | PLT when battery charge level = 50% | Relative difference in PLT (%) |
|---|---|---|---|
| p10 (fast network) | 6.8 seconds | 5.3 seconds | 38.3% |
| p25 | 8.3 seconds | 6.5 seconds | 27.6% |
| p50 | 10.2 seconds | 8.2 seconds | 24.3% |
| p75 | 12.6 seconds | 10.2 seconds | 23.5% |
| p90 (slow network) | 15.4 seconds | 13.4 seconds | 14.9% |
Time to First Paint (TTFP)
The moment the battery charge level drops to 15% the Time to First Paint also increased. Continuously through all percentiles, the time rose to over 6000ms for the 90th percentile.
LongTask Time (LTT)
Long tasks block the main thread. We can measure them with them Long Tasks API. The API considers every task that takes 50ms or more as long. This threshold comes from the RAIL Model if you want to know more. In the study, the Long Task Time of 3000ms rose to 5000ms on a P8 Lite due to the devices CPU clock speed is reduced.
Newsletter
Hello and welcome! Don't miss out on crucial web performance insights, plus the latest on accessibility and sustainability, delivered directly to your inbox. Elevate your craft in creating fast, user-friendly, and eco-conscious websites. Sign up now to access seasoned expertise and the freshest news!
Time to Interactive (TTI)
The Time to Interactive is calculated based on the visually ready page and the time when the page is interactive to the user. After the page is ready, the first period of 500ms during the browser was idle is marked as the TTI. As well as the other metrics, the TTI rises after the batterie charge level drops below 10%. The figure in the article illustrates this quite well. Under 10% the TTI increases from an average of about 7000ms to 9000-1000ms.
Frame Rate per Second (FPS)
Also, the Android Battery Save Mode effects the Frame Rate per Second. The average Frame per Second in the dataset was round about 16ms, which is considered as good. Below 10% of battery level, the frames per second drop and can lead to poor user experience.
Next steps
Android Battery Save Mode has a significant effect on web performance and user experience. At the same time, it is a useful feature to expand the batterie life of our phones. So where can we start to fix this? Optimize for the Critical Rendering Path to reduce the Time to First Paint.
I wrote a blog post about the Critical Rendering Path. Check it out if you want to know more.
Reduce the amount of JavaScript and move complex code to a WebWorker or try a different rendering strategy. Group your animations and make use of the requestAnimationFrame method or the Web Animations API.
Conclusion
In this post, I presented you the result of the scholarly article about “Web Performance with Android’s Battery-Saver Mode” by Utkarsh Goel, Stephen Ludin, Moritz Steiner.
If you like this article, smile for a moment, share it, follow me, check out my RSS feed and subscribe to my newsletter.
Cheers Marc
Further Reading
- Web Performance with Android’s Battery-Saver Mode
- Long Tasks
- Time to Interactive
- Average Smartphone Price by Region
