# Energy Consumption of Web Applications: Measurement Challenges in Practice

Louay Khrouf, Anas Shatnawi, Romain Rouvoy, Benoit Verhaeghe, Boubou

Thiam Niang

► To cite this version:

Louay Khrouf, Anas Shatnawi, Romain Rouvoy, Benoit Verhaeghe, Boubou Thiam Niang. Energy Consumption of Web Applications: Measurement Challenges in Practice. IEEE Software, In press, Special Issue on Green Clean Software Sustainability, 10.1109/MS.2025.3641504. [hal-05388914v2](https://hal-inriaHalId:hal-05388914)

HAL Id: hal-05388914

https://inria.hal.science/hal-05388914v2

Submitted on 5 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Energy Consumption of Web Applications: Measurement Challenges in Practice

Louay Khouf, Berger-Levrault / Inria / Univ. Lille / CNRS, France

Anas Shatnawi, Berger-Levrault, France

Romain Rouvoy, Univ. Lille / Inria / CNRS, France

Benoit Verhaeghe, Berger-Levrault, France

Boubou Thiam Niang, Berger-Levrault, France

**Abstract**—Software systems consume about 6% of global energy, and new regulations promote energy efficiency. However, developers face challenges like standardized measurement tools, integrating energy monitoring, and interpreting data meaningfully, which hinders informed decisions balancing energy efficiency and performance metrics.

While most studies focus on small-scale projects, we addressed this gap with an industrial case study. We developed a methodology to assess energy impact using Dynatrace Carbon Impact and NeoLoad, enabling the evaluation of technology-driven design decisions under production-like conditions. This enabled the evaluation of technology-driven design decisions, such as frontend frameworks (Java Swing vs. Angular), backend stacks (legacy Java vs. Spring Boot), and serialization formats (JSON vs. Protobuf) under production-like conditions. Our insights highlight several design recommendations for energy-efficient software in industrial contexts.

**Index Terms:** Software energy consumption, sustainable software development, web application efficiency, green software engineering

Software energy consumption refers to the energy used by software to perform tasks, including the supporting infrastructure [1]. The Shift Project study found that the digital sector—including devices, networks, and data centers—accounts for over 5% of global primary energy consumption and around 3.5% of greenhouse gas emissions, and is projected to exceed 7% by 2025. [2]. This consumption is expected to increase by 6.2% annually, straining energy resources and worsening environmental impacts. European and French regulations now require companies to measure and report software energy use, creating pressure to adopt more efficient practices [3].

During software development, architects explore design solutions across architectural styles, programming

languages, communication protocols, development frameworks, and data serialisation techniques. Each design solution can lead to variations in energy consumption, depending on the chosen architecture, language, or framework. Architects must understand how their design solutions affect energy consumption to develop energy-efficient software. However, this awareness is limited by the lack of reliable energy-measurement data across technologies and usage patterns. In practice, architects still prioritize maintainability and ease of development, as energy consumption is not yet part of their design culture. By providing empirical evidence on the energy impact of design decisions and usage scenarios, Our study offers empirical insights that enable architects to compare implementation alternatives and identify the more energy-efficient choice.

Previous research has examined energy-efficient practices in controlled experimental settings, comparing
ing design patterns [4, 5], communication protocols [6], and architectural styles [7]. However, these studies lack the complexity, variability, and operational constraints of real-world systems and overlook the diverse technologies, tooling ecosystems, and deployment environments found in industry. Building on these observations, our study provides empirical evidence of how these measurement challenges manifest in an industrial environment with heterogeneous configurations, offering a more realistic view of the difficulties in assessing energy consumption under production-like conditions.

As a continuation of our previous work [8], this article builds on the same industrial context, motivation, and general methodology. We leverage this foundation to address additional research questions, such as the impact of usage patterns on energy consumption. Furthermore, we identify and address five challenges related to energy measurement in an industrial setting that were not covered in our previous work. To support this expanded analysis in an industrial context, we applied an energy measurement methodology at Berger-Levrault, a software publisher with a diverse product portfolio across multiple platforms. Our approach combined Dynatrace Carbon Impact for monitoring resource and energy consumption and NeoLoad for simulating realistic workloads. The goal was to compare the energy impact of design alternatives under production-like conditions.

During the implementation of this methodology, we faced practical challenges that illustrate why energy measurement is difficult in industrial settings, including limited access to low-level data in virtualised infrastructures, coarse monitoring granularity, experimental noise, legacy constraints such as Citrix, and tooling or deployment inconsistencies. These challenges highlight the gap between controlled, small-scale research environments and industrial practice, which combines hybrid infrastructures, legacy and modern stacks, and diverse operational constraints that require adapting commercial tools such as Dynatrace and NeoLoad.

Despite these constraints, and to acknowledge the insights established in our previous study [8], we briefly restate its main findings. That work showed that adopting Angular for the frontend and Spring Boot for the backend reduced overall energy consumption by about 70%, with Angular alone consuming 30 times less energy than Java Swing, and that switching from JSON to Protobuf decreased energy use by 33% due to faster execution and lower memory demand. This study extends the previous work by analyzing energy consumption under different software usage patterns. The results show that energy consumption

per request declined as workload volume increased, indicating better efficiency at scale. However, backend components consumed more energy per user under heavy load, while the database remained stable and efficient. These findings suggest that modern technologies and usage-aware design decisions support sustainable software development.

The remainder of this article is organised as follows. Section 2 introduces our methodology, which uses two complementary approaches to evaluate energy consumption based on design alternatives and usage patterns. Section 3 presents key experimental findings, showing how architectural choices and usage behaviour affect energy efficiency. Section 4 details infrastructure constraints in measuring energy in virtual environments. Section 5 addresses experimental noise and monitoring granularity limitations. Section 6 explores constraints in legacy system environments. Section 7 discusses limitations of workload generation tools and inconsistencies in deployment environments that affected fair comparison. Section 8 summarises lessons learned and outlines future research directions.

## Energy Measurement Methodology

To evaluate the energy consumption of software systems, we propose a methodology based on two complementary goals. The first goal is to assess how different technological design choices influence energy usage, helping developers understand the energy implications of alternative architectures and frameworks. To do so, we compare multiple implementations of the same application under identical workloads while collecting CPU, memory, and network metrics, all measured by Dynatrace OneAgent. The second goal is to analyze how energy consumption evolves under varying workload sizes, revealing how systems behave at different scales. For this purpose, we run the same application with varying numbers of users and measure the resulting energy-related metrics. To support both objectives, we follow a unified four-step approach, as illustrated in Figure 1 and described in detail below.

1) **Identifying identical workloads.** Each workload consists of a predefined set of tasks executed consistently across all application versions. This allows us to isolate differences in energy consumption and performance metrics. To reflect realistic usage, workloads are derived from functional test cases simulating common end-user behaviors.

