Design patterns for energy-efficient Web applications

Published: 27 Apr 2025
Written by: Chun Fei Lung

Applying these design patterns in your code may (or may not) make your web applications more energy-efficient.

On the plus side, it’s positive…

Energy patterns are best practices that developers can use to make their source code energy efficient, which is not only good for the environment but also for users with battery-powered devices like laptops, tablets, and smartphones.

While researchers have already developed catalogues of energy patterns for mobile apps and deep learning libraries, no catalogue has been created yet for web applications.

This week’s paper does just that, by porting previously created energy patterns for mobile apps to web applications and seeing what sticks.

About the article

Title	Energy patterns for Web: An exploratory study
Year	2024
Author(s)	Pooja Rani (University of Zurich) Jonas Zellweger (University of Zurich) Veronika Kousadianos (University of Bern) Luis Cruz (Delft University of Technology) Timo Kehrer (University of Bern) Alberto Bacchelli (University of Zurich)
Venue	International Conference on Software Engineering: Software Engineering in Society

The ported energy patterns can be found in the table below. Sixteen patterns are just as applicable to web applications as to mobile apps, four patterns apply only partially to web applications, and two patterns do not apply to web applications at all.

Pattern	Applicable	Client/server	Description
Avoid extraneous graphics and animations	✅	server	Use battery-intensive graphics or animations with moderation, e.g. by not loading heavy graphics until users interact with them
Avoid extraneous work	✅	server	Present only relevant data or perform tasks that have a direct impact on the user experience, e.g. pausing audio/video when content is not visible
Batch operations	✅	server	Combine multiple operations to perform batch processing, e.g. grouping several operations into a single HTTP request
Cache	✅	client	Use caching mechanisms to reduce network load, e.g. by caching API responses in `localStorage`
Dark UI colours	✅	client	Provide a dark theme for your web application, e.g. using a toggle
Decrease rate	✅	server	Increase the time interval between requests to the backend, e.g. by not refreshing data more often than needed
Dynamic retry delay	✅	server	Use a systematic retry increasing time interval after each failed attempt to a resource, such as a database, or network
Enough resolution	✅	server	Provide high-accuracy data only when strictly necessary, e.g. by using lossy image formats for photos
Inform users	partially	client	Inform users of energy-intensive operations in a web application (e.g. autoplaying videos on YouTube)
Kill abnormal tasks	✅	server	Provide means of interrupting energy-hungry operations, e.g. by using a timeout to interrupt abnormal operations
Manual sync – on demand	✅	server	Perform tasks only when requested by the user
No screen interaction	partially	client	Allow interaction without using the display whenever possible, e.g. using keyboard shortcuts
Open only when necessary	✅	server	Open resources or services (like webcam feeds) only when necessary
Power awareness	partially	client	Enable or disable certain website functionalities based on the device’s power status, e.g. Chrome’s Energy Saver mode that kicks in when the battery level drops below 20%
Push over poll	✅	server	Use push notifications to receive updates from resources instead of actively querying resources via polling
Race-to-idle	✅	server	Release unnecessary resources and services, e.g. use garbage collection and release resources like microphones once a video call ends
Reduce size	✅	server	Transmit only necessary data
Sensor fusion	❌	—	Use data from low-power sensors to infer whether new data needs to be collected from high-power sensors
Suppress logs	✅	server	Keep the rate of logging low
User knows best	✅	client	Allow users to customise preferences for energy-critical features
Wi-Fi over cellular	❌	—	Delay or disable heavy data connections until the device is connected to a Wi-Fi network

The paper doesn’t do a very good job of explaining what each pattern is or why it matters, but fortunately that information is easy to find in the paper that originally introduced energy patterns for mobile. It’s also unclear why patterns are classified as “client” or “server” (side note: Take, for example, the first pattern, which concerns graphics and animations but is curiously classified as a “server” pattern.), so I wish the paper had spent a few more words clarifying this.

Interviews with six professional web developers suggest that most developers are unfamiliar with the concept of energy patterns. While interviewees found some patterns easy to understand, there were also some that required some follow-up questions or that they found hard to imagine within the context of web applications.

Another interesting observation is that web developers tend to prioritise functionality and performance, in contrast to mobile developers who show greater concern for battery life and cellular network considerations. One developer even appears to be completely indifferent to energy consumption on local machines and seems to care only about energy consumption on servers…

Nevertheless, the interviewed developers showed willingness to implement energy patterns in their code. While half the interviewees are open to refactoring existing code, most prefer to incorporate the pattern in new code only. With regard to tooling, the interviewees showed limited awareness of all the existing tools for energy measurement (side note: The paper doesn’t elaborate on this at all, so I’m still in the dark about this…).

The final part of the paper discusses measurements of actual energy usage for two specific energy patterns, Dynamic retry delay and Open only when necessary, using Intel PowerLog (side note: So that’s one tool! It just happens to be discontinued.) on a Mac Mini running macOS.

The results are somewhat surprising. The measurements show no significant difference in energy usage between application of the Dynamic retry delay pattern or its anti-pattern (side note: i.e. not using the pattern). For the Open only when necessary pattern, the measured energy usage was actually higher with than without the pattern. These are clear signs that the effect of these patterns may depend heavily on the specific implementation and use cases.