Software has a carbon footprint. Every CPU cycle consumes electricity, and that electricity has a carbon intensity that varies by grid, time of day, and energy source. For a PHP application handling millions of requests, the cumulative energy consumption is significant. Our PHP Energy tool was born from a simple question: how much energy does a specific PHP function consume, and how can we reduce it?
The Software Carbon Intensity (SCI) specification from the Green Software Foundation provides a framework for measuring software emissions. The formula considers the energy consumed by the application, the carbon intensity of the electricity grid, the embodied carbon of the hardware, and the functional unit of measurement. For a PHP API, a useful functional unit is energy per request. For a batch processing system, it might be energy per record processed.
You cannot reduce what you do not measure. Software energy consumption starts with visibility.
Our PHP Energy tool measures energy consumption at the function level using hardware performance counters available through the RAPL (Running Average Power Limit) interface on modern Intel and AMD processors. By instrumenting specific code paths, you can compare the energy cost of different implementations. We have found that optimised code is not just faster; it frequently uses 30-60% less energy. This is because energy consumption correlates strongly with CPU cycles, memory allocations, and I/O operations.
Practical Measurement Techniques
The most impactful optimisations are often the simplest. Reducing unnecessary database queries, implementing proper caching, and avoiding repeated computation have the largest effect on both performance and energy consumption. In one client project, replacing a series of individual database queries with a single batch query reduced the energy cost of the operation by 72%. The code was also simpler and faster, which demonstrates that green software engineering and good software engineering are fundamentally the same discipline.
For organisations beginning to measure their software carbon footprint, we recommend starting with your highest-traffic endpoints. Profile energy consumption under realistic load conditions, identify the most energy-intensive operations, and optimise them. Then expand measurement to cover the rest of your application. The goal is not perfection but continuous improvement, treating energy efficiency as a metric alongside performance, reliability, and cost.
- Use the SCI specification as a framework for measuring software carbon intensity
- Profile energy consumption at the function level using RAPL hardware counters
- Start with your highest-traffic endpoints for the biggest impact
- Optimise database queries, caching, and computation as the primary energy savings levers
- Include software energy consumption in your organisation's sustainability reporting
- Treat energy efficiency as a continuous improvement metric alongside performance
Reporting is essential for accountability. We generate energy consumption reports that map to the GHG Protocol Scope 2 and Scope 3 categories, which allows organisations to include software energy in their broader sustainability reporting. As regulatory requirements around carbon reporting increase, organisations that have already established measurement practices will be well-positioned to comply.