2) **Executing workloads.** The workload size re-
<figure><img src="image_2.png" /><figcaption>FIGURE 1. Methodology for evaluating energy consumption across design solutions and workload sizes.</figcaption></figure>

reflects the total volume of tasks an application processes and is influenced by factors such as request complexity and concurrency. To assess design choices, we apply the same workload across application versions so that energy differences reflect architecture alone. To study behavior under varying usage, we run the same version with different workload sizes to observe how energy consumption scales. Workloads are derived from functional test cases and executed using tools such as NeoLoad<fnref n="1" /> and Gatling.<fnref n="2" /> We used NeoLoad for its reliability and compatibility with legacy frontends via Citrix.<fnref n="3" />

3) **Collecting performance metrics.** Metrics are collected in real-time during workload execution to assess energy consumption relative to workload size across versions. Monitoring is performed using tools, such as Dynatrace OneAgent and Intel PCM.<fnref n="4" /> To support our virtualized and cloud infrastructure, we rely on Dynatrace OneAgent. Energy estimates are generated via Dynatrace Carbon Impact, which converts resource usage data (e.g., CPU utilization, memory consumption, network throughput, and disk I/O) into energy values using regional emission coefficients [9].

4) **Comparing energy consumption.** With the collected metrics, we evaluate the energy efficiency of each application version. A custom dashboard built using Dynatrace APIs aggregates energy data across versions into a unified visual representation. This data and the performance metrics are exported into an Excel file, and visual graphs are created to compare energy usage and resource consumption.

## Energy measurement implementation

