Coonti 
Blog

Your Website Uses Energy. Do You Know How Much?

When we talk about website performance, we usually talk about milliseconds. How quickly does the page load? How large is the JavaScript bundle? How many requests does the browser make? How well does the site perform on mobile?

These are important questions. But there is another metric that deserves more attention: how much energy does the website require to provide its experience?

For website designers and developers, this is becoming an increasingly important question. The web has evolved from a relatively simple document-delivery system into the world's largest application platform. Modern websites run JavaScript, decode images and video, execute animations, communicate with APIs, track users, render complex interfaces, and increasingly incorporate AI.

All of that computation requires energy.

A recent peer-reviewed study by our founder Janne Kalliola and Juho Vepsäläinen, Challenges Related to Approximating the Energy Consumption of a Website, examined how we can actually measure that energy use. The research compared different approaches to estimating website energy consumption and measured the same website implemented using two different web frameworks, Qwik and Next.js.

The results contain an important lesson for anyone building websites:

Green web development is not simply about reducing page weight. It is about reducing unnecessary computation. And to do that effectively, we need better measurements.

Website energy consumption is more complicated than it looks

A website's energy footprint is spread across several parts of the technology stack. There is the server and infrastructure that delivers the website. There are networks transferring data. There is the user's device, including its CPU, memory, display and other components. And there is the browser itself, which has to parse, compile, execute and render everything that arrives.

For developers, the last part is particularly interesting, as the browser is effectively a runtime environment for your software. Every JavaScript function that executes, every layout calculation, every animation and every piece of content that gets rendered requires computation. The user's device performs that work, and computation consumes energy.

This means that two websites that deliver roughly the same amount of data can potentially have very different energy consumption. A page can be relatively small in terms of transferred bytes and still make the CPU work hard.

Conversely, a larger page does not necessarily consume proportionally more energy if much of its content can be efficiently cached, deferred or rendered without significant ongoing computation.

That makes bytes transferred a useful but incomplete proxy for energy consumption.

Performance and energy efficiency are closely related—but not identical

This is where green coding connects naturally with established web performance practices. Many techniques used to make websites faster also reduce energy consumption:

• Reduce unnecessary JavaScript.
• Avoid expensive client-side computations.
• Optimize images and video.
• Lazy-load content that users do not immediately need.
• Avoid unnecessary animations and effects.
• Reduce the number of third-party scripts.
• Cache resources effectively.
• Avoid repeatedly rendering content that has not changed.
• Keep interfaces simple where complexity does not provide meaningful user value.

These practices reduce the amount of work performed by browsers and devices. But there is an important distinction. A fast website is not automatically an energy-efficient website.

A performance optimization may reduce loading time while increasing CPU usage. A framework may improve developer productivity but introduce additional runtime work. A caching strategy may reduce network traffic while requiring additional processing.

The only reliable way to understand the effect of an optimization is to measure it.

The problem with website energy calculators

There are already services that give websites an estimated energy consumption or carbon footprint. They are useful for creating awareness, but the research shows why their results need to be treated carefully.

The research compared estimates from existing services with measurements of an actual website. They found that existing estimation services could overestimate energy consumption compared with their measurements and could even produce contradictory results when comparing different web frameworks.

One particularly important finding concerned Website Carbon. The study found that the service did not account for some techniques that affect actual browser work, such as lazy rendering. They also identified questions around how hosting characteristics were detected and noted that the calculation was not sufficiently transparent to reproduce or fully understand the intermediate results.

The takeaway isn't that website carbon calculators are useless. They can be useful as rough indicators and communication tools. But don't treat a single estimated number as a precise measurement of your website's energy consumption.

If you are comparing two implementations, evaluating an optimization, or setting an energy budget, you need a measurement approach that reflects what actually happens on the user's device.

Look at the CPU

The study's most important practical recommendation is to use CPU-based measurement methods when estimating web energy consumption. The browser executes your application on the user's machine. If your website causes the CPU to perform more work, it generally requires more energy.

The research found that Firefox Profiler can be used to measure energy consumption with high precision. This provides developers with a much more direct way of examining what their websites are actually doing than relying solely on page weight or an external estimation model.

This changes how we should think about green web development. Instead of asking "How many kilobytes does this page contain?", we can also ask "How much work does the browser have to perform to deliver this experience?" That is a much more useful question when optimizing energy consumption.

Hardware matters too

One of the most interesting observations from the research is that the same website can have substantially different energy consumption depending on the CPU architecture running it.

The study compared an Apple M3 Pro system with a 13th-generation Intel Core i3 system. The measurements showed that the Apple M-series system was strikingly more energy efficient in the tested scenario. The authors caution that the measurement methodologies differed between macOS and Windows, so the result should not be interpreted as a universal benchmark of the two CPU architectures. Nevertheless, the difference was significant enough to demonstrate an important problem with generalized energy models.

This has a major implication for web sustainability. A website does not have one universal energy consumption figure. Energy consumption depends on the entire execution environment:

website → browser → operating system → CPU architecture → device

This is one reason why simplistic models based only on transferred data can miss important parts of the picture.

What does this mean for designers?

