Beginnen Sie mit dem Symptom, nicht mit einem Plugin
Eine Seite kann schnell antworten und sich trotzdem langsam anfühlen. Die Time to First Byte (TTFB) misst, wie lange eine Navigation auf das erste Byte der Antwort wartet; der Largest Contentful Paint (LCP) betrifft den größten sichtbaren Inhalt; die Interaction to Next Paint (INP) die Reaktion auf Klicks, Tippen und Tastatur. Wer einen Wert verbessert, behebt die anderen nicht automatisch.
Dies ist ein Diagnoseleitfaden, kein Bericht über ein gemessenes Kundenprojekt. Entscheiden Sie anhand Ihrer eigenen Vorher-nachher-Messungen, ob eine Änderung gewirkt hat.
Schaffen Sie eine vergleichbare Ausgangsbasis
- Wählen Sie repräsentative Templates: einen Artikel, eine Kategorie, ein Produkt und einen Checkout. Beziehen Sie angemeldete und anonyme Sitzungen ein.
- Notieren Sie Gerät, Netzwerk, Standort, URL, Cache-Status und bereitgestellte Version. Wiederholen Sie Labortests unter denselben Bedingungen, statt den besten Wert herauszupicken.
- Prüfen Sie Felddaten in PageSpeed Insights oder der Search Console. Eine URL mit wenig Traffic hat womöglich keine eigenen Daten; Daten auf Ursprungsebene sind breiter gefasst und sollten entsprechend gekennzeichnet werden.
- Trennen Sie Cache-Treffer von Cache-Fehlschlägen. Eine schnelle warme Antwort kann einen langsamen Ursprung während einer Invalidierung oder einer Lastspitze verbergen.
Reduzieren Sie die Serverarbeit auf sichere Weise
Untersuchen Sie die Dokumentanfrage im Netzwerk-Panel des Browsers und analysieren Sie dann PHP, Datenbankabfragen und Aufrufe externer APIs. Langsame Abfragen, wiederholte Remote-Aufrufe, ausgelastete Prozesse und ein weit entfernter Ursprung erfordern unterschiedliche Lösungen. Ein persistenter Objekt-Cache kann wiederholte Datenbankarbeit verringern, ist aber nicht dasselbe wie das Cachen einer vollständigen HTML-Antwort.
Ein Full-Page-Cache kann bei anonymen redaktionellen Seiten helfen. Legen Sie Kontoseiten, Warenkörbe, Checkouts, authentifizierte Antworten und Antworten mit persönlichen Daten nicht in einem öffentlichen Cache ab. Prüfen Sie mit Ihrem Hosting-Anbieter Cookies, Anfragemethoden, Query-Parameter und Cache-Schlüssel. Testen Sie vor dem Deployment mit zwei unabhängigen Sitzungen und bestätigen Sie, dass Inhaltsänderungen den betreffenden Cache invalidieren.
Verbessern Sie, was der Browser darstellt
Ermitteln Sie das tatsächliche LCP-Element in einem Performance-Trace. Ist es ein Bild, machen Sie seine URL im initialen HTML sichtbar, liefern Sie passend skalierte Varianten und laden Sie es nicht per Lazy Loading. Ist es Text, prüfen Sie render-blockierende Styles und das Laden der Schriften. Reservieren Sie Platz für Bilder und Einbettungen, um Layoutverschiebungen zu verringern.
Für den INP reproduzieren Sie die langsame Interaktion und untersuchen den Main Thread. Reduzieren Sie unnötige Arbeit, teilen Sie lange Tasks auf und bündeln Sie Layout-Lesezugriffe vor Schreibzugriffen. Arbeit in einen späteren Task zu verschieben hilft nur, wenn dieser Task nicht selbst zu einem großen Block wird.
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.Prüfen Sie das Nutzungserlebnis nach dem Deployment
Die „guten“ Schwellenwerte der Core Web Vitals liegen bei einem LCP von höchstens 2,5 Sekunden, einem INP von höchstens 200 Millisekunden und einem CLS von höchstens 0,1, bewertet am 75. Perzentil der Besuche. Die TTFB hilft bei der Diagnose, ist aber selbst keine Core Web Vital. Ein Lighthouse-Ladetest misst nicht den INP echter Sitzungen.
Testen Sie Checkout, Navigation, Consent-Tools und Widgets von Drittanbietern erneut. Verfolgen Sie die Feldmessungen über die Zeit; das gleitende Erhebungsfenster bildet ein Release nicht sofort ab. Halten Sie die Änderung und etwaige Regressionen zusammen mit Ihren Messwerten fest.
Häufige Fragen
Garantiert das Bestehen der Core Web Vitals bessere Rankings?
Nein. Ein schnelleres Erlebnis hilft den Lesern und kann die Suchleistung unterstützen, doch Relevanz, hilfreiche Inhalte und andere Signale zählen weiterhin. Behandeln Sie Geschwindigkeit als messbare Produktverbesserung, nicht als Ranking-Versprechen.
Gehört die TTFB zu den Core Web Vitals?
Nein. Die TTFB misst die Verzögerung bis zum ersten Byte der Antwort und hilft, den Server- und Netzwerkpfad zu diagnostizieren. Die Core Web Vitals sind LCP, INP und CLS. Nutzen Sie die TTFB, um eine langsame Antwort zu untersuchen, und prüfen Sie dann getrennt, wann nützliche Inhalte erscheinen und wie sich Interaktionen verhalten.
Warum ist meine gecachte Startseite schnell, der Checkout aber langsam?
Eine öffentliche Startseite kann gecachtes HTML wiederverwenden, während der Checkout frische, sitzungsspezifische Arbeit erfordert. Messen Sie die ungecachte Anfrage und prüfen Sie Datenbankabfragen, Erweiterungen und externe Dienste. Machen Sie den Checkout nicht öffentlich cachebar, nur um einen Test zu verbessern; prüfen Sie Datenschutz und die Korrektheit der Transaktionen.
Wie vergleiche ich die Performance vor und nach einer Änderung?
Halten Sie URL, Gerät, Netzwerkprofil und Cache-Status vergleichbar und wiederholen Sie den Test. Notieren Sie die Bandbreite der Ergebnisse und testen Sie dieselbe Kundenaktion. Nutzen Sie Felddaten, sobald sie verfügbar sind; ein einzelner schneller Labortest beschreibt nicht alle Besucher. Die Performance-Checkliste bietet eine umfassendere Prüfreihenfolge.
Quellen und weiterführende Literatur
Weiterlesen
Nutzen Sie die WordPress-Speed-Checkliste mit 47 Punkten für ein umfassenderes Audit oder erfahren Sie mehr über den Service für Website-Performance.
Leave a Reply