To apply the methodology in practice, we rely on a legacy and a modern version of the same software system, which are functionally equivalent and offer the same features and workflows. The modern version is the result of migrating the legacy system to a more recent stack, moving from Java Swing to Angular and updating the backend to Spring Boot, as detailed in [10]. The goal of the comparison is therefore to assess the energy impact of adopting this modern stack rather than to compare the frameworks in isolation. The two versions reflect their real production deployments: the modern version operates on two frontend and two backend servers for load balancing, whereas the legacy version runs on a single server per component. For the JSON-Protobuf comparison, the services differ only in serialization and both are

<footnote n="1">¹https://www.tricentis.com/fr/produits/test-de-performance-neoload</footnote>

<footnote n="2">²https://gatling.io</footnote>

<footnote n="3">³https://www.citrix.com</footnote>

<footnote n="4">⁴https://www.intel.com/content/www/us/en/developer/articles/tool/performance-counter-monitor.html</footnote>
<figure><img src="image_3.png" /><figcaption>**FIGURE 2.** Comparison of energy measurement and CPU usage across components in modern and legacy systems.</figcaption></figure>

deployed on a single server, with Protobuf introduced during the modernisation process [11].

To monitor energy consumption, we deployed the Dynatrace Carbon Impact module on all servers hosting the software. The Java Swing GUI executes remotely through Citrix on a monitored server, while the Angular frontend runs on two monitored servers in the modern stack. Workload generation is performed with NeoLoad: for the legacy version, NeoLoad replays the recorded Citrix session, reproducing the Swing interactions and triggering the corresponding server-side operations; for the modern version, NeoLoad uses its real-browser mode, launching actual browsers that execute the recorded scenario and generate the HTTP traffic processed by the Angular and Spring Boot servers. Although NeoLoad opens real browsers during execution, it runs outside the monitored environment, so measurements capture only the server-side energy on the instrumented frontend, backend, and Citrix servers, excluding any client-side activity. For the JSON-Protobuf comparison, Dynatrace records the server-side energy required for processing, serialization, and deserialization. All energy values are collected at Dynatrace's regular reporting interval during workload execution.

## Results & Key Findings

### Evaluating the energy impact of design choices

The experiments reveal notable differences in the energy consumption of the evaluated web development technologies. Figure 2 presents both the overall energy consumption and CPU usage for each component of the software across the evaluated implementations.

At the frontend level, the legacy implementation

<figure><img src="image_4.png" /><figcaption>**FIGURE 3.** Comparison of energy consumption, CPU, and memory usage between Protobuf and JSON implementations.</figcaption></figure>

using Java Swing consumes 16.27 watts per hour, compared to 0.55 watts for the modern Angular version. This shows that adopting Angular can reduce energy consumption by 30 times compared to legacy Java Swing. At the backend level, moving from a legacy Java implementation to a modern Spring Boot stack increased energy consumption: 3.97 watts per hour for the modern version versus 1.3 for the legacy one. This indicates that Spring Boot's higher processing demands contribute more to overall energy use.

The figure also shows CPU usage across components. On the frontend, the legacy version uses 7.65% of CPU resources, while the modern one uses only 1.95%, reinforcing that Java Swing demands more processing power than Angular. On the backend, the modern version uses 5.15% of the CPU versus 0.94% for the legacy one, indicating that Spring Boot requires more processing and consumes more backend resources overall.

Despite higher energy and CPU usage in the modern backend, the overall system is more efficient due to substantial frontend savings. These results show that replacing Java Swing with Angular greatly improves energy efficiency, supporting the use of modern web technologies.

As the next step in our investigation, we examined how data serialization formats affect energy consumption by comparing Protobuf and JSON implementations. Figure 3 summarizes the results, highlighting energy, CPU, and memory usage for each.

The results show that the Protobuf-based implementation consumed 33% less energy than the JSON version, highlighting its efficiency advantage. Protobuf also processed requests much faster—5.56 seconds
<figure><img src="image_5.png" /><figcaption>**FIGURE 4.** Energy consumption per request and per user as a function of the number of iterations per user</figcaption></figure>

per request versus 27 seconds for JSON—directly contributing to reduced energy usage.

The performance improvement came with higher CPU usage, as Protobuf used over three times more CPU than JSON. This reflects the binary format's overhead, which requires more processing but completes tasks more efficiently.

Memory usage also favors Protobuf, which uses about 10% less memory than JSON, underscoring its efficiency in speed and resource use.

