Sustainable software development, often called green coding, means delivering the same functionality with less CPU load, less memory and less data transfer. Using fewer resources lowers power consumption and the need for cooling in data centers, and with it the carbon footprint. Concrete levers include optimizing images on the web, targeted profiling in the backend and switching off processes nobody uses.
Key Takeaways
- Reducing the pixel dimensions, lowering the quality setting and blurring the background shrinks a 3-megabyte image to 86 kilobytes, a saving of around 97 percent with comparable visual quality.
- Faster code uses less CPU and produces less heat, which also cuts cooling in the data center. That shows up directly in the carbon footprint and in the cloud bill.
- Optimization patterns you apply every day no longer need to be measured each time. With one person-week of effort, Carlos Fernandez made an application start 35 percent faster.
- Auto-refresh functions keep running in the background even when nobody is looking at the window, producing a constant stream of unnecessary requests and resource use.
- Software can be set up to run compute-heavy tasks preferably when an API shows that plenty of green electricity is on the grid.
Green Coding: Performance and Sustainability Are the Same Problem
Make software faster, and you almost automatically shrink its carbon footprint. That is the practical core of sustainable software: the same functionality runs on less CPU and less memory. Less computing means less electricity, and less electricity means fewer emissions.
This link is the lever developers can actually pull. Sustainability doesn’t have to be sold as one more obligation when it can travel under the banner of performance work. Carlos Fernandez, a software developer and performance tester at DATEV, has worked right at this intersection for more than 25 years.
There’s one caveat. Not every performance gain helps the environment. If you simply put a second server next to the first, you get faster but consume more. The green software approach is to do the same job with fewer resources, not with more hardware.
Why Modern Software Wastes So Many Resources
Software today is written as if memory were unlimited. In the DOS days, developers watched every byte and fought with the 640-kilobyte limit. With 64-bit applications, that limit seems to have vanished and memory looks practically infinite.
That impression is wrong. Your program isn’t the only one on the machine. All processes share the CPU and memory, and every new version of Windows wants more. Sixteen gigabytes turn into 32, and at some point even that isn’t enough.
The same carelessness applies to bandwidth. How much data does an application really send when it talks to other machines? Hardly anyone asks. Being frugal with memory, CPU and bandwidth isn’t a nostalgic hobby. It is the basis of software that goes easy on resources.
How to Cut Image Sizes on the Web by Up to 97 Percent
Images are the biggest and easiest lever on the web. A photo from a good camera quickly reaches 12 megapixels, roughly 3,000 by 4,000 pixels. No screen shows it at that resolution. A typical monitor is about 1,900 pixels wide.
If the site serves the original 12-megapixel photo, every visitor downloads around 3 megabytes before the browser scales the image down. That data is wasted. Three adjustments shrink it dramatically, and combining them has the biggest effect:
| Measure | Effect |
|---|---|
| Resize the image in advance | The image is stored at the resolution actually needed |
| Lower the JPEG quality (e.g., to 50 %) | Often no visible difference, much smaller file |
| Blur the background (portrait mode) | From 3 MB to around 1.5 MB at the same pixel count |
| All steps combined | From 3 MB to 86 kilobytes |
In the end you save around 97 percent, and thanks to the focus effect, the image often looks even better. The real impact comes from scale. A website isn’t built for one user but for hundreds of thousands. The more requests, the more every saved kilobyte multiplies.
Where the Web Still Wastes Resources
Beyond images, it pays to look at video, code and unnecessary traffic. Turn off autoplay on websites, because a video that starts by itself eats bandwidth even when nobody watches it. For downloads, simply showing the file size before the download starts already helps.
For icons and graphics that aren’t photorealistic, vector graphics are the better choice. SVGs scale, don’t lose quality when enlarged and are much smaller than PNGs.
Auto-refresh mechanisms are a hidden problem. A developer sets an interval, say every second or twice a minute, and forgets that the user isn’t sitting in front of the window all the time. The refresh keeps running in the background and fires requests nobody needs.
The diagnosis comes built in and free. Press F12 in Chrome or Edge to open the developer tools. There you can see how many requests a page makes, how much data it transfers and which requests end in a 404. CSS helps as well, by keeping styles in one place instead of scattering them across the HTML.
Performance Patterns Belong in Everyday Work, Not in an Optimization Project
The most effective optimization happens while you write the code, not in a big cleanup project afterward. The usual rule is measure, improve, measure again. For big problems that’s right: you reach for a profiler and start with the largest chunks, not with micro-optimizations.
But once you have worked on performance long enough, you build up a repertoire of patterns that don’t need profiling anymore. One example from the .NET world: use TryGetValue on a dictionary instead of calling Contains first and then Get. That saves around 30 percent at that spot and costs nothing extra once it’s a habit.
Habits like these spare you from fixing every spot one by one later. If you write this way from the start, the optimization is built in.
Don’t forget the tests. Tests are often thrown together by copy and paste, and UI tests in particular run slowly because they have to wait for fields. Unit tests without a UI manage several thousand runs per second when the tests are short. You’ll never get that volume through the user interface.
The Performance Lens Changes How You Read Code
Once you’ve spent serious time on performance, you read code differently. In code reviews or in someone else’s code, you spot optimization potential almost in passing. You don’t necessarily bring it up right away. You make a mental note.
Those notes become a stockpile of quick wins. When the product owner asks for fast improvements, you already know where to look. In one case, a single person-week of work made an application start 35 percent faster. It wasn’t one big fix but several small ones.
A person-week is next to nothing in development time. That is exactly what makes optimizations like this easy to sell, because pure performance work quickly gets labeled expensive and time-consuming while features take priority.
Shifting Workloads to When Green Electricity Is Available
Software can schedule its load around the availability of green electricity. Public services show, for all of Europe, where and how much electricity is currently being generated from renewables, and they offer an API.
That lets you move work around. Not every workload has to be processed the moment it arrives. If you smooth out peak loads, you can handle larger volumes when green electricity is plentiful. If you don’t want to connect to an API, simply restrict heavy jobs to certain times of day and do less at night.
Why Efficient Software Also Cuts Cloud Costs
In the backend, the path runs through profiling. Lower CPU usage sets off a whole chain: less electricity, less heat, less cooling, and therefore less power for the air conditioning in the data center. That is how the software carbon footprint shrinks in practice.
In the cloud era, this turns straight into money. Providers such as AWS, Google or Azure bill by CPU, memory and bytes transferred. Work more efficiently, and you see it on the monthly bill right away. Ecology and economics line up.
“When we improve the performance of software, we simply get the same functionality with fewer resources, less CPU, less memory. And using less electricity is good for the carbon footprint.”
(Carlos Fernandez)
The cloud has watered down this awareness. In your own data center, every extra machine used to be a visible investment planned over months. Today you push a slider up and get another instance. The hardware behind it is still real and finite: every host has a fixed number of CPUs and a fixed amount of memory. Size it too small, and you hit limits. Size it too large, and servers sit idle while still drawing power.
Sustainability Grows from the Bottom Up, Not Only from the Top Down
Many people haven’t caught on to the topic yet, so it takes persuasion inside the organization. At DATEV, a Green Community of Practice with around 200 members does that work, covering not only software but also procurement and other areas. A smaller sub-team focuses specifically on sustainable software.
Strategic goals from the top help, but it takes time before they are broken down to the individual developer. If you don’t want to wait, you do the persuading from the bottom up. An internal speaking platform, run by a Software Craft Community with almost 1,500 members, exists for exactly that: developers passing tips and guidelines on to other developers.
Pressure now comes from outside, too. An energy efficiency law requires organizations that run a data center to disclose certain metrics. The growing interest in sustainable software draws on both: people’s own drive and legal obligation.
Where to Start with Sustainable Software
Where you start depends on where you work. On the web, start with network traffic. How many requests does the page make, how much data goes over the wire, which requests take long or lead nowhere? Outdated JavaScript libraries, bloated HTML and unused resources are the first candidates.
In the backend, profiling is the way in. Decide what you want to measure, optimize in a targeted way and check afterward whether it made a difference. Keep the direction in mind: the goal is the same functionality with less CPU and less memory, not more speed from more hardware.
Small things around the company add up as well. Turn off monitors and lights in the evening, switch off devices overnight and over holidays, and think about location when it comes to 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 escape.
Frequently Asked Questions
Does faster software automatically result in a smaller carbon footprint?
Most of the time, yes, but not necessarily. Achieving the same functionality with less CPU and less RAM reduces power consumption and thus emissions. On the other hand, if you gain speed by adding a second server, you’ll go faster but consume more power. The key is the approach: performing the same task with fewer resources, not with additional hardware.
Is memory consumption even an issue anymore with modern 64-bit applications?
Yes. The impression of unlimited memory is misleading because a program never has the machine to itself. All processes share the CPU and main memory, and every new operating system version demands more: 16 gigabytes become 32, and eventually even that won’t be enough. The same applies to bandwidth, the consumption of which is rarely even measured during cross-computer communication.
Is it worth resizing photos before embedding them in a website?
The effect is significant. A 12-megapixel photo is about 3 megabytes, even though a typical monitor displays only about 1,900 pixels in width. Adjusting the pixel size beforehand, reducing the JPEG quality to about 50 percent, and blurring the background reduces the file size to 86 kilobytes. With hundreds of thousands of requests, every kilobyte saved adds up.
Why are autoplay and auto-refresh considered a waste of resources?
Both generate load that no one uses. An automatically playing video consumes bandwidth, even if no one is watching it. An auto-refresh with a fixed interval (such as every second or twice per minute) continues to run in the background even when the user isn’t looking at the window at all. These requests occur continuously and provide no value in return.
Does every optimization have to start with a measurement?
Not every one. For major issues, the rule is: measure, improve, measure again, using a profiler and starting with the biggest problems rather than micro-optimizations. However, those who have been working on performance for a long time recognize patterns that no longer require profiling. In .NET, for example, use TryGetValue with a dictionary instead of Contains followed by Get: that alone saves about 30 percent here.
Can software schedule its computational work based on the availability of green energy?
Yes. Public services show, for all of Europe, exactly how much electricity is currently being generated from renewable sources, complete with an API for querying this data. This allows peak loads to be shifted, rather than processing every task the moment it arises. Those who don’t want to integrate an API can limit heavy tasks to specific times and run fewer computations at night.
Why does resource-efficient code directly impact cloud billing?
Because providers like AWS, Google, or Azure bill based on CPU usage, main memory, and bytes transferred. Lower CPU usage triggers a chain reaction: less electricity, less heat, and less cooling required in the data center. While a new instance can be quickly added using an autoscaler, the underlying hardware remains limited, and oversized servers still consume power even when idle.
