Sustainable software development means delivering the same functionality with less CPU load, less memory and less data transfer. Lower resource consumption reduces electricity use and cooling requirements in data centers, shrinking the carbon footprint. Practical levers include image optimization on the web, targeted backend profiling and switching off unused processes.
Key Takeaways
- Reducing an image’s pixel dimensions, adjusting its quality and blurring its background can shrink a 3-megabyte file to 86 kilobytes: a saving of around 97 percent with equivalent visual quality.
- Better-performing code uses less CPU, generates less heat and reduces the cooling required in the data center. This directly lowers both the carbon footprint and the cloud bill.
- Once certain optimization patterns become part of daily work, they no longer need to be measured every time. With one person-week of effort, Carlos Fernandez improved an application’s startup time by 35 percent.
- Auto-refresh functions keep running in the background even when nobody is looking at the window, continuously generating unnecessary requests and consuming resources.
- Software can schedule compute-intensive tasks for times when an API shows that plenty of green electricity is available on the grid.
Performance and sustainability are two sides of the same problem
Improving a piece of software’s performance almost automatically reduces its carbon footprint. The same functionality then runs with less CPU and less memory. Less computation means less electricity use, and less electricity use means fewer emissions.
This connection gives developers a practical lever. Sustainability does not have to be sold as an additional obligation when it can be approached as performance work. Carlos Fernandez, a software developer and performance tester at DATEV, has worked at precisely this intersection for more than 25 years.
There is one important qualification: not every performance improvement helps the environment. Simply adding a second server may make a system faster, but it also consumes more resources. The sustainable approach is to complete the same task with fewer resources, not with more hardware.
Why modern software wastes resources
Software today is written as if memory were unlimited. In the days of DOS, developers watched every byte and wrestled with the 640-kilobyte limit. With 64-bit applications, that boundary appears to have disappeared and memory seems practically infinite.
That impression is misleading. Your program is not the only one running on the machine. All processes share the CPU and memory, and every version of Windows needs more. Sixteen gigabytes become 32, and eventually even that is no longer enough.
The same carelessness applies to bandwidth. How much data does an application actually transfer when communicating across computers? The question is rarely asked. Economical use of memory, CPU and bandwidth is not a nostalgic hobby; it is the foundation of resource-efficient software.
How to reduce web images by up to 97 percent
Images are the biggest and easiest lever on the web. A photo from a good camera can easily contain 12 megapixels, roughly 3,000 by 4,000 pixels. No screen displays it at that resolution; a typical monitor is about 1,900 pixels wide.
If the website serves the original 12-megapixel photo, every visitor downloads around 3 megabytes before the browser scales it down. That data is wasted. Four adjustments reduce it dramatically:
| Measure | Effect |
|---|---|
| Resize the image in advance | Store the image at the resolution that is actually needed |
| Lower JPEG quality, for example to 50 percent | Often no visible difference, but a much smaller file |
| Blur the background in portrait mode | Reduce 3 MB to around 1.5 MB at the same pixel dimensions |
| Combine all steps | Reduce 3 MB to 86 kilobytes |
The result is a saving of around 90 percent, and focusing the image can even make it look better. The real impact comes from scale: a website is not built for one user, but for hundreds of thousands. The more requests it receives, the more every saved kilobyte adds up.
Where the web wastes further resources
Beyond images, it is worth looking at videos, code and unnecessary data transfers. Autoplay should be disabled on websites because an automatically starting video uses bandwidth even when nobody watches it. For downloads, simply stating the file size before the transfer starts already helps.
Vector graphics are the better choice for icons and non-photorealistic graphics. SVGs are scalable, retain their quality when enlarged and are significantly smaller than PNGs.
Auto-refresh mechanisms are a hidden problem. A developer defines an interval, perhaps once per second or twice per minute, but forgets that the user does not sit in front of the window permanently. The refresh continues in the background and generates requests nobody needs.
The diagnostic tools are built in and free. Pressing F12 opens the developer tools in Chrome and Edge. They show how many requests a page makes, how much data it transfers and which requests end in a 404 response. CSS also helps by consolidating styles instead of scattering them throughout the HTML.
Performance patterns belong in daily work, not in a separate optimization project
The most effective optimization happens while the software is being written, not in a large downstream project. The usual rule is: measure, improve and measure again. That is correct for major problems, where you use a profiler and start with the biggest issues rather than micro-optimizations.
After working on performance for long enough, however, you develop a repertoire of patterns that no longer require profiling. One example from the .NET world is using TryGetValue for a dictionary instead of calling Contains first and then Get. This saves around 30 percent at that point and adds no effort once it becomes routine.
These habits prevent the need to improve every location later. If you think this way from the beginning, you build the optimization in from the start.
Do not forget the tests. Tests are often assembled by copy and paste, and UI tests in particular run slowly because they have to wait for fields. Unit tests without a user interface can execute several thousand short tests per second. That volume cannot be achieved through the UI.
The performance lens changes how you read code
Anyone who works intensively with performance starts reading code differently. During code reviews or while looking at unfamiliar code, optimization opportunities become visible almost incidentally, even if you do not raise them immediately. You remember them.
That accumulated knowledge becomes a store of quick wins. When the product owner asks for rapid improvements, you already know where to look. In one case, one person-week of work improved an application’s startup time by 35 percent. There was no single large change, but several small interventions.
One person-week is almost nothing in development time. That is precisely what makes such optimizations easy to justify. Pure performance work is quickly perceived as expensive and time-consuming, while features take priority.
Green electricity as a control signal for computing work
Software can align its load with the availability of green electricity. Public services show how much renewable electricity is currently being generated across Europe and provide this information through an API.
That makes it possible to shift work. Not every workload has to be processed at the moment it is created. Systems that balance peak loads can process larger volumes when plenty of green electricity is available. If you do not want to integrate an API, you can simply limit heavy tasks to certain times and do less at night.
Efficiency saves electricity and money
On the backend, profiling is the way forward. Lower CPU use starts a chain reaction: less electricity, less heat, less cooling and therefore less electricity for air conditioning in the data center.
In the cloud era, that translates directly into money. Providers such as AWS, Google and Azure charge for CPU, memory and transferred bytes. Working more efficiently with resources becomes visible on the monthly bill. Ecology and economics coincide.
When we improve the performance of software, we deliver the same functionality with fewer resources, less CPU and less memory. And lower electricity consumption is good for the carbon footprint. — Carlos Fernandez
The cloud has weakened this awareness. In the past, every additional machine in an organization’s own data center was a visible investment planned over months. Today, you move a slider and get another instance. The hardware behind it remains real and limited: every host has a fixed number of CPUs and a fixed amount of memory. If it is undersized, you hit limits; if it is oversized, servers sit idle and still consume electricity.
Sustainability spreads from the bottom up, not only from the top down
The topic has not yet reached everyone, so organizations need internal advocacy. DATEV has a Green Community of Practice with around 200 members that covers not only software but also procurement and other areas. A smaller sub-team focuses specifically on sustainable software.
Strategic goals from management are helpful, but they take time to reach individual developers in concrete form. People who do not want to wait can advocate from the bottom up. An internal presentation platform supported by a Software Craft Community of almost 1,500 members exists for exactly this purpose: developers share tips and guidelines with other developers.
Pressure is also coming from outside. Energy-efficiency legislation requires certain indicators to be disclosed by organizations that operate a data center. The growing interest in sustainable software therefore comes from both intrinsic motivation and legal obligations.
Where to start
The best starting point depends on where you work. On the web, begin with network traffic: How many requests does the page make? How much data is transferred? Which requests are slow or go nowhere? Outdated JavaScript libraries, bloated HTML and unused resources are the first candidates.
On the backend, start with profiling. Decide what you want to measure, optimize it deliberately and then check whether the change helped. Keep the direction clear: the goal is the same functionality with less CPU and memory, not more performance through more hardware.
Small actions across the organization also add up. Switch off monitors and lights in the evening, turn off devices overnight and on public holidays, and consider location when planning data centers. A data center in Finland needs less cooling than one in a warm region. Heat recovery captures waste heat instead of letting it dissipate.