## Impact of usage patterns on energy consumption

Figure 4 shows the energy consumed per request and per user as the number of iterations increases. While the backend remains stable at around $2.0 \times 10^{-4}$ watts per request, the database shows a major efficiency gain, dropping by about 83% between 100,000 and 1,000,000 requests. This suggests improved resource utilization under high load, likely due to caching and connection pooling.

On a per-user basis, the backend shows a steady increase, from $1.15 \times 10^{-1}$ watts per user at 100,000 iterations to more than 1.1 watts at 1,000,000. This rise indicates a decline in efficiency as load scales, likely due to increased CPU demands and resource contention. In contrast, the database maintains lower and more consistent energy use, ranging from 0.05 to 0.25 watts per user. Although it increases slightly at higher loads, the database remains more stable and efficient overall.

These results show that backend components are more sensitive to usage spikes and require optimization to maintain efficiency at scale, whereas database components exhibit better energy stability. This highlights the importance of component-level monitoring for sustainable energy performance in production systems.

## Infrastructure Constraints in Energy Measurement

The infrastructure on which software applications are deployed plays a critical role in the feasibility and accuracy of energy consumption measurement. In modern enterprise environments, applications increasingly run on virtual machines, containers, or cloud platforms for flexibility, scalability, and cost efficiency. At Berger-Levrault, this virtualized infrastructure underpins our deployment strategy but complicates energy measurement. Most tools require low-level hardware information such as CPU activity, memory usage, or power states, which virtual environments hide behind the virtualization layer or cloud provider. As a result, tools like Intel PCM cannot function effectively. JoularJX [12] is limited to Java applications, and Scaphandre [13] does not support Windows or large-scale use. This mismatch between energy tools and real deployments makes it difficult to obtain accurate and actionable energy data.

To overcome this issue, we used Dynatrace Carbon Impact, which estimates energy use in virtualized and cloud environments. Unlike hardware-level tools that require performance-counter access, Dynatrace infers energy consumption by mapping high-level resource metrics (CPU utilization, memory usage, disk I/O, and network traffic) to kWh using internal power models based on the guidelines of the Sustainable Digital Infrastructure Alliance (SDIA), with contributions from the Cloud Carbon Footprint project and Dynatrace's internal research, combined with a Power Usage Effectiveness (PUE) factor [14]. Since low-level hardware data is inaccessible in our virtualized infrastructure and Dynatrace was already deployed at Berger-Levrault, it offered a practical way to integrate energy estimation into the existing monitoring stack. This allowed us to measure energy consumption at scale without changing our infrastructure.

## Recommendation

As industrial settings rely mainly on virtualized and cloud-based infrastructures, integrating energy measurements requires tools that operate at the virtual machine level, since hardware-level counters are typically inaccessible. Tools based on high-level resource metrics and estimation models are therefore more suitable, and when already part of the monitoring ecosystem, make energy measurement practical without modifying the infrastructure.
## Managing Experimental Noise & Monitoring Granularity

A major challenge in industrial setups is conducting experiments in a clean and controlled environment. In our case, the test servers were part of a shared infrastructure used for daily operations. Although the applications under test were isolated, background activity from services, user sessions, or monitoring could still occur. To reduce interference, we scheduled tests during non-working hours, yet system processes and updates introduced variability and noise, complicating attribution of energy consumption to the workloads. We also mitigated noise by repeating experiments and averaging results.

In addition to this, the granularity of monitoring data posed a significant challenge. We adopted the DynaTrace Carbon Impact module due to its compatibility with virtualized and cloud-based environments. However, it reports energy consumption only once per hour, which prevented us from capturing short-term variations or associating specific application events—such as a request spike or component activation—with their energy impact. To compensate, we extended workload durations to average results over time. We also kept the server idle for two hours between tests to stabilize conditions and establish a consistent energy baseline. These steps helped improve the reliability of measurements within the limitations of our monitoring setup.

### Recommendation

To understand software energy behavior, measurements should ideally be performed in an isolated environment. When isolation is not possible, tests should be run during periods of minimal activity and repeated to reduce background noise. With tools such as DYNATRACE that provide hourly updates, an idle period helps establish a baseline, and extending workload duration produces more stable averages.

## Testing Constraints in Legacy System Environments

