Suchen Sie, wie man WordPress beschleunigt, und Sie finden Listen: dreißig Tipps, fünfzig Plugins, jede Option eingeschaltet. Folgen Sie einer davon, und die übliche Geschichte beginnt. Der Score bewegt sich, dann öffnet sich ein Menü nicht mehr, ein Formular sendet nicht mehr, und niemand weiß, welche der zehn Einstellungen schuld ist.
Dieser Ratgeber geht den anderen Weg. Er gibt Ihnen eine Reihenfolge: was Sie zuerst messen, wie Sie das eigentliche Problem finden und welchen Hebel Sie dafür ziehen, vom sichersten bis zum heikelsten. Jeder Schritt verweist auf einen eigenen Ratgeber, wenn Sie tiefer einsteigen möchten.
Was „schnell“ für Google bedeutet
Google bewertet die Geschwindigkeit einer Seite mit drei Kennzahlen, den Core Web Vitals, gemessen bei Ihren echten Besuchern:
- LCP (Largest Contentful Paint): wann der Hauptinhalt angezeigt wird, oft das obere Bild oder der Titel. Gut unter 2,5 s.
- INP (Interaction to Next Paint): wie lange die Seite braucht, um auf ein Tippen oder einen Klick zu reagieren. Gut unter 200 ms.
- CLS (Cumulative Layout Shift): wie stark der Inhalt beim Laden springt. Gut unter 0,1.
Das Urteil fällt beim 75. Perzentil der Besuche über 28 Tage: drei von vier Besuchen müssen gut sein. Ein einzelner Test auf Ihrem eigenen schnellen Rechner sagt darüber wenig aus.
Schritt 1: zuerst die Felddaten messen, dann das Labor
Es gibt zwei Arten von Daten, und sie beantworten unterschiedliche Fragen:
- Felddaten (Search Console und der obere Bereich von PageSpeed Insights) stammen von Ihren echten Besuchern. Sie sagen Ihnen, ob es ein Problem gibt, und wo.
- Labordaten (der Score von PageSpeed Insights, Lighthouse) stammen aus einem einzigen simulierten Ladevorgang. Sie helfen zu verstehen, warum, und eine Änderung sofort zu prüfen.
Beginnen Sie mit dem Core-Web-Vitals-Bericht in der Search Console. Er gruppiert Ihre URLs nach ähnlichen Seiten, meist also nach Seitenvorlage: Startseite, Beiträge, Produktseiten, Kategorien, Landingpages. Das ist die Einheit, an der Sie arbeiten, denn eine Korrektur in einer Vorlage korrigiert jede Seite, die darauf aufbaut.
Bevor Sie etwas ändern, notieren Sie den Ausgangspunkt jeder Vorlage: die drei Felddaten-Metriken und einen Labortest auf dem Smartphone. Wenn beide sich widersprechen, und das kommt oft vor, erklärt unser Ratgeber zu Labor- und Felddaten, wie man sie liest.
Schritt 2: herausfinden, welche Metrik auf welcher Vorlage durchfällt
Jede Metrik verweist auf eine andere Familie von Ursachen. Genau das bewahrt Sie davor, alles einzuschalten:
- Schlechter LCP: Der Server antwortet spät, oder das Hauptbild kommt spät (zu schwer, spät entdeckt, versehentlich per Lazy Loading geladen, hinter Stylesheets blockiert).
- Schlechter CLS: Bilder ohne reservierten Platz, eine Webschrift, die unterwegs wechselt, ein Banner oder Block, der nach der ersten Anzeige eingefügt wird.
- Schlechter INP: zu viel JavaScript im Hauptthread, vom Theme, vom Builder oder von Drittanbietern.
Sehen Sie sich auch die Server-Antwortzeit an (TTFB, in PageSpeed Insights angezeigt). Braucht das HTML selbst mehr als etwa 0,8 s, gleicht keine Optimierung im Browser das aus: Der nächste Schritt kommt zuerst.
Eine Vorlage + eine durchgefallene Metrik = eine Familie von Ursachen = ein Hebel.
Schritt 3: der Server und der Seitencache
WordPress baut jede Seite bei jedem Besuch in PHP, mit Datenbankabfragen. Ein Seitencache bewahrt das fertige HTML auf und liefert es direkt an die nächsten Besucher: Er ist der Hebel mit der größten Wirkung auf die Antwortzeit, und auf einer Inhaltsseite ist er für anonyme Besucher sicher.
- Ein Cache-System, nicht zwei. Viele Hoster cachen Seiten bereits auf dem Server. Ein Plugin-Cache darüber ergibt zwei Schichten, die zu unterschiedlichen Zeitpunkten geleert werden, und am Ende liefern Sie veraltete Seiten aus. Wählen Sie eine, die den Seitencache übernimmt.
- Prüfen Sie die Grundlagen des Hostings: eine unterstützte PHP-Version und einen Objektcache (Redis oder Memcached), wenn die Seite dynamisch ist.
- Seiten mit Konten oder Warenkorb brauchen eine Grenze zwischen dem, was gecacht werden darf, und dem, was nie gecacht werden darf. Bei WooCommerce ist diese Grenze das ganze Thema unseres Ratgebers zum Beschleunigen eines WooCommerce-Shops.
Schritt 4: die Bilder und das Hauptbild
Bilder sind meist der schwerste Teil einer Seite, und das Hauptbild ist oft der LCP. Die ersten Schritte sind alle sicher, weil sie dasselbe Bild in weniger Bytes senden: Kompression, ein modernes Format (WebP oder AVIF) und die richtige Größe für den Bildschirm. Wenn PageSpeed trotz srcset weiter verlangt, Bilder richtig zu dimensionieren, liegt es fast immer am Attribut sizes: siehe unseren Ratgeber zu srcset und sizes.
Kümmern Sie sich dann um das Hauptbild selbst:
- laden Sie es nie per Lazy Loading: Das ist für Bilder unterhalb des sichtbaren Bereichs gedacht;
- helfen Sie dem Browser, es früh zu finden, mit einem Preload und hoher Ladepriorität, und wenn es sich zwischen Smartphone und Desktop unterscheidet, laden Sie eines pro Gerät vor;
- ist es ein CSS-Hintergrund aus einem Builder, entdeckt der Browser es spät: unser Ratgeber zu Hero-Hintergrundbildern zeigt die Lösungen;
- und halten Sie große Illustrationen aus Inline-SVG heraus, das das HTML selbst belastet: Inline-SVG ist für Icons.
Schritt 5: CSS
Der Browser zeigt nichts an, bevor er die Stylesheets im <head> heruntergeladen und gelesen hat. Bei einem Builder-Theme können das mehrere hundert Kilobyte sein, die meisten davon auf der aktuellen Seite ungenutzt. Zwei Techniken setzen hier an:
- Critical CSS: Die Stile dessen, was beim Laden sichtbar ist, werden in die Seite eingebettet, und das vollständige Stylesheet lädt, ohne zu blockieren.
- Genutztes CSS (oft „Unbenutztes CSS entfernen“ genannt): Die Regeln, die die Seite nicht verwendet, werden entfernt.
Beide sind sehr wirksam, und beide können etwas kaputt machen, weil sie nach einer einzigen Momentaufnahme der Seite urteilen. Ein Menü, ein Modal oder ein Mini-Warenkorb, der in diesem Moment geschlossen ist, wirkt unnötig und verliert seine Stile. Wie Sie die fehlende Regel finden und zurückholen: unser Ratgeber zu fehlenden Stilen, mit zwei häufigen Fällen: das Menü, das offen erscheint und der Mini-Warenkorb, der verschwindet.
Schritt 6: JavaScript und Reaktionsfähigkeit
JavaScript belastet alles: Es konkurriert mit dem Hauptbild ums Netzwerk und hält den Hauptthread beschäftigt, wenn der Besucher tippt. Der stärkste Hebel ist, die Skripte, die beim Laden nicht gebraucht werden, bis zur ersten Interaktion zu verzögern. Es ist auch der Hebel, der die meisten Websites kaputt macht:
- ein Menü, das sich erst beim zweiten Tippen öffnet: unser Ratgeber zum Burger-Menü;
- ein Slider, ein Formular oder ein Consent-Banner, das nicht mehr funktioniert: wie Sie das schuldige Skript finden;
- ein Consent-Banner, das spät kommt und den Rest aufhält: unser Ratgeber zu Consent-Bannern.
Verzögern Sie nie, was der Besucher sofort braucht: das Consent-Tool, das Menü, die Skripte für Warenkorb und Zahlung. Und kennen Sie die Grenze der Übung: Manche Themes liefern ihren ganzen Code in einer einzigen großen Datei, was jede Optimierung deckelt. So erkennen Sie sie.
Schritt 7: Layout-Stabilität
Springender Inhalt hat selten eine große Ursache, meist mehrere kleine: Bilder ohne width und height, eine Webschrift, die beim Eintreffen die Textgröße ändert, ein Cookie-Banner oder eine Promo-Leiste, die die Seite nach unten schiebt, ein Slider, der in einem Zustand startet und in einem anderen endet. Reservieren Sie den Platz, und wählen Sie das font-display Ihrer Schriften bewusst: swap zeigt den Text sofort, kann ihn aber verschieben, wenn die Schrift eintrifft, optional verschiebt ihn nie, behält aber manchmal die Ersatzschrift. Page-Builder bringen eigene Ursachen mit, behandelt in unserem CLS-Ratgeber für Divi und Elementor.
Ihr Builder, Ihr Shop
Die obige Reihenfolge gilt für jede WordPress-Website. Manche Setups haben eigene Fallen, mit einem eigenen Ratgeber:
- Divi: viel CSS und viele Hintergrundbilder ab Werk, und Optionen, die sich mit jedem Optimierungs-Plugin überschneiden. Eine Divi-Website Schritt für Schritt beschleunigen.
- Elementor und Divi: Layoutverschiebungen, die typisch für Builder sind. CLS bei Builder-Themes beheben.
- WooCommerce: Cache, Warenkorb-Fragmente, Produktbilder und Zahlungsskripte. Einen WooCommerce-Shop beschleunigen.
Die Methode, die die Website funktionsfähig hält
Nicht alle Hebel sind gleich. Manche verringern nur das Gewicht von Dateien oder geben dem Browser einen Hinweis und können nichts kaputt machen. Andere ändern, was ausgeführt wird, in welcher Reihenfolge oder was ausgeliefert wird, und brauchen einen Test. Unser Ratgeber zu sicheren Optimierungen sortiert sie einzeln.
Der übliche Weg
Jede Option am selben Nachmittag eingeschaltet.
Ein einziger Test, am Desktop, als Administrator angemeldet.
Ein kaputtes Menü, das eine Woche später auffällt, und zehn verdächtige Einstellungen.
Der Weg, der hält
Zuerst die sicheren Hebel, alle auf einmal: Sie können nichts kaputt machen.
Dann ein heikler Hebel nach dem anderen, auf einer Vorlage, geprüft auf Smartphone und Desktop, abgemeldet.
Nach jeder Änderung die Funktionen, die zählen: Menü, Suche, Formulare, Warenkorb.
Sofort eine Labormessung und vier Wochen später die Felddaten zur Bestätigung.
Mit Mantys Core
Mantys Core kann Ihre gesamte Performance-Schicht übernehmen, Cache inklusive, oder neben Ihrem bestehenden Setup laufen. Es folgt der Reihenfolge dieses Ratgebers, Seite für Seite und Gerät für Gerät:
Messen: Ein einziger Befehl startet PageSpeed für dieselbe URL ohne und dann mit den Optimierungen, und ein Bypass mit einer einzigen Anfrage zeigt die rohe Seite neben der optimierten.
Bilder: Es misst die tatsächlich angezeigte Breite jedes Bildes und schreibt
sizesneu, erzeugt WebP, ergänzt fehlende Abmessungen und lädt das Hauptbild vor, erfasst aus echten Renderings auf Smartphone und Desktop, eines pro Gerät, wenn sie sich unterscheiden.CSS: Critical CSS und genutztes CSS werden Seite für Seite aus Renderings auf Smartphone und Desktop erzeugt, ihre Einstellungen können je Vorlage abweichen, und ein ungewöhnlich kleines Ergebnis wird abgelehnt, während die letzte gute Version weiter ausgeliefert wird.
JavaScript: Die Verzögerung lässt gängige Consent-Tools und den Tag Manager standardmäßig aus, bringt die Skripte in die Reihenfolge der Seite zurück und nimmt Ausnahmen je Vorlage an.
Sie entscheiden weiterhin, was auf jeder Seite zählt. Die Plattform erledigt die Arbeit Seite für Seite und lässt Sie belegen, dass jede Änderung die ist, die hilft.
Zusammenfassung
- Lesen Sie zuerst die Felddaten, Vorlage für Vorlage: Sie sagen Ihnen, ob es ein Problem gibt und wo.
- Ordnen Sie die durchgefallene Metrik ihrer Ursachenfamilie zu: LCP zu Server und Bildern, CLS zu reserviertem Platz, INP zu JavaScript.
- Beheben Sie in dieser Reihenfolge: Server und Seitencache, Bilder, CSS, JavaScript, Stabilität.
- Schalten Sie zuerst die sicheren Hebel ein, dann die heiklen einzeln, getestet auf Smartphone und Desktop, abgemeldet.
- Bestätigen Sie sofort im Labor und vier Wochen später im Feld.
Kommentare
Hängen Sie an einem ähnlichen Problem? Beschreiben Sie Ihr Setup und was Sie beobachten. Wir lesen jeden Kommentar und antworten.
Noch keine Kommentare. Teilen Sie als Erste oder Erster Ihren Fall.