Green Software Engineering in der PHP-Entwicklung: PHP, Datenbank und Cache

Ein PHP-Backend braucht weniger Rechenzeit, Speicher und Datenbankarbeit, wenn Teams erst reale Engpässe messen und danach unnötige Arbeit im Request entfernen. Das senkt nicht automatisch eine bestimmte Menge Energie oder Emissionen. Es schafft aber die technische Voraussetzung, dass eine Anwendung pro Seitenaufruf, API-Aufruf oder Hintergrundjob weniger Ressourcen beansprucht.

Green Software Engineering behandelt nicht nur Strom. Der Software Carbon Intensity Standard (SCI) unterscheidet Energieeffizienz, Hardwareeffizienz und den Zeitpunkt oder Ort des Energiebezugs. Für eine Aussage zu Emissionen müssen Team, Systemgrenze, funktionale Einheit, Messmethode und Stromintensität zusammenpassen.

Dieser Beitrag zeigt die Backend-Arbeit: PHP-Laufzeit prüfen, SQL-Aufrufe begrenzen, Cache mit Regeln einsetzen und jede Änderung gegen eine Ausgangsmessung testen. Den Rahmen für nachhaltige Webarbeit beschreibt der Green-SEO-Hub zu digitaler Nachhaltigkeit. Die W3C Web Sustainability Guidelines ergänzen dafür Empfehlungen. Die WSG-Leitlinien bilden einen W3C Group Note Draft, keine verbindliche Rechtsnorm.

Was PHP-Teams reduzieren können

Eine Request-Kette beansprucht Ressourcen an mehreren Stellen: Der Webserver startet oder bedient PHP, PHP lädt und verarbeitet Code, die Anwendung fragt Daten ab, erzeugt Objekte und sendet eine Antwort. Ein Cache kann einzelne Schritte überspringen. Die passende Maßnahme hängt vom Engpass ab.

Diese Liste ordnet technische Arbeit und beweist keine CO₂e-Ersparnis. Ein geringerer PHP-Messwert kann dennoch zu mehr Gesamtlast führen, etwa wenn eine Änderung mehr Requests auslöst, den Cache häufiger leert oder Daten zwischen Regionen verschiebt. Der SCI fordert eine abgegrenzte Systembetrachtung.

Ablauf: vom Befund zur schlankeren Request-Kette

1. →Einen repräsentativen Vorgang festlegen: Wähle einen häufigen oder geschäftskritischen Vorgang aus: etwa einen nicht eingeloggten Artikelaufruf, eine Kategorieseite, eine Produktsuche oder einen Importjob. Notiere URL oder API-Endpunkt, Datenstand, eingeloggten Zustand, Cache-Zustand, PHP-Version und Infrastruktur. Vergleiche nur Läufe mit derselben funktionalen Einheit, zum Beispiel „ein erfolgreicher Artikelaufruf ohne Cache“ oder „ein verarbeiteter Importdatensatz“. Erfasse mindestens Request-Dauer, CPU-Zeit oder CPU-Auslastung, Peak-Speicher, Zahl und Dauer der SQL-Abfragen sowie Cache-Treffer und -Fehler. Ergänze die Messung durch Traces oder Profiler aus der eingesetzten Umgebung. Ein einzelner lokaler Lauf liefert eine Hypothese. Mehrere Wiederholungen unter dokumentierten Bedingungen liefern eine Vergleichsbasis.
2. →PHP-Laufzeit und Unterstützung sichern: Zum Stand 11. September 2026 unterstützt das PHP-Projekt die Reihen 8.2 bis 8.5. PHP 8.2 erhält Sicherheitsupdates nur noch bis 31. Dezember 2026. PHP 8.3, 8.4 und 8.5 erhalten noch aktive oder Sicherheitsunterstützung gemäß dem verabschiedeten Zeitplan. Das Projekt sieht zwei Jahre aktiven Support und anschließend zwei Jahre Sicherheitsunterstützung vor. Prüfe vor jedem Versionswechsel Framework, Erweiterungen, eigene Tests und das Rückfallverfahren.

Aktualisiere PHP nicht mit dem Versprechen eines pauschalen Performance- oder Energiegewinns. Messe den Workload auf der bisherigen und der Zielversion. So finden Teams Inkompatibilitäten, geänderte Standardwerte und Unterschiede im Hauptpfad.

OPcache speichert vorkompilierten PHP-Bytecode im Shared Memory. PHP muss dadurch Skripte nicht bei jedem Request erneut laden und parsen. Prüfe daher zunächst, ob OPcache aktiv ist, genügend Speicher für den Codebestand besitzt und ob Neustarts, Deployments und Dateiprüfungen zur Betriebsweise passen.

Der Just-in-Time-Compiler bildet kein Standardrezept. PHP dokumentiert seit PHP 8.4 disable als Standard für opcache.jit; zuvor lautete der Standard tracing. JIT kann für rechenintensive Pfade eine Testhypothese sein. Aktiviere ihn nur in einer Testumgebung und vergleiche CPU-Zeit, Latenz, Speicher sowie Fehlerraten für den tatsächlichen Workload.