In industrial settings, software systems often rely on a mix of modern and legacy technologies. At Berger-Levrault, some applications still run on older platforms. One such application was delivered through Citrix, a remote desktop environment commonly used for legacy deployments. Citrix posed key challenges: it was incompatible with most modern workload-generation tools, limiting test automation and scalability, and it imposed short session durations, making

long or continuous tests difficult. These constraints led to fragmented energy measurements that may not reflect real-world performance. To address this, we used NeoLoad, one of the few tools compatible with Citrix-based applications. Although session timeouts remained a limitation, NeoLoad enabled us to perform constrained but valuable energy measurements.

### Recommendation

When dealing with legacy systems such as those relying on Citrix, short session durations imposed for security reasons can limit long-running tests. Practitioners should use workload generators compatible with such systems and design shorter, repeated workloads to mitigate session-timeout constraints. They should also document these limitations clearly so they can be considered when interpreting energy results.

## Workload Generator Constraints

To evaluate the energy consumption of software systems, it is essential to simulate realistic and varied workloads. We selected NeoLoad as our workload generator due to its compatibility with both modern and legacy applications, including those delivered through Citrix. However, NeoLoad presented challenges during our experiments. The main issue was a license limitation that restricted virtual users to 250. This required us to adapt our testing strategy and limited our ability to explore high-concurrency or extreme load scenarios. While 250 users were sufficient for typical enterprise loads, large-scale stress testing was not feasible. We also faced a technical issue when testing the modern application, which required authentication via access tokens. These tokens had a limited lifespan and could expire during long-running tests. To resolve this, we developed a PowerShell script that automatically refreshed tokens during execution, allowing tests to proceed without interruption.

To work around the user limit, we fixed the number of virtual users at 250 and varied the workload by adjusting request volume and execution time. This approach allowed us to simulate diverse usage patterns and produce meaningful, realistic workload scenarios despite the constraints.

### Recommendation

In most industrial settings, session durations are kept short for security reasons, giving authentication tokens short lifespans. Practitioners should implement automated renewal scripts to avoid test interruptions.
1. Workload-generator licenses often limit virtual users,

2. so experiments should vary request volume and execution time rather than rely solely on high user counts.

3.

## Inconsistent Deployment Environments Across Test Applications

5. In production environments, software systems are often deployed using different architectures based on organizational needs. This was the case at Berger-Levrault, where the tested applications were not deployed under identical conditions. One application ran on two separate servers, while another used a load balancer on the frontend or backend. These differences affected infrastructure behavior and resource distribution, complicating our energy measurement methodology.

6.

7. This was the case at Berger-Levrault, where the tested applications were not deployed under identical conditions. One application ran on two separate servers, while another used a load balancer on the frontend or backend. These differences affected infrastructure behavior and resource distribution, complicating our energy measurement methodology.

8.

9. One application ran on two separate servers, while another used a load balancer on the frontend or backend. These differences affected infrastructure behavior and resource distribution, complicating our energy measurement methodology.

10.

11. These differences affected infrastructure behavior and resource distribution, complicating our energy measurement methodology.

12.

13. Complicating our energy measurement methodology.

14.

15. These variations created two main issues. First,

16. multi-server hosting caused inconsistent resource allocation, making it difficult to attribute energy consumption to a specific component. Second, load balancers introduced traffic variability, making measurements less predictable as server load could shift during execution.

17.

18. Second, load balancers introduced traffic variability, making measurements less predictable as server load could shift during execution.

19.

20. To address these limitations, we adapted our process to the existing deployment. Standardizing environments would have required major infrastructure changes beyond our scope. Instead, we documented each application's architecture and accounted for these differences in our analysis. We avoided direct comparisons between differently deployed applications and focused on comparing versions within the same environment to ensure fair and meaningful conclusions.

21.

22. To address these limitations, we adapted our process to the existing deployment. Standardizing environments would have required major infrastructure changes beyond our scope. Instead, we documented each application's architecture and accounted for these differences in our analysis. We avoided direct comparisons between differently deployed applications and focused on comparing versions within the same environment to ensure fair and meaningful conclusions.

23.

24. Standardizing environments would have required major infrastructure changes beyond our scope. Instead, we documented each application's architecture and accounted for these differences in our analysis. We avoided direct comparisons between differently deployed applications and focused on comparing versions within the same environment to ensure fair and meaningful conclusions.

