Nachhaltige Softwareentwicklung, oft Green Coding genannt, bedeutet, dieselbe Funktionalität mit weniger CPU-Last, weniger Hauptspeicher und geringerer Datenübertragung zu erreichen. Weniger Ressourcenverbrauch senkt den Stromverbrauch, reduziert den Kühlbedarf in Rechenzentren und damit den CO2-Fußabdruck. Konkrete Hebel sind Bildoptimierung im Web, gezieltes Profiling im Backend und das Abschalten ungenutzter Prozesse.
Das Wichtigste in Kürze
- Wer ein Bild von 3 Megabyte durch Pixelreduktion, Qualitätsanpassung und Hintergrundunschärfe optimiert, kommt auf 86 Kilobyte: eine Einsparung von rund 97 Prozent bei gleichwertiger optischer Qualität.
- Performanterer Code verbraucht weniger CPU, erzeugt weniger Wärme und senkt damit auch den Kühlaufwand im Rechenzentrum, was sich direkt im CO2-Fußabdruck und in der Cloud-Rechnung niederschlägt.
- Wer bestimmte Optimierungsmuster täglich anwendet, muss sie nicht mehr messen: Mit einer Personenwoche Aufwand konnte Carlos Fernandez den Start einer Anwendung um 35 Prozent verbessern.
- Auto-Refresh-Funktionen laufen im Hintergrund weiter, auch wenn kein Nutzer das Fenster betrachtet, und erzeugen so dauerhaft unnötige Requests und Ressourcenverbrauch.
- Software lässt sich so steuern, dass rechenintensive Aufgaben bevorzugt dann laufen, wenn laut API gerade viel grüner Strom im Netz verfügbar ist.
Green Coding: Performance und Nachhaltigkeit sind dasselbe Problem
Wer die Performance einer Software verbessert, senkt fast automatisch ihren CO2-Fußabdruck. Die gleiche Funktionalität läuft dann mit weniger CPU und weniger Hauptspeicher. Weniger Rechenarbeit bedeutet weniger Stromverbrauch, und weniger Stromverbrauch heißt weniger Emissionen.
Diese Kopplung ist der praktische Hebel für Entwickler. Nachhaltigkeit muss nicht als zusätzliche Pflicht verkauft werden, wenn sie sich als Performance-Arbeit tarnen lässt. Carlos Fernandez, Softwareentwickler und Performance-Tester bei der DATEV, arbeitet seit über 25 Jahren an genau dieser Schnittstelle.
Eine Einschränkung gehört dazu: Nicht jede Performance-Verbesserung dient der Umwelt. Wer einfach einen zweiten Server danebenstellt, wird schneller, verbraucht aber mehr. Der nachhaltige Ansatz heißt, dieselbe Aufgabe mit weniger Ressourcen zu erledigen, nicht mit mehr Hardware.
Warum moderne Software zu verschwenderisch mit Ressourcen umgeht
Software wird heute geschrieben, als wäre Speicher unbegrenzt. Zu DOS-Zeiten hat man auf jedes Byte geschaut und um die 640-Kilobyte-Grenze gekämpft. Mit 64-Bit-Anwendungen scheint diese Grenze verschwunden, der Speicher praktisch unendlich.
Dieser Eindruck täuscht. Du bist nicht das einzige Programm auf der Maschine. CPU und Hauptspeicher müssen sich alle Prozesse teilen, und jede Windows-Version verlangt mehr. Aus 16 Gigabyte werden 32, und irgendwann reicht auch das nicht.
Der gleiche Leichtsinn betrifft die Bandbreite. Wie viel überträgt eine Anwendung wirklich bei rechnerübergreifender Kommunikation? Diese Frage wird selten gestellt. Sparsamkeit bei Speicher, CPU und Bandbreite ist kein nostalgisches Hobby, sondern die Grundlage für ressourcenschonende Software.
Wie sich bei Bildern im Web bis zu 97 Prozent einsparen lassen
Bilder sind der größte und einfachste Hebel im Web. Ein Foto aus einer guten Kamera hat schnell 12 Megapixel, also rund 3000 mal 4000 Pixel. Kein Bildschirm zeigt das in dieser Auflösung, ein typischer Monitor schafft etwa 1900 Pixel in der Breite.
Liegt das Originalfoto mit 12 Megapixeln auf der Webseite, lädt jeder Besucher rund 3 Megabyte herunter, bevor der Browser das Bild herunterskaliert. Diese Daten sind verschenkt. Drei Stellschrauben reduzieren das drastisch:
| Maßnahme | Wirkung |
|---|---|
| Pixelgröße vorab anpassen | Bild wird in der tatsächlich benötigten Auflösung abgelegt |
| JPEG-Qualität senken (z. B. auf 50 %) | oft kein sichtbarer Unterschied, deutlich kleinere Datei |
| Hintergrund unscharf (Portrait-Modus) | von 3 MB auf rund 1,5 MB bei gleicher Pixelzahl |
| Kombination aller Schritte | von 3 MB auf 86 Kilobyte |
Am Ende steht eine Ersparnis von rund 97 Prozent, und das Bild sieht durch den Fokus oft sogar besser aus. Der eigentliche Effekt entsteht durch Skalierung: Eine Webseite wird nicht für einen Nutzer geschrieben, sondern für hunderttausende. Je mehr Requests, desto stärker multipliziert sich jedes gesparte Kilobyte.
Wo das Web noch Ressourcen verschwendet
Neben Bildern lohnt der Blick auf Videos, Code und unnötigen Datenverkehr. Autoplay auf Webseiten gehört abgeschaltet, denn ein automatisch startendes Video kostet Bandbreite, auch wenn niemand es ansieht. Bei Downloads hilft schon der Hinweis, wie groß eine Datei ist, bevor sie geladen wird.
Für Icons und nicht-fotorealistische Grafiken sind Vektorgrafiken die bessere Wahl. SVGs sind skalierbar, verlieren beim Vergrößern keine Qualität und sind deutlich kleiner als PNGs.
Ein verstecktes Problem sind Auto-Refresh-Mechanismen. Ein Entwickler legt ein Intervall fest, etwa jede Sekunde oder zweimal pro Minute. Vergessen wird dabei, dass der Nutzer nicht permanent vor dem Fenster sitzt. Der Refresh läuft im Hintergrund weiter und erzeugt Requests, die niemand braucht.
Die Diagnose ist kostenlos eingebaut. Mit F12 öffnet sich in Chrome und Edge das Developer-Window. Dort siehst du, wie viele Requests eine Seite macht, welches Volumen übertragen wird und welche Requests mit Status 404 ins Leere laufen. Auch CSS hilft, indem Styles dort gebündelt werden statt verstreut im HTML.
Performance-Patterns gehören in den Alltag, nicht in ein Optimierungsprojekt
Die wirksamste Optimierung passiert während des Programmierens, nicht in einem nachgelagerten Großprojekt. Die übliche Regel lautet: messen, verbessern, wieder messen. Bei großen Problemen ist das richtig, hier setzt man mit einem Profiler an und fängt bei den größten Brocken an, nicht bei Mikro-Optimierungen.
Wer lange genug an Performance arbeitet, entwickelt aber ein Repertoire an Patterns, die kein Profiling mehr brauchen. Ein Beispiel aus der .NET-Welt: Beim Dictionary ein TryGetValue verwenden statt erst Contains und dann Get. Das spart rund 30 Prozent an dieser Stelle und kostet keinen Mehraufwand, wenn es Routine ist.
Solche Gewohnheiten verhindern, dass man später jede Stelle einzeln nachbessern muss. Wer das von Anfang an mitschreibt, baut die Optimierung gleich ein.
Vergiss dabei die Tests nicht. Tests werden oft per Copy-Paste hingeschüttelt, und gerade UI-Tests laufen langsam, weil sie auf Felder warten müssen. Unit-Tests ohne Oberfläche schaffen bei kurzen Tests mehrere tausend Durchläufe pro Sekunde. Über die Oberfläche ist diese Menge nicht zu erreichen.
Die Performance-Brille verändert, wie du Code liest
Wer sich intensiv mit Performance beschäftigt, liest Code anders. Bei Code-Reviews oder fremdem Code erkennt man Optimierungspotenzial fast nebenbei, ohne es sofort anzusprechen. Man merkt es sich.
Dieses gespeicherte Wissen wird zum Vorrat an Quick Wins. Wenn der Product Owner nach schnellen Verbesserungen fragt, hast du die Stellen schon im Kopf. In einem konkreten Fall hat eine Personenwoche Arbeit den Start einer Anwendung um 35 Prozent beschleunigt. Es war kein einzelner Brocken, sondern mehrere kleine Eingriffe.
Eine Personenwoche ist in Entwicklungszeit fast nichts. Genau das macht solche Optimierungen verkaufbar, denn reine Performance-Arbeit gilt schnell als teuer und aufwendig, während Features Vorrang haben.
Grüner Strom als Steuergröße für Rechenarbeit
Software kann ihre Last danach ausrichten, wann grüner Strom verfügbar ist. Es gibt öffentliche Dienste, die für ganz Europa anzeigen, wo gerade wie viel Strom aus erneuerbaren Energien erzeugt wird, samt API.
Damit lässt sich Arbeit verschieben. Nicht jede Last muss in dem Moment verarbeitet werden, in dem sie entsteht. Wer Spitzenlasten ausgleicht, kann größere Mengen dann erledigen, wenn grüner Strom reichlich da ist. Wer keine API anbinden will, begrenzt schwere Aufgaben einfach auf bestimmte Uhrzeiten und macht nachts weniger.
Effizienz spart Strom und Geld zugleich
Auf der Backend-Seite führt der Weg über das Profiling. Weniger CPU-Verbrauch zieht eine ganze Kette nach sich: weniger Stromverbrauch, weniger Wärme, weniger Kühlbedarf, und damit auch weniger Strom für die Klimaanlagen im Rechenzentrum.
Im Cloud-Zeitalter wird daraus direkt Geld. Anbieter wie AWS, Google oder Azure rechnen nach CPU, Hauptspeicher und übertragenen Bytes ab. Wer ressourcenschonender arbeitet, sieht das sofort auf der monatlichen Rechnung. Ökologie und Ökonomie fallen hier zusammen.
Wenn wir die Performance der Software verbessern, erreichen wir die gleiche Funktionalität einfach mit weniger Ressourcen, weniger CPU, weniger Hauptspeicher. Und weniger Stromverbrauch ist gut für den CO2-Fußabdruck. (Carlos Fernandez)
Die Cloud hat dieses Bewusstsein verwässert. Früher war im eigenen Rechenzentrum jede zusätzliche Maschine eine sichtbare Investition über Monate. Heute schiebst du einen Regler hoch und hast eine neue Instanz. Die Hardware dahinter bleibt real und begrenzt: Jeder Host hat eine feste Zahl an CPUs und Speicher. Zu klein dimensioniert, stößt du an Grenzen, zu groß, laufen Server leer und verbrauchen trotzdem Strom.
Nachhaltigkeit setzt sich von unten durch, nicht nur von oben
In vielen Köpfen ist das Thema noch nicht angekommen, deshalb braucht es Überzeugungsarbeit innerhalb der Organisation. Bei der DATEV gibt es dafür eine Green Community of Practice mit rund 200 Mitgliedern, die nicht nur Software, sondern auch Beschaffung und andere Bereiche abdeckt. Ein kleineres Subteam kümmert sich gezielt um nachhaltige Software.
Strategische Ziele von oben sind hilfreich, brauchen aber Zeit, bis sie bis zum einzelnen Entwickler heruntergebrochen sind. Wer nicht warten will, leistet die Überzeugungsarbeit von unten. Eine interne Vortragsbühne, getragen von einer Software Craft Community mit fast 1500 Mitgliedern, dient genau dazu, Tipps und Richtlinien von Entwicklern für Entwickler weiterzugeben.
Druck kommt inzwischen auch von außen. Ein Energieeffizienzgesetz verlangt, bestimmte Kennzahlen transparent zu machen, wenn man ein Rechenzentrum betreibt. Das gesteigerte Interesse an nachhaltiger Software speist sich aus beidem: aus eigenem Antrieb und aus gesetzlicher Pflicht.
Wo du anfangen kannst
Der Einstiegspunkt hängt davon ab, wo du arbeitest. Im Web beginnst du beim Netzwerkverkehr: Wie viele Requests macht die Seite, welches Volumen wird übertragen, welche Requests dauern lang oder laufen ins Leere? Veraltete JavaScript-Bibliotheken, aufgeblähtes HTML und ungenutzte Ressourcen sind die ersten Kandidaten.
Im Backend führt der Weg über das Profiling. Lege fest, was du messen willst, optimiere gezielt und prüfe danach, ob es etwas gebracht hat. Wichtig bleibt die Richtung: Ziel ist die gleiche Funktionalität mit weniger CPU und weniger Speicher, nicht mehr Leistung durch mehr Hardware.
Auch die kleinen Dinge im Unternehmen summieren sich. Monitore und Licht abends abschalten, Geräte über Nacht und an Feiertagen ausschalten, bei Rechenzentren die Standortwahl bedenken. Ein Rechenzentrum in Finnland braucht weniger Kühlung als eines in einer warmen Region. Wärmerückgewinnung fängt die Abwärme auf, statt sie verpuffen zu lassen.
Häufig gestellte Fragen
Bringt eine schnellere Software automatisch einen kleineren CO2-Fußabdruck?
Meist ja, aber nicht zwangsläufig. Dieselbe Funktionalität mit weniger CPU und weniger Hauptspeicher senkt den Stromverbrauch und damit die Emissionen. Wer Geschwindigkeit dagegen durch einen zweiten Server erkauft, wird schneller und verbraucht mehr. Entscheidend ist die Richtung: dieselbe Aufgabe mit weniger Ressourcen erledigen, nicht mit zusätzlicher Hardware.
Ist Speicherverbrauch bei modernen 64-Bit-Anwendungen überhaupt noch ein Thema?
Ja. Der Eindruck unbegrenzten Speichers täuscht, weil ein Programm die Maschine nie allein hat. CPU und Hauptspeicher teilen sich alle Prozesse, und jede neue Betriebssystemversion verlangt mehr: aus 16 Gigabyte werden 32, irgendwann reicht auch das nicht. Dasselbe gilt für Bandbreite, deren Verbrauch bei rechnerübergreifender Kommunikation selten überhaupt gemessen wird.
Lohnt es sich, Fotos vor dem Einbinden in eine Webseite zu verkleinern?
Der Effekt ist erheblich. Ein Foto mit 12 Megapixeln bringt rund 3 Megabyte, obwohl ein typischer Monitor nur etwa 1900 Pixel in der Breite darstellt. Pixelgröße vorab anpassen, JPEG-Qualität auf etwa 50 Prozent senken und den Hintergrund unscharf stellen führt zusammen auf 86 Kilobyte. Bei hunderttausenden Requests multipliziert sich jedes gesparte Kilobyte.
Warum gelten Autoplay und Auto-Refresh als Ressourcenverschwendung?
Beide erzeugen Last, die niemand nutzt. Ein automatisch startendes Video kostet Bandbreite, auch wenn es keiner ansieht. Ein Auto-Refresh mit festem Intervall, etwa jede Sekunde oder zweimal pro Minute, läuft im Hintergrund weiter, während der Nutzer gar nicht vor dem Fenster sitzt. Die Requests entstehen dauerhaft und liefern keinen Gegenwert.
Muss jede Optimierung mit einer Messung beginnen?
Nicht jede. Bei großen Problemen gilt die Regel messen, verbessern, wieder messen, mit einem Profiler und dem Einstieg bei den größten Brocken statt bei Mikro-Optimierungen. Wer länger an Performance arbeitet, kennt aber Muster, die kein Profiling mehr brauchen. In .NET etwa TryGetValue beim Dictionary statt Contains und anschließendem Get: rund 30 Prozent an dieser Stelle.
Kann Software ihre Rechenarbeit nach der Verfügbarkeit von grünem Strom ausrichten?
Ja. Öffentliche Dienste zeigen für ganz Europa an, wo gerade wie viel Strom aus erneuerbaren Energien erzeugt wird, samt API zur Abfrage. Damit lassen sich Spitzenlasten verschieben, statt jede Aufgabe im Moment ihres Entstehens zu verarbeiten. Wer keine API anbinden will, begrenzt schwere Aufgaben auf bestimmte Uhrzeiten und rechnet nachts weniger.
Warum schlägt sich ressourcenschonender Code direkt in der Cloud-Rechnung nieder?
Weil Anbieter wie AWS, Google oder Azure nach CPU, Hauptspeicher und übertragenen Bytes abrechnen. Weniger CPU-Verbrauch zieht eine Kette nach sich: weniger Strom, weniger Wärme, weniger Kühlbedarf im Rechenzentrum. Eine neue Instanz ist zwar mit einem Regler schnell hinzugefügt, doch die Hardware dahinter bleibt begrenzt, und zu groß dimensionierte Server verbrauchen im Leerlauf trotzdem Strom.
