Coonti 
Blog

What Really Makes a Website Energy Efficient?

For years, website performance has been measured using familiar metrics: page weight, loading time, number of requests, JavaScript size, and Core Web Vitals. These metrics matter. But if we want to build a more sustainable web, there is another question we should ask:

How much energy does the website actually consume in the browser?

A recent study by Janne Kalliola, founder of Coonti, and Juho Vepsäläinen examined the front-end energy consumption of 100 websites across mass media, retail, government and public organisations, and sports. The study measured websites from Finland, Sweden, Germany, the UK, and the US, focusing specifically on the effects of caching, cookies, scrolling, and data transfer.

The findings provide some useful—and occasionally surprising—lessons for website designers and developers.

The browser is part of your software stack

When we talk about the environmental impact of a website, it is easy to focus on servers, cloud infrastructure, and data transfer.

But a significant share of the energy associated with digital services is consumed on the user's device. The study notes that user devices account for approximately 54% of energy consumption in the Sustainable Web Design Model, making front-end efficiency an important area for improvement.

That means the code you ship does not stop mattering once it reaches the browser. JavaScript execution, rendering, layout, image processing, animations, third-party scripts, and dynamically loaded content all require the user's device to do work.

And work requires energy.

For developers, this changes the way we should think about web performance. A website isn't simply a collection of bytes transferred from a server. It is a software system executing on someone else's computer.

How much energy does a web page consume?

The study measured front-end energy consumption using an Apple M3 Pro laptop. Across the tested scenarios, average consumption ranged from 1.85 mWh to 5.03 mWh per front-page load, depending on caching, cookie settings, and scrolling behaviour.

For a typical scenario involving accepted cookies and partial scrolling, the researchers estimated an average of approximately 4.36 mWh for a fresh page load and 3.23 mWh for a subsequent load.

These numbers should not be interpreted as universal values for every website or device. The study used one CPU architecture and one browser, and the authors explicitly caution that results are not directly generalisable to other hardware.

Their value is as a baseline—and, more importantly, as evidence that we can measure the energy consumed by front-end software.

Caching can significantly reduce energy consumption

Caching is hardly a new concept for web developers. We cache assets to reduce bandwidth, improve performance, and make pages load faster. But caching also has an energy benefit on the client side.

The research found that cached versions consumed between 54.4% and 81.8% of the energy of fresh versions, depending on the scenario. In other words, caching reduced front-end energy consumption substantially.

The effect was even larger for data transfer. Cached pages transferred only around 26–37% as much data as fresh pages, on average.

This illustrates an important principle: An optimization can have multiple environmental benefits at once.

Good caching can mean less network traffic, less data processing, and less work for the browser. It also means that caching should be considered an element of sustainable architecture—not simply a performance optimization.

Cookies are not just a privacy issue

The research also found a substantial difference between accepting and rejecting non-essential cookies.

When users rejected non-essential cookies, the pages consumed 61.5–81.0% of the energy consumed when cookies were accepted. Data transfer and request counts were also significantly lower.

Why?

The researchers attribute much of the difference to third-party JavaScript and related functionality, including tracking and other services.

The effect on requests was particularly striking. With cookies rejected, the number of third-party requests fell to between 27.4% and 42.5% of the number generated when cookies were accepted.

This gives designers and developers another reason to scrutinise the third-party technologies added to a website. Analytics, advertising, social media integrations, personalisation, chat widgets, A/B testing and other services can all provide legitimate business value.

But they are not free. Every third-party script adds complexity, dependencies and potentially additional computation.

A sustainable design process should therefore ask:

What value does this script provide, and is that value worth the computational cost?

Scrolling has an energy cost too

Here's another finding that may be less intuitive. The researchers compared pages that remained above the fold with pages that were scrolled to the bottom.

The above-the-fold versions consumed 70.1–84.8% of the energy of the corresponding fully scrolled versions—a reduction of roughly 15–30%.

The explanation is straightforward: scrolling can trigger additional content and assets to load and render. It also means the page remains active on the screen for longer.

Modern websites often use long pages, infinite scrolling, large media assets, animations, and lazy-loaded components. These patterns aren't inherently bad. In many cases, they provide a better user experience. But they should be used deliberately.

