Kaum ein Projekt beginnt mit doppeltem Code. Er entsteht schleichend: Ein Button wird kopiert statt wiederverwendet, eine Hilfsfunktion zur Sicherheit ein zweites Mal geschrieben, eine alte Komponente bleibt liegen, weil niemand sich traut, sie zu löschen. Nach zwei Jahren trägt eine Website oft ein Drittel Code mit sich herum, den kein Mensch mehr braucht – und der bei jedem Seitenaufruf trotzdem übertragen und geparst wird.
Genau dagegen richtet sich Guideline 3.4. Sie will Redundanz und Doppelungen gar nicht erst wuchern lassen.
Die drei Erfolgskriterien von Guideline 3.4 (meine Übersetzung des Originals):
Entfernen oder vereinfachen: Überarbeite den Code, um Doppelungen und Redundanz zu verringern, indem Du die Struktur verbesserst, wiederkehrende Logik zusammenführst und Wiederverwendung förderst.
Weiterentwickeln statt neu bauen: Bevorzuge es, bestehende, nutzerseitige Lösungen zu verbessern und zu erweitern, statt sie von Grund auf neu zu bauen. Ersetze eine bestehende Lösung nur dann, wenn das klare Vorteile für Nutzererfahrung, Performance, Skalierbarkeit oder Wartbarkeit bringt.
Code sinnvoll strukturieren: Wende das DRY-Prinzip (Don’t Repeat Yourself) auf CSS und JavaScript an, wo es die Wartbarkeit verbessert. Achte darauf, dass Bemühungen zur Verringerung von Doppelungen die Komplexität nicht erhöhen, keine unnötigen Abhängigkeiten einführen und die Performance nicht beeinträchtigen.
Meine Einordnung
Die drei Kriterien oben greifen ineinander, und mir gefällt, dass das mittlere die verbreitetste Fehlannahme direkt anspricht. In vielen Projekten gilt der komplette Neubau als Königsweg: neues Framework, sauberer Start, alles besser. In der Praxis erlebe ich fast immer das Gegenteil. Ein Neubau bringt neue Abhängigkeiten, neue Standard-Bibliotheken und neuen ungenutzten Ballast mit – und am Ende steht mehr Code da als vorher, nicht weniger. Weiterentwickeln statt neu bauen ist deshalb kein Kompromiss, sondern oft die nachhaltigere Entscheidung.
Rechnen wir den Rest in Zahlen. Angenommen, toter und doppelter Code bläht jede Seite um nur 100 Kilobyte auf. Bei einer Million Aufrufen sind das rund 100 Gigabyte Datenübertragung im Monat – nach der Faustregel, dass ein Megabyte weniger pro Aufruf über eine Million Aufrufe etwa 400 Kilogramm CO₂ spart, ungefähr 40 Kilogramm CO₂. Für Code, der niemandem nützt.
Das dritte Kriterium mahnt zu Recht zur Vorsicht: DRY ist ein Werkzeug, kein Selbstzweck. Wer jede Wiederholung um jeden Preis zusammenzieht, baut manchmal eine abstrakte Konstruktion, die schwerer zu verstehen ist als die Doppelung, die sie ersetzt. Entscheidend ist, ob die Wartbarkeit wirklich steigt.
Wo ich weiter gehe
Guideline 3.4 spricht vom Entfernen und Entrümpeln. Ich setze eine Stufe früher an: beim Entwurf. Denn die günstigste Zeile Code ist die, die nie geschrieben wird. Wer schon in der Design-Phase überlegt, welche Komponente wirklich gebraucht wird und welche nur nett zu haben ist, muss später nichts löschen.
In neuen Projekten frage ich deshalb bei jeder Komponente: Gibt es die schon? Lässt sich Vorhandenes wiederverwenden? Braucht diese Seite die Bibliothek überhaupt? Diese drei Fragen verhindern mehr überflüssigen Code als jedes spätere Aufräumen.
Dein erster Schritt heute
Für bestehenden Code musst Du trotzdem entrümpeln – und genau dabei ist KI inzwischen richtig gut. Sie erkennt doppelte Regeln, tote Selektoren und zusammenfassbare Logik oft schneller und gründlicher als das bloße Auge.
Ergänzend hilft ein Blick in den Coverage-Reiter Deines Browsers oder ein Build-Werkzeug mit Tree-Shaking, das ungenutzte Module beim Bauen automatisch aussortiert. Aber der erste, wirksamste Schritt bleibt: einmal ehrlich hinschauen, wie viel von Deinem Code überhaupt noch gebraucht wird.
Aufräumen behebt den Schaden. Der bessere Code ist der, der nie doppelt entsteht – denn was nie geschrieben wird, muss auch nie gelöscht werden.
Quellen: W3C-Fassung von Guideline 3.4 · Interpretation bei Sustainable Web Design