Performance-Probleme finden und lösen

„Die Seite ist langsam“ ist keine Diagnose, sondern ein Symptom. Langsam kann bedeuten: Der Server antwortet spät, die Bilder laden ewig, das Backend ruckelt beim Speichern oder eine einzelne Übersichtsseite hängt. Jede dieser Beschwerden hat andere Ursachen und andere Lösungen. Diese Lektion zeigt, wie Sie zuerst messen, dann richtig einordnen und schließlich gezielt beheben – statt zehn Optimierungs-Plugins zu installieren, die sich gegenseitig behindern.

1. Wo ist es langsam?

Abb. 3.1Der Ablauf eines Seitenaufrufs

Die erste Weiche ist die Frage, welcher Teil des Aufrufs zu lange dauert. Eine hohe Antwortzeit des Servers (TTFB) zeigt auf PHP, Datenbank oder Hosting. Ein spätes Kopfbild zeigt auf Bilder und Ladereihenfolge. Träges Verhalten nach dem Anzeigen zeigt auf JavaScript. Und ein langsames Backend hat fast immer mit Abfragen oder externen Diensten zu tun – Besucher merken davon nichts, das Team umso mehr.

2. Die häufigsten Bremsen

Auffällig ist, wie oft dieselben drei Dinge die Ursache sind: zu große Bilder, zu viele Plugins und fehlendes Caching. Ein Seitenbaukasten, der auf jeder Seite ein komplettes Framework lädt, ein Slider mit vier Bibliotheken und ein Statistik-Plugin, das jede Ansicht in die Datenbank schreibt – diese Kombination sieht man auf sehr vielen Websites. Wer hier aufräumt, gewinnt mehr als mit jeder Feinjustierung.

3. Die Caching-Ebenen

1<?php
2function radwerk_wetter(): array {
3    $daten = get_transient( 'radwerk_wetter' );
4    if ( false !== $daten ) {
5        return $daten;                       // aus dem Zwischenspeicher
6    }
7
8    $antwort = wp_remote_get( WETTER_URL, [ 'timeout' => 3 ] );
9    if ( is_wp_error( $antwort ) ) {
10        return [];                           // Fehler nicht speichern
11    }
12
13    $daten = json_decode( wp_remote_retrieve_body( $antwort ), true );
14    set_transient( 'radwerk_wetter', $daten, HOUR_IN_SECONDS );
15    return $daten;
16}

4. Vorgehen bei einer langsamen Website

Was oft schiefgeht

Drei Muster begegnen einem in der Praxis immer wieder. Erstens mehrere Optimierungs-Plugins gleichzeitig: Eines fasst CSS zusammen, ein zweites lädt Skripte verzögert, ein drittes räumt die Datenbank auf. Sie stören sich gegenseitig, und kein Mensch weiß am Ende, welche Einstellung welchen Effekt hat. Ein einziges, gut konfiguriertes Werkzeug ist fast immer besser. Zweitens das Optimieren ohne Messung: Da werden Skripte verschoben und Bilder komprimiert, während der eigentliche Engpass eine externe Schnittstelle mit drei Sekunden Antwortzeit ist. Und drittens das Messen der falschen Seite – die Startseite ist optimiert, aber achtzig Prozent der Besucher kommen über Blogbeiträge oder Leistungsseiten, die niemand angesehen hat.

Hinzu kommt ein Missverständnis: Der Wert in PageSpeed Insights ist nicht das Ziel. Entscheidend sind die Felddaten aus echten Besuchen, die Google in der Search Console unter „Core Web Vitals“ zeigt. Eine Seite mit 85 Punkten im Labor, deren Besucher auf dem Handy im ländlichen Mobilfunknetz vier Sekunden warten, hat ein Problem – und eine Seite mit 70 Punkten und grünen Felddaten hat keines. Optimieren Sie für die Menschen, nicht für die Punktzahl.

5. Ein Beispiel

Ein Café mit Online-Vorbestellung klagte über ein zähes Backend: Das Speichern eines Produkts dauerte fast zehn Sekunden. Query Monitor zeigte über 2.000 Datenbankabfragen je Aufruf, die fast alle von einem Bewertungs-Plugin stammten – es lud bei jedem Speichern sämtliche Bewertungen aller Produkte, um einen Durchschnitt zu berechnen. Die Lösung war eine gespeicherte Kennzahl statt einer Berechnung bei jedem Aufruf; das Plugin bot dafür eine Einstellung, die niemand kannte. Danach blieben 180 Abfragen und unter einer Sekunde. Im Frontend brachte zusätzlich das Umstellen der Produktbilder auf WebP mehr als eine Sekunde – ganz ohne neues Plugin.

6. Häufige Fragen

Wie viele Plugins sind zu viele? Die Zahl sagt wenig; entscheidend ist, was sie tun. Zwanzig schlanke Plugins können harmloser sein als drei schwere. Prüfen Sie mit Query Monitor, welche Plugins Abfragen und Ladezeit verursachen, und entfernen Sie alles, was nicht mehr gebraucht wird.

Bringt ein teurerer Server viel? Nur, wenn die Serverantwort tatsächlich langsam ist – und auch dann oft weniger als ein Objekt-Cache oder das Entfernen einer teuren Abfrage. Bei rein statischen Seiten mit gutem Cache ist selbst ein kleines Paket ausreichend.

Warum ist die Seite für mich langsam, im Test aber schnell? Weil Sie angemeldet sind: Für angemeldete Personen wird der Seitencache umgangen. Messen Sie immer in einem privaten Fenster.

7. Übung zum Selbermachen

Messen Sie eine Website mit PageSpeed Insights und notieren Sie LCP, INP und CLS. Öffnen Sie dieselbe Seite angemeldet mit Query Monitor und notieren Sie Anzahl und Gesamtzeit der Datenbankabfragen sowie die drei langsamsten. Prüfen Sie unter Werkzeuge → Website-Zustand, wie groß die automatisch geladenen Optionen sind. Formulieren Sie daraus drei Maßnahmen mit erwarteter Wirkung – und setzen Sie nur die erste um, um den Effekt sauber messen zu können.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.