If a user has to scroll through a huge page to find the information they need, the design may be imposing additional computational work for little benefit.

Design for the content that matters

For designers, this suggests a useful question during the design process:

• How much of this page needs to exist, load, and execute?
• Could important information be presented more directly?
• Could a complex visual effect be simplified?
• Could content be loaded only when the user actually requests it?
• Could a long page be shortened without reducing usability?
• Could media-heavy components be deferred until they are relevant?

Sustainable design is not about making every interface minimal. It is about making intentional choices about where complexity provides value.

More data does not necessarily mean more energy

One of the study's most interesting findings concerns a metric developers often use as a proxy for sustainability: transferred data. You might reasonably expect a page transferring twice as much data to consume approximately twice as much energy. The research does not support such a simple relationship.

The measured correlation between energy consumption and data transfer was only 0.38 across all websites. The correlation between energy consumption and the number of requests was stronger, at 0.64, but still not strong enough for requests to serve as a reliable proxy for energy consumption.

The researchers therefore recommend that developers measure energy consumption directly rather than relying on proxy metrics.

A lightweight website is generally desirable. Reducing unnecessary data is still an important green web practice. But 1 MB less data does not automatically equal a specific amount of energy saved.

The browser may perform very different amounts of computational work depending on what that data contains and what the application does with it.

A small JavaScript bundle isn't necessarily a green website

This is particularly relevant to modern web development.

Imagine two websites:

• Website A transfers more data but mostly displays static content.
• Website B transfers less data but executes significant amounts of JavaScript, performs frequent rendering operations, runs trackers, and continually updates the interface.

Which one consumes more energy?

You cannot reliably answer that from page weight alone. The study found that the amount of JavaScript, CSS, images, transferred data, and requests varied substantially between websites. Yet energy consumption did not vary in direct proportion to those metrics.

This is why sustainable web development needs to move beyond simplistic rules such as "make the page smaller." The better goal is:

Make the browser do less unnecessary work.

What should developers measure?

If data volume and request counts are imperfect proxies, what should we do instead?

Measure energy.

The study used Sitespeed.io with Firefox because Firefox can measure CPU energy consumption. The researchers measured browser threads on an Apple M3 Pro system and repeated measurements five times for each website to reduce variance. In total, the study produced 3,640 measurements across its test scenarios.

The researchers also made their measurement toolkit publicly available so that others can reproduce the measurements and test their own websites.

For a development team, the important principle is not necessarily to reproduce the entire research setup. It is to start treating energy as a measurable software quality attribute. Instead of asking only:

• How many kilobytes did we remove?
• How many requests did we eliminate?
• Did Lighthouse score improve?
• Did the page load faster?

also ask:

• Did CPU energy consumption decrease?
• Which components consume the most energy?
• What happens when third-party scripts are removed?
• Does caching reduce energy consumption?
• What happens when content is lazy-loaded?
• Does a new architectural approach reduce computational work?

These questions can reveal optimizations that conventional web performance metrics don't necessarily capture.

Green architecture matters

There is also a broader architectural lesson here. Caching, lazy loading, third-party services, content rendering, API calls, client-side JavaScript, and media delivery are not isolated implementation details. They are consequences of architectural decisions.

For example, deciding whether functionality should be rendered on the server or in the browser changes where computation happens.

Deciding whether content is loaded immediately or on demand changes when computation and data transfer happen.

Deciding whether to use a third-party service adds another dependency and potentially another set of network requests and scripts.

These decisions belong in architecture and design discussions—not only in a final performance optimisation sprint.

Don't optimise for a metric. Optimise for the system.

The research provides an important warning against reducing sustainable web development to a checklist of individual metrics.

• Page weight matters.
• Requests matter.
• JavaScript size matters.
• Caching matters.

But none of these tells the complete story.

The study found that the relationship between energy consumption and data transfer was moderate at best, and the authors explicitly recommend measuring energy rather than relying on proxy metrics. This suggests a more mature approach to green coding:

Measure → understand → change → measure again.

For example:

1. Measure your application's baseline energy consumption.
2. Identify where computation and unnecessary activity occur.
3. Change the architecture, code, design, or dependencies.
4. Measure again.
5. Keep the changes that actually improve the result.