3. →Große Datenströme ohne Vollmaterialisierung verarbeiten: Ein Import, Export oder Report darf nicht alle Elemente in ein Array laden, wenn die Arbeit auch schrittweise erfolgen kann. PHP-Generatoren geben Werte mit yield einzeln an eine Schleife. Das vermeidet das vorherige Anlegen eines gesamten Arrays im Speicher; wahlfreier Zugriff steht bei Generatoren nicht zur Verfügung.

function readCsvRows(string $path): Generator
{
    $handle = fopen($path, 'r');
    try {
        while (($row = fgetcsv($handle)) !== false) {
            yield $row;
        }
    } finally {
        fclose($handle);
    }
}

foreach (readCsvRows('/data/import.csv') as $row) {
    // Einen Datensatz prüfen, speichern und die nächste Zeile lesen.
}

Dieses Muster begrenzt den Speicherbedarf der Anwendung, sofern der nachfolgende Code keine wachsenden Sammelstrukturen aufbaut. Es ersetzt keine Prüfung der Datenbank- und Netzwerkseite. Bei großen Jobs prüfen Teams zusätzlich Batch-Größe, Transaktionsgrenzen, Fehlerfortsetzung und Wiederholungen.

4. →SQL-Arbeit am Ausführungsplan prüfen: Das N+1-Muster entsteht, wenn Code zunächst eine Liste lädt und anschließend für jedes Element eine weitere Abfrage ausführt. Ein Beispiel: Eine Übersicht lädt Beiträge und ruft in einer Schleife jeweils Autor oder Kategorie ab. Die Zahl der Abfragen wächst mit der Listenlänge.

Löse das Muster mit einer passenden Sammelabfrage, einem Join oder vorgeladenen Beziehungen auf. Prüfe danach, ob eine große Join-Abfrage unverhältnismäßig viele Zeilen erzeugt oder doppelte Daten transportiert. Eine Regel, dass immer genau eine Abfrage besser sei, existiert nicht. Maßgeblich sind Zeilen, Indizes, Datenmenge, Sperren und die gemessene Dauer.

EXPLAIN zeigt, wie MySQL eine Abfrage ausführen will, einschließlich Join-Reihenfolge und Indexzugriff. Die Dokumentation nennt das Werkzeug für die Prüfung, wo Indizes Abfragen beschleunigen können. Ein zusätzlicher Index kostet jedoch Speicher sowie Schreibarbeit. Lege keinen Index allein wegen eines vermuteten Engpasses an. Messe die betroffene Abfrage und prüfe ihren Plan vor und nach der Änderung.

EXPLAIN
SELECT p.id, p.title, a.display_name
FROM posts AS p
JOIN authors AS a ON a.id = p.author_id
WHERE p.status = 'published'
ORDER BY p.published_at DESC
LIMIT 20;

Wähle nur die Felder, die der Endpunkt braucht. SELECT * kann unbenötigte Spalten, große Textfelder und sensible Daten durch die Anwendung bewegen. Diese Entscheidung verlangt einen Vertrag zwischen Abfrage und Darstellung: Fehlt später ein Feld, darf Code nicht unbemerkt wieder pro Listenelement nachladen.

5. →Cache als Vertrag behandeln: Ein Cache speichert ein Ergebnis, das sich später wiederverwenden lässt. Er kann PHP-Arbeit, Datenbankabfragen oder Aufrufe externer Dienste vermeiden. Er kann aber auch veraltete Inhalte ausliefern oder beim Ablauf vieler gleicher Schlüssel Lastspitzen auslösen. Darum braucht jeder Cache-Eintrag einen fachlichen Vertrag.

PSR-6 definiert für PHP-Caches unter anderem Treffer, Fehlschlag, Ablauf und Time to Live (TTL). Ein abgelaufener Eintrag muss als Fehlschlag gelten. Die Schnittstelle fordert außerdem, dass ein Cache-Fehler die Anwendungsfunktion nicht lahmlegen soll.

Messe Cache-Treffer nach Endpunkt und Cache-Key-Gruppe. Eine hohe Gesamtquote sagt wenig aus, wenn der teure Suchendpunkt fast immer danebenliegt. Prüfe auch Invalidierungen nach Inhaltspflege und Rechtewechseln. Rollen, Vorschau und Veröffentlichungswege dürfen keine alten Inhalte im Cache zurücklassen.

Prüfkriterien für Freigabe und Betrieb

Eine technische Änderung gilt als belegt, wenn sie den Vorgang verbessert oder eine bekannte Nebenwirkung vermeidet. Teams dokumentieren die Messung.

Google beschreibt Core Web Vitals als Metriken für die reale Nutzererfahrung beim Laden, bei Reaktionen und bei visueller Stabilität. Für LCP, INP und CLS gelten eigene Mess- und Einordnungsregeln. Backend-Änderungen können einen Beitrag leisten, ersetzen aber keine Prüfung mit Feld- und Labordaten. Der Leitfaden Core Web Vitals und mobile Nutzbarkeit trennt diese Datenarten und ihre Aussagegrenzen.

