Ein neuer Button auf der Startseite wird auf zwei Wochen geschätzt. Das Plugin-Update wartet bis Montag, weil am Freitag niemand ein Risiko eingehen will. Der neue Entwickler hat nach einer Woche immer noch keine funktionierende Kopie der Website auf seinem Rechner. Die Geschäftsführung sieht steigende Rechnungen und zieht den einfachsten Schluss: Die Leute arbeiten zu langsam.
Ally Piechowski, die Entwicklerteams begutachtet, hat im Artikel Why Your Engineering Team Is Slow (It’s the Codebase, Not the People) fünf Anzeichen beschrieben, dass der Code das Tempo bremst und nicht das Team. Sie schrieb über Anwendungen, doch jedes dieser Anzeichen hat eine Entsprechung auf einer WordPress-Website und in einem WooCommerce-Shop. Im Folgenden finden Sie jedes davon samt einer Methode, es an Ihrer eigenen Installation zu messen.
Warum ist die Schätzung für eine einfache WordPress-Änderung so hoch
Das erste Anzeichen nennt die Autorin die entschuldigende Schätzung. Für eine Funktion, die drei Tage dauern sollte, sagt der Entwickler: “Wie ich diesen Code kenne, sind das wohl etwa zwei Wochen” (Ally Piechowski, eigene Übersetzung). Er weiß, dass eine Änderung an einer Stelle etwas an drei anderen kaputt macht. Schätzungen, die dauerhaft 2-3 Mal höher ausfallen als nötig, sind laut der Autorin kein Schätzproblem. Das Team weiß, was dieser Code kostet, es hat nur aufgehört, es zu erklären.
In WordPress haben solche versteckten Verflechtungen typische Ursachen: ein Theme, das einen Teil der Inhalte selbst erzeugt, statt Blöcke zu nutzen, überschriebene WooCommerce-Templates, die vor mehreren Versionen kopiert wurden, mehrere Plugins, die dasselbe tun, und eigener Code, der an denselben Hooks hängt.
So messen Sie es: Nehmen Sie die letzten zehn Änderungen aus der Ticket-Historie und stellen Sie Schätzung und tatsächlichen Aufwand gegenüber. Ist die Abweichung gleichbleibend und immer in dieselbe Richtung, sagt die Schätzung die Wahrheit über den Code.
Warum will niemand die Website am Freitag aktualisieren
Das zweite Anzeichen ist die Angst vor dem Live-Stellen. Im Artikel geht es um ein Team mit der ungeschriebenen Regel “nach Mittwoch wird nichts mehr live gestellt”. Sie entstand, nachdem drei Veröffentlichungen an Donnerstagen hintereinander mit einer Störung am Wochenende endeten, ohne Rückfallplan, mit Tests, denen niemand traute, und einem 45-minütigen Veröffentlichungsprozess.
Auf einer WordPress-Website sieht diese Angst so aus: Plugin-Updates werden direkt auf der Live-Seite angeklickt, es gibt keine Testumgebung oder eine mit einer Datenbank von vor einem halben Jahr, und das Backup hat noch nie jemand zurückgespielt. Die Folge ist dieselbe wie im Artikel: Änderungen sammeln sich zu Paketen, und jedes Paket ist größer und riskanter als das vorige.
So messen Sie es: Beantworten Sie drei Fragen. Gibt es eine Testumgebung mit aktueller Datenbank? Hat jemand im letzten Quartal ein Backup zurückgespielt? Gibt es Tage, an denen das Team nichts live stellt? Jedes “nein” bei den ersten beiden und ein “ja” bei der dritten erhöht die Punktzahl.
Welche Datei im WordPress-Theme ist die Sperrzone
Das dritte Anzeichen ist die Datei, die niemand anfasst. Die Autorin sucht sie in der Repository-Historie: eine Datei, die ständig im git log auftaucht, deren Struktur aber seit Jahren niemand verändert hat. Rund um eine solche Datei baut das Team Umwege, sodass der Code um eine Zone herum wächst, die alle meiden.
In WordPress ist das meist die functions.php des Themes, die über die Jahre auf mehrere tausend Zeilen angewachsen ist, oder das firmeneigene Plugin, in das jeder “nur noch eine Funktion” geschrieben hat.
So messen Sie es: Führen Sie im Repository des Themes oder des eigenen Plugins Folgendes aus:
git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10Die Liste zeigt die am häufigsten geänderten Dateien. Die Datei an der Spitze, deren Änderungen ausschließlich Ergänzungen am Ende sind, ist eine Kandidatin für die Sperrzone. Hat das Theme kein Repository, ist die Punktzahl für dieses Anzeichen ohnehin hoch: Niemand kann nachvollziehen, wer den Code wann und warum geändert hat.
Zählen Sie bei der Gelegenheit die aktiven Plugins:
wp plugin list --status=active --format=countDie Zahl allein entscheidet nichts, aber mehrere Formular-, Cache- oder SEO-Plugins gleichzeitig sind eine häufige Quelle von Konflikten, die jede Änderung verlängern.
Schützt eine hohe Testabdeckung den WooCommerce-Checkout
Das vierte Anzeichen nennt die Autorin die Lüge der Testabdeckung. Das Dashboard zeigt einen gesunden Prozentwert, während drei Modelle, die mit Geld umgehen, keinen einzigen Test haben. Dazu liefen die Tests auf dem CI-Server 40 Minuten, also hörten die Entwickler auf, sie lokal auszuführen. Ihr Test ist einfach: Wann hat ein Test zuletzt einen Fehler gefunden, bevor er in die Produktion gelangte?
Ein WooCommerce-Shop ganz ohne Tests hat dasselbe Problem in schärferer Form. Der Zahlungsweg besteht aus Warenkorb, Checkout, Zahlungsanbieter und Bestellbestätigung per E-Mail. Wenn nach jedem Update jemand von Hand eine Testbestellung aufgibt, hat der Shop einen Test, nur eben einen manuellen, der vom Gedächtnis einer einzigen Person abhängt.
So messen Sie es: Prüfen Sie, ob es überhaupt einen automatischen Test gibt, der eine Bestellung aufgibt, und fragen Sie, wann er zuletzt etwas gefunden hat.
Wie lange dauert die Einarbeitung eines neuen Entwicklers in eine WordPress-Website
Das fünfte Anzeichen ist die Zeit bis zur ersten Änderung: wie lange es dauert, bis eine neue Person eine echte Korrektur live stellt. Laut der Autorin sind es in einem gesunden Projekt ein oder zwei Tage, in ungesunden hat sie zwei Wochen und mehr erlebt. Die Ursache ist oft eine verwahrloste Einrichtung: veraltete Installationsskripte, kaputte Startdaten, undokumentierte Umgebungsvariablen.
Bei WordPress sieht die Liste ähnlich aus: kein Repository, ein Datenbank-Dump, den man beim Hoster erbitten muss, API-Schlüssel, die nur auf dem Live-Server liegen, Premium-Plugins ohne Entwicklerlizenz.
So messen Sie es: Richten Sie von Grund auf eine funktionierende lokale Kopie ein, zum Beispiel mit wp-env, und notieren Sie die Zeit sowie alles, worum Sie jemanden bitten mussten.
Wie berechnet man die Punktzahl der fünf Anzeichen
Die Autorin bewertet jedes Anzeichen auf einer Skala von 0 bis 2. Ab 4 Punkten braucht der Code eine direkte Investition, bevor andere Maßnahmen helfen. Ab 7 Punkten beginnen, wie sie schreibt, die meisten ihrer Aufträge.
| Anzeichen | 0 Punkte | 2 Punkte |
|---|---|---|
| Entschuldigende Schätzung | Schätzungen stimmen mit dem Aufwand überein | dauerhafte Abweichung nach oben |
| Angst vor dem Live-Stellen | Testumgebung, Rückfallplan, Veröffentlichung an jedem Tag | Änderungen direkt live, kein geprüftes Backup |
| Datei, die niemand anfasst | keine Datei dominiert die Historie | eine Datei wuchert mit Ergänzungen |
| Testabdeckung | ein Test hat kürzlich einen Fehler vor der Produktion gefunden | Checkout ohne jeden Test |
| Zeit bis zur ersten Änderung | lokale Kopie in einer Stunde | mehrere Tage und Zugangsanfragen |
Die Punkte selbst sind willkürlich, entscheidend ist die Reihenfolge der Anzeichen. Die Autorin rät, mit dem Anzeichen mit der höchsten Punktzahl zu beginnen, ihm einen konzentrierten zweiwöchigen Sprint zu widmen und etwas Konkretes zu messen, etwa die Häufigkeit der Veröffentlichungen oder die Treffsicherheit der Schätzungen.
Warum arbeitet der beste Entwickler an der Website am langsamsten
Die Autorin weist auf ein Paradox hin: Bei solchem Code werden die Besten am stärksten ausgebremst. Sie sehen das Risiko, sie wissen, dass eine Änderung in dieser Datei jenen Ablauf kaputt machen kann, also arbeiten sie vorsichtig, schreiben defensiven Code und schätzen höher. Eine weniger erfahrene Person ist manchmal schneller, weil sie die Gefahr nicht sieht, und verursacht dann eine Störung, nach der alle noch vorsichtiger werden.
Ein Beispiel aus ihrem Artikel: Zwei Entwickler bauten eine Woche lang einen CSV-Export in den Verwaltungsbereich ein, obwohl die eigentliche Arbeit vielleicht einen Tag ausmachte. Der Rest der Zeit ging dafür drauf, den vorhandenen Code gut genug zu verstehen, um ihn gefahrlos zu ändern. Dieser Mehraufwand taucht in keinem Bericht auf, also sieht die Führung nur langsame Menschen.
Löst ein Neuaufbau der Website das Problem langsamer Änderungen
Nicht immer. Die Autorin beschreibt einen Kunden, bei dem in zehn Jahren sechs Entwicklerteams aufeinander folgten. Jedes Mal war das Muster gleich: Druck für neue Funktionen, aufgeschobene Aufräumarbeiten, bis der Code nicht mehr zu retten schien. Dann schlug jemand vor, alles neu zu schreiben oder Microservices herauszulösen, was die Lage verschlimmerte, denn statt eines Systems gab es nun zwei, und das alte lief weiter.
Bei WordPress kommt einem dieses Szenario bekannt vor: ein neues Theme, das neben dem alten aufgesetzt wird, ein Headless-Frontend, das einen Teil der Seiten übernimmt, während der Rest weiter über das alte Template läuft, oder ein neuer Shop, in den die Hälfte der Anbindungen nie umzieht. Ein Neuaufbau lohnt sich, wenn klar ist, welches Anzeichen bremst und ob die neue Architektur es beseitigt. Andernfalls wandern die alten Hindernisse in den neuen Code.
Was sollte man bei jedem Anzeichen zuerst beheben
Die Autorin nennt für jedes Anzeichen einen anderen ersten Schritt. Hier ihre Empfehlungen und deren Entsprechung auf einer WordPress-Website.
- Entschuldigende Schätzung: die Module mit der größten Reichweite entflechten. In WordPress heißt das meist, die
functions.phpin einzelne Dateien oder ein Plugin mit klar benannten Funktionen aufzuteilen und überschriebene WooCommerce-Templates zurückzubauen, die niemand aktualisiert hat. - Angst vor dem Live-Stellen: ein schnellerer Veröffentlichungsprozess, automatische Rückkehr zur vorherigen Version und kleinere Änderungspakete. In WordPress: eine Testumgebung mit aktueller Datenbank, Code aus dem Repository statt per FTP ausliefern und ein erprobtes Zurückspielen des Backups.
- Datei, die niemand anfasst: zuerst Tests rund um die Datei, danach Umbauten an der Struktur. Für ein Theme genügen zu Beginn einige Tests, die prüfen, ob die wichtigsten Seiten dargestellt werden.
- Testabdeckung: ein Test für den Zahlungsweg. In WooCommerce ist das ein automatischer Test, der in der Testumgebung eine Bestellung aufgibt und prüft, ob die Bestätigungs-E-Mail angekommen ist.
- Zeit bis zur ersten Änderung: Laut der Autorin macht sich ein einziger Tag, der in die Einrichtung fließt, schnell bezahlt. In WordPress: eine wp-env-Konfigurationsdatei im Repository, ein Skript, das einen anonymisierten Datenbank-Dump holt, und eine Liste der Umgebungsvariablen.
Wenn Sie das mit der Geschäftsleitung oder einem Kunden besprechen, wirkt Konkretes besser als Allgemeines. Die Autorin stellt zwei Aussagen gegenüber: “Jede Funktion dauert ungefähr doppelt so lange, weil diese drei Module eng miteinander verflochten sind” ist ein völlig anderes Gespräch als die Klage über technische Schulden (Ally Piechowski, eigene Übersetzung).
Beschleunigt KI Änderungen an einer alten WordPress-Website
Die Annahme ist verlockend, ein KI-Agent werde das Problem einfach umschreiben. Die Autorin zitiert eine METR-Studie aus dem Jahr 2025: 16 erfahrene Open-Source-Entwickler arbeiteten mit KI-Werkzeugen in Repositories, die sie gut kannten, um 19% langsamer. Sie fügt hinzu, dass das Schreiben von Code nie der Engpass war.
Der Agent stößt auf dieselben versteckten Abhängigkeiten wie ein Mensch, er erzeugt nur schneller den nächsten Umweg um die Datei, die niemand anfasst. Senken Sie die fünf Anzeichen deshalb, bevor Sie KI ins Repository lassen.
Womit fängt man bei einer langsamen WordPress-Website an
Ab vier Punkten beginnen Sie mit dem Hindernis, das die höchste Bewertung hat. Ein neuer Entwickler oder ein neues Theme stößt sonst auf dieselben Hindernisse. Meist sind das eine Testumgebung mit aktueller Datenbank und ein Repository für das Theme, denn ohne beides lässt sich kein anderes Anzeichen gefahrlos angehen.
So funktioniert unser WooCommerce-Rettungssprint: eine bezahlte Diagnose, Korrekturen nach Priorität, Veröffentlichung zuerst in der Testumgebung und ein schriftlicher Bericht darüber, was geändert wurde und warum. Wenn Sie sich fragen, ob sich die Reparatur der Website überhaupt noch lohnt, beginnen Sie mit dem Audit zur Bereitschaft für einen Neuaufbau oder dem Leitfaden wann Sie eine Website neu aufbauen sollten.