25.

26. To address these limitations, we adapted our process to the existing deployment. Standardizing environments would have required major infrastructure changes beyond our scope. Instead, we documented each application's architecture and accounted for these differences in our analysis. We avoided direct comparisons between differently deployed applications and focused on comparing versions within the same environment to ensure fair and meaningful conclusions.

27.

28. We avoided direct comparisons between differently deployed applications and focused on comparing versions within the same environment to ensure fair and meaningful conclusions.

29.

30. Similarly, the backend comparison reflects the old versus the migrated version of the same application, not a scientific comparison of two isolated frameworks.

31.

32. Similarly, the backend comparison reflects the old versus the migrated version of the same application, not a scientific comparison of two isolated frameworks.

33.

## Recommendation

34. A characteristic of industrial setups is the presence of heterogeneous architectures. When possible, practitioners should deploy different versions of the same software on similar infrastructures to enable fair energy comparisons. When load balancers are present, teams should monitor traffic distribution during tests to understand its impact on measured energy. When infrastructure cannot be standardized, these constraints should be documented and considered in the analysis to ensure the correct interpretation of results.

35.

36.

37. When possible, practitioners should deploy different versions of the same software on similar infrastructures to enable fair energy comparisons. When load balancers are present, teams should monitor traffic distribution during tests to understand its impact on measured energy. When infrastructure cannot be standardized, these constraints should be documented and considered in the analysis to ensure the correct interpretation of results.

38.

39.

40. When load balancers are present, teams should monitor traffic distribution during tests to understand its impact on measured energy. When infrastructure cannot be standardized, these constraints should be documented and considered in the analysis to ensure the correct interpretation of results.

41.

42.

43.

## Threats to validity and Practical implications

1

### Threats to validity

2

Energy measurements in industrial environments are affected by constraints that make full experimental control difficult. Due to infrastructure policies, our experiments were executed on shared servers where background processes and concurrent activities could still occur, even when tests were run during non-working hours with an idle baseline. As a result, measurements could still be influenced by residual system activity and noise. Moreover, the hourly updates provided by the Dynatrace Carbon Impact module reduce the precision of the observed energy behaviour, as short variations can go unnoticed. To address this, we extended the duration of our experiments to ensure more reliable measurements. Finally, the workloads used to study behaviour under alternative usage patterns were limited by licence constraints, making them less representative of real user behaviour and potentially leading to scaling effects that differ from real-world conditions. Taken together, these factors constitute internal threats to validity that may influence the precision and reliability of the measured energy behaviour. In this study, the experiments were conducted on a specific application running within Berger-Levrault's infrastructure, which, although complex and realistic, remains unique to this environment and may not fully represent other applications or operational contexts. As a result, the observed energy insights cannot be directly transferred to other environments with different technologies or characteristics, forming an external threat to validity.

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

### Practical implications

33

This study presented a methodology that provides practitioners with insights into how design decisions affect energy consumption and how software behaves under variable workloads. The methodology can be integrated into industrial development workflows, allowing energy checks to be added alongside existing CI/CD pipelines. The results also show that modernizing legacy systems can lead to more energy-efficient applications, suggesting that adopting modern technology stacks is beneficial. A more heterogeneous infrastructure can also help teams better evaluate architectural efficiency under realistic execution conditions.

34

35

36

37

38

39

40

41

42

43

44

45
Conclusion

We presented a methodology for measuring web ap-
plication energy consumption in industrial settings,
applied at Berger-Levrault. Our approach assessed
design impacts and analysed usage patterns using
Dynatrace Carbon Impact and NeoLoad. Challenges
included virtualization limits, coarse monitoring, legacy
systems, and deployment inconsistencies, highlighting
the gap between research-oriented approaches and in-
dustrial practice. Our results showed notable energy ef-
ficiency gains. Angular reduced frontend energy use by
30%, while Spring Boot increased backend usage but
improved overall efficiency. Switching to Protobuf cut
energy use by 33% due to faster processing and lower
memory use. These insights emphasise the need for
energy-aware tools in real-world settings. Future work
will focus on detecting code-level energy impacts and
promoting efficient technologies like Protobuf across
diverse systems.

REFERENCES