Energie, Emissionen, CSRD und DPP abgrenzen

Weniger CPU-Zeit pro Request bildet einen technischen Befund. Eine Aussage über Energie verlangt mindestens Messwerte oder ein Modell für die abgegrenzte Infrastruktur. Eine Aussage über Emissionen braucht zusätzlich eine regionale Stromintensität und die gewählte funktionale Einheit. Der SCI berechnet Emissionen als Rate pro Einheit und berücksichtigt operative sowie verkörperte Emissionen innerhalb der festgelegten Systemgrenze. Zertifikate oder Kompensation senken nach SCI den Wert nicht.

Die CSRD regelt Unternehmensnachhaltigkeitsberichte. Die Richtlinie (EU) 2022/2464 liegt in ihrer geltenden Fassung vor. Das Gesetz macht aus einer PHP-Messung weder automatisch einen berichtspflichtigen Wert noch eine CSRD-konforme Angabe. Ob und wie ein Unternehmen berichten muss, richtet sich nach dem jeweiligen Rechtsrahmen, dem Unternehmensfall und den angewendeten Standards.

Der Digitale Produktpass (DPP) gehört zum Rahmen der Ökodesign-Verordnung (EU) 2024/1781 für physische Waren. Die Verordnung schafft den Rahmen; Anforderungen folgen produktbezogen über weitere Rechtsakte. Ein schlankeres PHP-Backend kann die Datenbereitstellung unterstützen, ersetzt aber weder Produktdaten, eindeutige Kennungen noch die rechtliche Prüfung des betroffenen Produktsegments. Der Beitrag Digitaler Produktpass und Structured Data behandelt diesen Produktdatenpfad.

Grenzen dieser PHP-Vertiefung

Diese Seite empfiehlt keinen pauschalen Wechsel zu Redis, Memcached, JIT, einer bestimmten Datenbank oder einer bestimmten Hosting-Region. Die Wirkung hängt von Lastprofil, Datenmodell, Infrastruktur, Sicherheitsanforderungen und Betrieb ab.

Diese Anleitung ersetzt auch kein Kapazitätsmodell. Eine schnellere Einzelseite kann bei höherem Traffic mehr Gesamtarbeit erzeugen. Ein Cache kann Speicher reservieren. Ein neuer Index kann Schreibvorgänge verlangsamen. Behandle jede Maßnahme als überprüfbare Änderung an einem abgegrenzten System.

Die W3C Web Sustainability Guidelines geben Orientierung für Entscheidungen rund um digitale Produkte und Dienste. Die Leitlinien verlangen keine einzelne PHP-Konfiguration und liefern keine allgemein gültige Grammzahl pro Request. Teams leiten daraus Prüffragen ab und legen die eigene Messmethode offen.

Häufige Fragen zu Green PHP

Senkt ein Update auf eine neuere PHP-Version automatisch Energieverbrauch und Emissionen?

Nein. Ein Update hält die Laufzeit im Support und bringt technische Verbesserungen mit. Die Wirkung auf CPU, Speicher, Energie oder Emissionen hängt vom eigenen Code und der Betriebsumgebung ab. Messe denselben Vorgang auf alter und neuer Version.

Soll ich JIT in PHP aktivieren?

Nur nach einem Vergleichstest für einen rechenintensiven, repräsentativen Pfad. Seit PHP 8.4 ist JIT standardmäßig deaktiviert. OPcache und eine verlässliche Messung gehören vor den JIT-Test.

Löst ein Object Cache immer ein Datenbankproblem?

Nein. Ein Cache kann Last verlagern oder veraltete Ergebnisse liefern. Prüfe zuerst Abfragezahl, Ausführungsplan, Datenvolumen und N+1-Muster. Cache nur Ergebnisse mit klarer Gültigkeit und Invalidierung.

Beweist eine geringere Serverzeit bessere Core Web Vitals oder ein besseres Google-Ranking?

Nein. Core Web Vitals messen reale Seitenerfahrung. Ranking hängt von mehreren Signalen ab. Prüfe Backend-Ressourcen, Frontend-Auslieferung und Felddaten getrennt.

Reicht die Backend-Messung für CSRD oder einen digitalen Produktpass?

Nein. CSRD und DPP haben unterschiedliche rechtliche und fachliche Geltungsbereiche. Eine PHP-Messung kann Daten für eine interne Entscheidung liefern. Das Messergebnis bildet ohne weitere Methode und Einordnung keinen Berichtsnachweis und keinen Produktpass.

Nächster Schritt

Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet Backend, Auslieferung und Rendering ein. OLDSCHOOLSEO plant für geeignete Websites eine Jamstack-Website ab 224 € mit schlanker Auslieferungsarchitektur.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen

Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018

Über den Autor: Sandra Krone

Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.

Mehr über die GründerProfil auf LinkedIn