Eine langsame Website hat nicht nur eine mögliche Ursache. Der Server antwortet spät, das Hauptbild startet zu spät, ein Skript blockiert die Interaktion oder ein Banner verschiebt den Button beim Tippen. Jede Störung braucht eigene Belege und Reparaturen.
Beginnen Sie mit wichtiger Seite, Gerät und Aktion. Eine schnelle Desktop-Startseite beweist keinen schnellen mobilen Checkout. Unterschiedliche Tests können ein Release aus falschen Gründen besser oder schlechter erscheinen lassen.
Umfang dieser Prüfung
Was messbar ist
- Öffentliche Website-Leistung über PageSpeed Insights, Lighthouse-Laborwerte und CrUX-Feldmetriken, wenn verfügbar.
- Mobile oder Desktop-Strategie, gemessene URL, verfügbare Möglichkeiten, Diagnosen und Belege je Metrik.
Was sie nicht belegt
- Ein Laborlauf ist eine kontrollierte Stichprobe. Felddaten können fehlen oder die ganze Herkunft statt die exakte Seite beschreiben.
- Local Agent verwendet eine separate begrenzte lokale Messung, nicht gehostetes Lighthouse oder CrUX.
Zugang folgt Tarif und Anbieterverfügbarkeit. Fehlende Werte werden als nicht verfügbar gekennzeichnet statt durch erfundene Messungen ersetzt.
1. Labor und Feld unterschiedlich lesen
Lighthouse führt ein wiederholbares Diagnoseszenario aus. CrUX aggregiert geeignete echte Nutzungserlebnisse, soweit ausreichend Daten vorliegen. Nutzergruppen, Geräte, Netze und Zeitfenster können Abweichungen erklären. Die PageSpeed-Insights-Dokumentation beschreibt beide Quellen.
Lesen Sie die Quelle jeder Metrik: Ein Bericht kann für einen Wert Felddaten, für einen anderen Laborersatz enthalten. Prüfen Sie, ob die Daten die URL oder die gesamte Herkunft betreffen. Fehlende Felddaten bedeuten fehlende Stichprobe, weder Core-Web-Vitals-Durchfallen noch fehlende Besucher.
2. Die drei Core Web Vitals verstehen
| Metrik | Bedeutung | Gute Referenzgrenze |
|---|---|---|
| LCP | Darstellung des größten sichtbaren Inhaltselements | Höchstens 2,5 Sekunden |
| INP | Reaktion auf Nutzerinteraktionen | Höchstens 200 Millisekunden |
| CLS | Unerwartete Layoutverschiebung | Höchstens 0,1 |
Im Feld werden diese Grenzen am 75. Perzentil der Besuche und getrennt nach Gerätekategorien beurteilt. Siehe Web Vitals. Ein einzelner Laborwert ist kein Feldnachweis. Time to First Byte und First Contentful Paint sind hilfreiche Diagnosen, aber keine zusätzlichen Core Web Vitals.
3. Symptome mit Belegen verbinden
Die folgenden Prioritäten sind Beispiele. Auswirkungen auf eine Kernaufgabe zählen mehr als ein Diagnosetitel.
| Symptom | Kontextpriorität | Zu untersuchen |
|---|---|---|
| Hauptinhalt erscheint spät | Hoch, wenn das Angebot unklar bleibt | LCP-Element, Antwort und Anfragezeiten |
| Kaufbutton reagiert langsam | Hoch im Kaufprozess | Interaktionsspur und lange Hauptthread-Aufgaben |
| Inhalt rutscht unter dem Zeiger | Hoch bei Fehlaktionen | Verschobene Elemente und reservierte Maße |
| Großes ungenutztes Skript | Mittel bis zur Kostenmessung | Bytes, Ausführung und Nutzung |
Geschätzte Einsparung ist nicht garantiert. Vorschläge können sich überschneiden, schwere Ressourcen notwendig sein. Erst den Engpass bestätigen, dann Funktionen entfernen oder Infrastruktur ändern.
4. Die verzögernde Komponente reparieren
Später Inhalt: LCP-Element identifizieren. Bei später Serverantwort Backend und Cache prüfen. Ein spät entdecktes Hauptbild früh im Dokument zugänglich machen und das erste wichtige Bild nicht verzögert laden. Passende Größe ausliefern. Der LCP-Leitfaden gliedert die Phasen.
Langsame Interaktion: teure Handler, synchrones Rendering und Drittanbieterarbeit untersuchen. Lange Aufgaben aufteilen, unnötige Arbeit um die Aktion reduzieren. Total Blocking Time hilft im Labor, ist aber nicht INP. Verwenden Sie INP-Hinweise zusammen mit einer echten Interaktionsaufzeichnung.
Verschiebungen: Platz für Bilder, Einbettungen und Banner vorab reservieren. Die konkrete Lösung hängt von bewegtem Element und Ursache ab.
5. Vorher und nachher kontrolliert vergleichen
- Exakte URL, Strategie, Zeitpunkt und Quelle notieren.
- Eine kohärente Änderung am bestätigten Engpass vornehmen.
- Mehrere vergleichbare Läufe wiederholen und den Trend statt des besten Werts betrachten.
- Seite visuell prüfen und Hauptaktion durchführen.
- Andere Vorlagen mit derselben Komponente auf Regression prüfen.
- Felddaten später beobachten; ihr Aggregationsfenster bildet Releases nicht sofort ab.
Diagnosebelege statt nur Score-Screenshots sichern. Wenn ein schnelleres Bild Layoutbewegung erzeugt, ist die Reparatur unvollständig. Schmale Ansichten und verspätete Inhalte wie Cookiehinweise, Schriften und Widgets nachprüfen.
6. Grenzen des Tests erkennen
Eine Navigation testet nicht jeden Zustand einer komplexen Anwendung. Die Seite kann schnell laden und nach längerem Bearbeiten schlecht reagieren. Im Labor gelten eventuell andere Einwilligungen, Konten oder Inhalte als beim echten Kunden.
Sitelemetry nennt Strategie und verfügbare Quellen. Local Agent prüft lokale Lieferung mit einer anderen begrenzten Methode; sein Ergebnis ist numerisch nicht mit öffentlichem Lighthouse vergleichbar. Fehlt PageSpeed, Messung beheben oder wiederholen statt eine leere Zahl als null zu lesen. Belege sollen klar sagen, was tatsächlich lief.
7. Geschwindigkeit in die Produktarbeit einbauen
Definieren Sie Budgets für eigene Vorlagen und Interaktionen: Bildvolumen, Drittanbieterskripte und teure Clientarbeit eignen sich zur Prüfung. Bei Chat, Analytics oder Animation vor und nach dem Einbau testen statt Kostenfreiheit anzunehmen.
Richtigkeit, Zugänglichkeit und Geschwindigkeit gemeinsam erhalten. Ein stabiles Formular mit Fortschrittsanzeige ist wertvoller als ein Score durch versteckte Inhalte. Wichtigste mobile Verkaufsseite wählen, verfügbare Messung starten und einen Auftrag mit messbarer Abnahme schreiben. Ergänzen Sie Barrierefreiheit und Integrationen, wenn dieselbe Komponente alle drei betrifft.
Häufige Fragen
Warum unterscheiden sich Scores zwischen Läufen?
Netz, Serverlast, Cache und Laborvariabilität wirken mit. Vergleichen Sie dieselbe URL und Gerätewahl mehrfach und lesen Sie die Einzelmetriken.
Bedeutet fehlendes CrUX, dass die Seite langsam ist?
Nein. Geeignete Felddaten fehlen für diesen Umfang. Das Labor dient der Diagnose, ohne Feldbestehen oder -durchfallen zu behaupten.
Sind TBT und INP identisch?
Nein. TBT diagnostiziert blockierende Arbeit im Labor; INP beschreibt Reaktionsfähigkeit während Nutzerinteraktionen.
Quellen und weiterführende Links
- Google: Informationen zu PageSpeed Insightsdevelopers.google.com
- web.dev: Web Vitalsweb.dev
- web.dev: Largest Contentful Paint optimierenweb.dev
- web.dev: Interaction to Next Paint optimierenweb.dev
Vom Sitelemetry-Team mit dem Prüfumfang des Produkts und verlinkten Primärquellen abgeglichen. Beispiele dienen der Veranschaulichung, sofern kein beobachteter Fall ausdrücklich genannt wird.