1. A. Čolaković, "Lot systems modeling and performance evaluation," *Computer Science Review*, vol. 50, p. 100598, 2023.

2. H. Ferreboeuf, M. Efovi-Hess, and X. Verne, "Environmental impact of digital: 5-year trends and 5g governance," The Shift Project, Tech. Rep., 2021.

3. French Government / ADEME / ARCEP, "Act no. 2021-1485 of 15 november 2021 aiming to reduce the environmental footprint of digital activity in france," 2021, english summary available via InCyber.org ("Act No. 2021-1485 to reduce the environmental footprint of the digital sector in France"). [Online]. Available: https://incyber.org/en/article/act-no-2021-1485-to-reduce-the-environmental-footprint-of-the-digital-sector-in-france

4. D. Feitosa, R. Alders, A. Ampatzoglou, P. Avgeriou, and E. Y. Nakagawa, "Investigating the effect of design patterns on energy consumption," *Journal of Software: Evolution and Process*, vol. 29, no. 2, p. e1851, 2017.

5. D. C. Connolly Bree and M. O. Cinnéide, "The energy cost of the visitor pattern," in *2022 IEEE International Conference on Software Maintenance and Evolution (ICSME)*, 2022, pp. 317–328.

6. V. Herwig, R. Fischer, and P. Braun, "Assessment of rest and websocket in regards to their energy consumption for mobile applications," in *2015 IEEE 8th International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS)*, vol. 1, 2015, pp. 342–347.

7. K. T. G. Daniél Garrido-Y Martinez Nielsen, "Energy consumption of software architectures a comparison between microservice and monolithic architectures in c# and java," Master's thesis, Aalborg University, 2010.

8. L. Khrouf, A. Shatnawi, B. T. Niang, and B. Verhaeghe, "On the energy consumption of web applications: An empirical study of their design solutions," in *Proceedings of the 13th International Workshop on Green and Sustainable Software (GREENS)*. IEEE, 2025.

9. Dynatrace, “Cost and carbon optimization in dynatrace,” https://docs.dynatrace.com/docs/observe/business-analytics/apps/cost-and-carbon-optimization#get-started--concepts, 2024, accessed June 2025.

10. G. Darbord, B. Verhaeghe, A. Etien, N. Anquetil, A. Shatnawi, A. Seriai, and M. Derras, "Migrating the communication protocol of client-server applications," *IEEE Software*, vol. 40, no. 4, pp. 11–18, 2023.

11. A. Shatnawi, A. Bahri, B. Niang, and B. Verhaeghe, "Enhancing data serialization efficiency in rest services: Migrating from json to protocol buffers," in *Proceedings of the 20th International Conference on Software Technologies - Volume 1: ICSOFT, INSTICC. SciTePress*, 2025, pp. 193–200.

12. A. Noureddine, "PowerJoular and JoularJX: Multi-Platform Software Power Monitoring Tools," in *18th International Conference on Intelligent Environments, Biarritz, France*, Jun. 2022. [Online]. Available: https://hal.science/hal-03608223

13. "Scaphandre." [Online]. Available: https://github.com/hubblo-org/scaphandre

14. Dynatrace Documentation, "Cost and carbon optimization," https://docs.dynatrace.com/docs/observe/business-observability/cost-and-carbon-optimization#concepts.

<figure><img src="image_6.png" /></figure>

**Louay Khrouf** is a PhD student at the Spirals team of Inria Lille and a research engineer at Berger-Levrault. Contact him at **Louay.KHROUF@berger-levrault.com**.

<figure><img src="image_7.png" /></figure>

**Anas Shatnawi** is a research engineer at Berger-Levrault. Contact him at **Anas.SHATNAWI@berger-levrault.com**.

<figure><img src="image_8.png" /></figure>

**Romain Rouvoy** Full Professor of Computer Science at the University of Lille / CNRS / Inria, France

Contact him at
**romain.rouvoy@univ-lille.fr**

<figure><img src="image_9.png" /></figure>

**Benoit Verhaeghe** is a research engineer at Berger-Levrault. Contact him at **benoit.verhaeghe@berger-levrault.com**.

<figure><img src="image_10.png" /></figure>

**Boubou Thiam NIANG** is a research engineer at Berger-Levrault. Contact him at **BoubouThiam.NIANG@berger-levrault.com**.