Die meisten Performance-Projekte, die wir von jemand anderem übernehmen, sehen gleich aus. Jemand hat noch ein Cache-Plugin installiert, die Presets durchgeklickt und nach zwei Tagen begonnen, Änderungen zurückzunehmen, weil der Warenkorb oder das Menü zerfiel. Niemand hat den Ausgangspunkt festgehalten, also lässt sich nicht sagen, was geholfen und was geschadet hat. Wir arbeiten seit Jahren mit WordPress, und dasselbe Szenario kehrt unabhängig von der Projektgröße wieder. Die Reihenfolge der Schritte wiegt hier schwerer als die Wahl des Werkzeugs, deshalb beginnt die Optimierung der Seitengeschwindigkeit mit einem Plan und nicht mit einer Installation.
Inhaltsverzeichnis
Zuerst messen, dann erst irgendein Plugin
Bevor Sie die Konfiguration anfassen, legen Sie eine Kopie des Child-Themes und der Datenbank an. Einen Teil der Korrekturen wird man zurücknehmen müssen, und ohne Bezugspunkt wird das Zurücknehmen zum Raten. Ein paar Minuten Arbeit, die später eine ganze Woche retten.
Die Messung für Mobil und Desktop liegt in getrennten Cache-Einträgen. Ein einfacher Abruf der Adresse wärmt nur die Desktop-Variante auf, deshalb trifft der Mobiltest auf einen kalten Cache und zeigt ein zu niedriges Ergebnis. Der erste Durchlauf nach einer vollständigen Leerung fällt immer schlechter aus, weil die zusammengefassten CSS- und JavaScript-Dateien erst erzeugt werden.
Dieselbe Konfiguration liefert zwischen den Durchläufen unterschiedliche Zahlen, deshalb schaue ich auf den Median aus mehreren Messungen und nicht auf einen einzelnen Wert. Für das Iterieren ist ein lokales Werkzeug bequemer: Es arbeitet schnell und begrenzt die Anfragen nicht. Das Urteil fällt das Werkzeug von Google, während der Indikator im Hosting-Panel allein nichts darüber sagt, was eigentlich zu reparieren ist.
Wie Sie den Bericht lesen, um den Engpass zu treffen statt zu raten
Den Bericht öffnen wir immer in derselben Reihenfolge, denn erst sie fügt sich zu einer Diagnose:
- die rohen Metriken, bevor Sie auf die Liste der Vorschläge sehen
- der LCP-Knoten und was er überhaupt ist
- der Zeitplan der Netzwerkanfragen
- die Aufschlüsselung der Arbeit des Haupt-Threads
- die Ursachen der Layoutverschiebungen
Die Summe aus Server-Antwortzeit, Verzögerung bei der Erkennung des Bildes und dessen Ladezeit zeigt sofort, ob das Hosting, das Template oder die Grafik schuld ist. Wenn die Server-Antwortzeit das Ergebnis nach unten zieht, holt das kein Plugin auf, und das Gespräch wandert zum Thema leistungsfähiges Hosting für Firmenwebseiten. Drei getrennte Gespräche und drei getrennte Kostenschätzungen.
Wenn der Haupt-Thread vor allem mit Stilen und der Neuberechnung des Layouts beschäftigt ist und nicht mit dem Ausführen von Skripten, bringt das Herausschneiden von JavaScript nichts. Suchen Sie dann nach der Größe des Stylesheets und der Zahl der Elemente im Baum. Ein Eintrag über eine lange Aufgabe, der auf das Dokument selbst zeigt, bedeutet Inline-Skripte und im Template eingefügte Handler, keine Bibliotheksdatei. Und der häufigste Fehler: Die Arbeit beginnt bei dem, was am leichtesten anzuklicken ist, statt bei dem größten Kostenpunkt im Bericht.
LCP: schuld ist meist die Sichtbarkeit des Elements, nicht das Gewicht des Bildes
Das teuerste Einzelproblem ist ein LCP-Element, das bis zur Initialisierung von JavaScript versteckt ist. Ein Karussell, ein Slider oder ein per Skript gebauter Abschnitt warten auf die gesamte Abhängigkeitskette. Die Komprimierung der Datei rettet dann nichts, wenn der Browser vom Bild erst nach der Ausführung des Codes erfährt.
Ein Preload-Hinweis wirkt nur, wenn er ganz oben im Abschnitt head steht, vor den strukturierten Daten und den Analyseskripten. Weiter unten verliert er seinen Sinn, weil der Parser ihn zu spät erreicht. Prüfen Sie außerdem, ob das Banner auf dem Telefon nicht in voller Desktop-Größe statt in der von WordPress erzeugten Variante ausgeliefert wird. In Premium-Templates ist das ein nahezu serienmäßiger Fehler.
Hintergrundbilder, die ein Skript in einem Rutsch malt, zusammen mit denen unterhalb des sichtbaren Bereichs, konkurrieren mit dem LCP-Bild um Bandbreite und können den gesamten Gewinn aus der Grafikoptimierung auffressen. Bei Karussellen lauert noch eine Falle: Den ersten Slide freizulegen, ohne die übrigen zu verbergen, repariert LCP, erzeugt aber Layoutverschiebungen. Eine Metrik wächst auf Kosten der anderen.
CLS und Schriften: ein Kompromiss, den keine einzelne CSS-Regel löst
Regeln, die das Layout absichern und im Stylesheet des Themes stehen, wirken nicht, wenn dieses Stylesheet asynchron geladen wird. Sie müssen inline in den Abschnitt head und von der Optimierung ausgeschlossen werden, sonst treffen sie nach dem ersten Malen ein.
Derselbe Mechanismus betrifft die Schriftarten. Font-Deklarationen in einem zusammengefassten, asynchronen Stylesheet kommen zu spät, deshalb verschiebt der Wechsel der Schrift die Überschriften. Das Einfügen der Deklarationen inline beseitigt das Reihenfolgeproblem, hält aber die Textanzeige zurück und verschlechtert FCP. Das Preloaden der Schnitte verbessert die Stabilität, nur reisen diese gut ein Dutzend Kilobyte mit hoher Priorität neben dem LCP-Bild und verderben das Ergebnis auf der anderen Seite. Wählen Sie.
Ohne einen Fallback mit angepassten Metriken wählen Sie zwischen FCP und CLS, und die Variante mit font-display: optional ist eine Entscheidung des Markeninhabers, keine technische. Denken Sie auch daran, dass automatisch erzeugtes kritisches CSS keine Stile enthält, die JavaScript nachträglich hinzufügt, deshalb wird die Höhenreservierung für Slider von Hand geschrieben.
TBT steigt nach einer guten Änderung, und das ist kein Rückschritt
Die Arbeit von JavaScript ist im Grunde konstant. Solange die Seite langsam lud, lief sie außerhalb des Messfensters ab. Nach der Beschleunigung rückt sie hinein und wird mitgezählt. Ein TBT-Sprung direkt nach der Verkürzung von FCP ist ein Signal, dass die Änderung gewirkt hat, und kein Grund, sie zurückzunehmen.
Skripte bis zur ersten Interaktion zu verzögern, ist verlockend. Auf jQuery, das Menü und den Slider angewendet, endet es aber mit einer Navigation, die nicht funktioniert. Das ist ein Umweg, keine Diagnose, und so muss man es dem Kunden auch benennen. Zusammenfassen und Verzögern sind dabei gekoppelt: Eine Datei, die nur aus einer Liste ausgeschlossen ist, landet trotzdem im gemeinsamen, verzögerten Paket.
Schließen Sie konkrete Dateien aus statt ganzer Verzeichnisse. Der Ausschluss eines Verzeichnisses zieht auch schwere Bibliotheken auf den kritischen Pfad, die dort in Ruhe bleiben sollten. Prüfen Sie bei der Gelegenheit, ob das Muster zum tatsächlichen Namen passt, da die minifizierte Variante einer Bibliothek anders heißt als die Quellfassung.
Wartung: was drei Monate nach der Einführung kaputtgeht
Alle Änderungen gehen in das Child-Theme, und Dateiaustausche erledigen wir mit Filtern auf den Handles. Sonst löscht die erste Aktualisierung des Templates die Arbeit spurlos. Ausgetauschte Minifikate und Font-Subsets müssen nach jeder Aktualisierung neu erzeugt und in der Adresse versioniert werden, denn ein langer Browser-Cache kann eine alte Datei monatelang halten.
Die Warteschlange für die Erzeugung des kritischen CSS ist begrenzt und verstopft bei Mehrsprachigkeit mit Übersetzungen und technischen Adressen. Die Folge? Ein Teil der Unterseiten bekommt es nie. Das Leeren des Caches löscht dabei weder das kritische CSS noch die mobile Variante. Das sind getrennte Mechanismen, und man prüft sie getrennt.
Nach jeder Änderung im Code prüfen wir das Login, die Sitemap, den RSS-Feed, die 404-Fehlerseite und die Sprachversionen. Ein Änderungsprotokoll mit einer Liste der Sackgassen erspart dem nächsten Dienstleister die Wiederholung von Tests, die schon einmal zurückgenommen wurden. Ohne diese Disziplin fällt das Ergebnis von Core Web Vitals WordPress von allein zurück, nach Plugin-Updates und gewöhnlichen Inhaltsänderungen.
Zusammenfassung: eine vernünftige Reihenfolge statt einer Plugin-Liste
Messen, den Bericht in der festgelegten Reihenfolge lesen, LCP reparieren, dann die Layoutstabilität und ganz zum Schluss die Belastung des Haupt-Threads. So sieht bei uns die Optimierung der Seitengeschwindigkeit in der Praxis aus, und diese Abfolge ergibt sich aus den Abhängigkeiten zwischen den Metriken, nicht aus Vorlieben.
Trennen Sie das Gemessene vom Beurteilten und sagen Sie offen, wann eine Korrektur ein Umweg ist. Das Ergebnis der Mobilmessung streut deutlich, berichten Sie also eine Spanne aus mehreren Durchläufen statt einer einzelnen eindrucksvollen Zahl. Ein Kunde, der diese Streuung versteht, ruft nicht um sieben Uhr morgens wegen zwei Punkten nach unten an.
Wenn Sie ein Performance-Audit, die Modernisierung eines bestehenden Systems, Integrationen, Automatisierung oder die Umsetzung eines MVP brauchen, sprechen Sie uns an. Es lohnt sich, das mit einem SEO-Audit der Website zu verbinden, denn Geschwindigkeit und Sichtbarkeit in der Suchmaschine ziehen einander mit. Wir sehen uns Ihre Konfiguration gern an und sagen Ihnen, was sich wirklich zu verbessern lohnt.