Energy efficiency is not solely a developer concern. Design decisions determine how much software eventually needs to be built.

Consider a design containing:

• continuously animated elements,
• autoplay video,
• large background images,
• interactive maps,
• real-time data,
• complex transitions,
• infinite scrolling,
• multiple personalization systems,
• chat widgets,
• analytics and advertising scripts.

Each individual feature might appear harmless. Together, they can create a significant amount of computation. Designers therefore have an opportunity to influence energy consumption before code is written.

A good question during design reviews is not just "Does this improve the user experience?", but it is also "Does the benefit justify the additional computation?". Sometimes the answer will be yes. Sometimes it will be no. That is precisely the point of sustainable design: making the trade-off explicit.

What does this mean for developers?

For developers, the first step is to stop thinking of energy efficiency as a final optimization step. It should become another engineering quality attribute, alongside performance, accessibility, security and maintainability.

A practical approach could look like this:

1. Establish a baseline

Measure the current application before changing it. Don't optimize based on assumptions.

2. Profile CPU activity

Use browser profiling tools to understand where computation is happening. Look for JavaScript execution, rendering, layout work and other sources of unnecessary activity.

3. Identify the expensive parts

Ask which features cause the browser to perform significant work. A few particularly useful areas to investigate include JavaScript-heavy components, animations, continuous event handlers, unnecessary re-renders and third-party scripts.

4. Optimize the architecture

Sometimes the biggest gains don't come from rewriting individual functions. They come from changing how the application works.

Could something be rendered on the server instead of the client? Can functionality be loaded only when required? Can a component be removed altogether? Can the browser avoid doing work that doesn't contribute to what the user sees?

5. Measure again

After making a change, measure the result. An optimization isn't an optimization until the measurement demonstrates that it improved something that matters.

Don't optimize blindly for the framework

The research also offers an important warning for today's framework-heavy web ecosystem.

The study compared Qwik and Next.js implementations of the same website. The research found that energy estimation tools could give contradictory conclusions about the relative energy consumption of the frameworks.

This is a useful reminder that there is no universally "green" framework. Framework choice matters, but the way the framework is used matters too. A theoretically efficient framework can still produce an inefficient application. Likewise, a general-purpose framework can be used to build a relatively efficient website.

The relevant question is therefore: "Which architecture and implementation achieve the required user experience with the least unnecessary computation?"

That is a much more productive engineering question.

Green coding starts with avoiding unnecessary work

There is a simple principle behind much of sustainable software engineering: The greenest computation is the computation you don't have to perform.

This principle applies particularly well to web development.

1. Before optimizing code, ask whether the code needs to exist.

2. Before optimizing an API call, ask whether the API call is necessary.

3. Before compressing an image, ask whether the image needs to be loaded.

4. Before optimizing an animation, ask whether the animation contributes enough value to justify its continuous computation.

5. Before adding another JavaScript dependency, ask whether the functionality can be achieved without it.

This way of thinking moves green coding beyond micro-optimizations. It makes energy efficiency an architectural and design concern.

Measure what matters

The research by Kalliola and Vepsäläinen highlights an uncomfortable reality: we still don't have a perfect, universally applicable way of measuring the energy consumption of websites.

That shouldn't be an excuse for doing nothing. It is a reason to measure carefully.

Use existing tools for rough estimates where appropriate. Use browser profiling when you need to understand actual client-side behavior. Keep the measurement environment consistent when comparing implementations. And, most importantly, treat measurements as evidence rather than absolute truth.

The goal isn't necessarily to discover that your website consumes exactly X joules.

The more useful goal is to answer questions such as:

• Did the new implementation reduce CPU work?
• Did removing this JavaScript reduce energy consumption?
• Does lazy loading actually help in this scenario?
• Which component consumes the most resources?
• Does this framework change make the application more efficient?
• Is this feature worth its computational cost?

Those are questions developers can act on.

A new quality attribute for the web

For decades, web development has been optimized around a familiar set of constraints:

Make it work. Make it fast. Make it accessible. Make it secure. Make it maintainable.

We should add another:

Make it energy efficient.

Energy efficiency is not merely an environmental concern. Less computation can mean better performance, lower infrastructure requirements, longer battery life, reduced operating costs and a better experience on less powerful devices.

And unlike many sustainability questions, software energy efficiency is something developers and designers can directly influence.

The web is already one of the world's largest software platforms. As websites become more sophisticated—and as AI adds another layer of computation—the amount of work performed by browsers is unlikely to decrease.

In other words: Are we building websites that do only the work they need to do?

The answer starts with measuring. And then, with designing and coding for efficiency from the beginning.

Learn more about green coding

Want to understand the fundamentals of energy-efficient software development? Start with Coonti's Basics of Green Coding training.

For teams ready to go further, the One-Day Green Software Workshop combines theory with practical exercises, including energy measurement and evaluating the energy, financial and environmental impact of software changes.

About the research: This article is based on Challenges Related to Approximating the Energy Consumption of a Website by Janne Kalliola and Juho Vepsäläinen, published in IEEE Access in 2025. The paper is open access and provides the detailed methodology, measurements and discussion behind the findings summarized here.