This is essentially the same engineering discipline we already use for performance. The difference is that we're adding another quality attribute to the equation: energy efficiency.

What website designers can do

Sustainable web development is not solely the developer's responsibility. Designers can influence energy consumption long before implementation begins.

Consider:

1. Reduce unnecessary complexity. Every interactive element, animation, dynamic component, and media asset should provide a meaningful benefit.

2. Design for progressive disclosure. Don't make the browser load and render everything immediately if users only need a fraction of the content.

3. Question long pages. Long pages are not inherently inefficient, but consider whether their structure encourages unnecessary loading and rendering.

4. Use media deliberately. Images and video are major contributors to data transfer. Make sure they are serving a real user need.

5. Challenge third-party functionality. Analytics, advertising, social integrations, chat and personalisation can all be useful—but should be treated as architectural dependencies rather than free add-ons.

6. Collaborate with developers early. The most effective green software decisions are often made before implementation.

What developers can do

For developers, the study suggests several practical priorities:

1. Measure energy consumption directly. Don't assume that page weight or request count tells you how much energy the browser uses.

2. Make caching a first-class concern. Caching demonstrated a significant reduction in front-end energy consumption in the study.

3. Minimise unnecessary third-party JavaScript. The dramatic reduction in requests after rejecting non-essential cookies demonstrates how much activity third-party services can introduce.

4. Load content when it is needed. Lazy loading can reduce the work required when a page initially loads, while also avoiding unnecessary downloads for content the user never sees.

5. Consider the full execution environment. Energy consumption depends on more than your code. The study used a single CPU architecture and browser, and the authors caution that energy results can vary between CPU families and browsers.

6. Include energy in architectural decisions. Don't wait until the application is finished to ask whether it is energy efficient.

The greenest request is often the request you don't make

The research reinforces a familiar principle from sustainable software engineering: Avoid unnecessary work before trying to optimise the work you need to do.

• Don't load an image the user won't see.
• Don't execute JavaScript that isn't needed.
• Don't send a request to a third-party service without a clear purpose.
• Don't repeatedly render content that hasn't changed.
• Don't transfer data simply because it is convenient.

And don't build an unnecessarily complex interface when a simpler one delivers the same user value.

These choices can improve more than sustainability. They can also improve performance, responsiveness, maintainability, privacy, accessibility, and sometimes operating costs. That is what makes green software engineering particularly interesting: the best sustainability improvements are often simply good engineering.

From green coding to green architecture

The study's findings also point beyond individual lines of code.

If caching can reduce energy consumption, it is an architectural concern.

If third-party scripts have a substantial impact, dependency management is an architectural concern.

If scrolling triggers additional loading and rendering, information architecture and interaction design become sustainability concerns.

If transferred data is not a reliable proxy for energy consumption, measurement strategy becomes an engineering concern.

In other words, green software needs to be considered at the architecture, design, development, and operations levels—not bolted on at the end.

For website teams, that is perhaps the most important takeaway from this research. The question isn't simply how to make an existing website greener.

It is:

How can we design and architect websites that require less energy from the beginning?

Learn more about green architectures

If you want to understand how architectural decisions influence software's environmental impact, explore Coonti's Green Architectures training. It introduces the principles and practices needed to make sustainability part of software architecture and design.

Take green coding into practice

For development teams that want to go further, Coonti's Two-Day Green Coding Workshop provides a practical deep dive into measuring and reducing the energy consumption and environmental impact of software.

About the research

This article is based on Evaluating Front-end Web Energy Consumption: Quantifying the Role of Caching, Cookies, Scrolling Behavior, and Data Volume by Janne Kalliola and Juho Vepsäläinen, published in ACM Transactions on the Web. The study measured 100 websites across four industries and five countries, using CPU-based energy measurements to examine how different browsing behaviours and implementation choices affect front-end energy consumption.

The findings should be understood within the study's limitations: measurements were conducted on a single Apple M3 Pro CPU and using Firefox, and the study focused on front pages rather than complete user journeys. The authors identify measurements across different CPUs, architectures, browsers, and mobile devices as important areas for further research.