Sprachen

Seitengeschwindigkeit & Core Web Vitals Prüfer

Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first — real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.

Built by Patrick Stox

field data first (CrUX) · lab fallback (Lighthouse) · mobile + desktop

Die Prüfungen laufen auf unserem Server. Wir rufen die von dir eingegebene URL ab und speichern die Ergebnisse nicht. Anonymous aggregate stats count a domain once via a rotating hash for research posts; URLs are never stored. Anonyme Ergebniszähler auf Ausführungsebene können für aggregierte Forschung verwendet werden; URLs, Domains, IP-Adressen und Kennungen werden nie einbezogen, und Statistiken werden erst ab 100 Ausführungen veröffentlicht.

Rückmeldung
Fehler melden

Funktioniert etwas in Seitengeschwindigkeit & Core Web Vitals Prüfer nicht? Teile uns mit, was passiert ist — die Meldung geht direkt an eine private Prüfwarteschlange, nicht in eine öffentliche Liste.

Gesendete Angaben 
 Werkzeugeingaben, Uploads, eingefügte Quellen, vollständige Ergebnisse, Abfrageparameter und URL-Fragmente werden nicht automatisch angehängt. Du kannst die oben ausgewählte Passage bearbeiten oder entfernen. Browser- und Missbrauchsschutz-Metadaten werden zur Spamabwehr verarbeitet. 
  
 
  
 
 
  
 
 
   
      
 
       
     
  
      

Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses
        for the page-experience signal; it updates daily, so repeat checks within 24 hours are
        served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them
        to differ from field data and to vary between runs. Lab audits can't measure INP (it needs
        real users).

   
 
   
        
Über dieses Werkzeug
Führe einen Page-Speed-Test mit echten Chrome-Nutzerdaten (CrUX) und einem Lighthouse-Lab-Fallback aus. Der erste Satz nennt, ob die Seite die Core Web Vitals besteht, und die priorisierte Liste zeigt, was du zuerst beheben solltest. Mobilgerät und Desktop bleiben getrennt sichtbar.
Feld- und Labordaten beantworten unterschiedliche Fragen: Feldwerte beschreiben reale Nutzer, Labordaten sind eine simulierte Diagnose und schwanken zwischen Läufen.
Funktionen
  • Verdict-first-Satz mit der einzelnen schlechtesten Metrik auf dem Gerät, das Google für Rankings verwendet
  • CrUX-Felddaten für URL oder Ursprung mit automatischem Fallback auf einen Lighthouse-Laborlauf
  • Mobile und Desktop nebeneinander mit klar gekennzeichneten Datenquellen und offiziellen Schwellenwerten
  • Priorisierte Diagnosefixes aus tatsächlich ausgelösten Lighthouse-Audits sowie Massen-Scorecard für bis zu fünf Ursprünge mit CSV-Export
So funktioniert es
Gib eine vollständige URL ein und starte den Test. Das Werkzeug fragt zuerst URL-Felddaten aus CrUX ab, fällt bei fehlender Stichprobe auf Ursprung-Felddaten und anschließend auf einen simulierten Lighthouse-Lauf zurück. Es markiert für jede Karte die Quelle, bewertet LCP, INP und CLS gegen die offiziellen Schwellenwerte und ordnet die ausgelösten Fixes nach Priorität.
Einschränkungen
  • CrUX benötigt genügend reale Chrome-Aufrufe in einem rollierenden 28-Tage-Fenster; neue oder wenig besuchte Seiten können auf Ursprung- oder Labordaten zurückfallen.
  • Lighthouse-Läufe nutzen simulierte Drosselung, dauern ungefähr 30 Sekunden und können zwischen Läufen variieren; sie sind keine regionalen Nutzerwerte.
  • Ein bestandener Score beweist weder vollständige Barrierefreiheit noch gute Conversion oder eine bestimmte Platzierung. Prüfe die konkreten Audits und die Zielregion separat.
Häufig gestellte Fragen
Welche Grenzwerte gelten für die `Core Web Vitals`?
Eine Seite besteht, wenn ihr Wert im 75. Perzentil bei allen drei Metriken im Bereich „gut“ liegt: `Largest Contentful Paint` (LCP) höchstens 2,5 Sekunden, `Interaction to Next Paint` (INP) höchstens 200 Millisekunden und `Cumulative Layout Shift` (CLS) höchstens 0,1. LCP über 4 Sekunden, INP über 500 Millisekunden oder CLS über 0,25 gilt als „schlecht“; Werte dazwischen erfordern eine Verbesserung. Das Tool verwendet genau diese offiziellen Grenzwerte.
Warum unterscheiden sich meine `Core Web Vitals`-Werte von `PageSpeed Insights`?
Sie sollten übereinstimmen, wenn beide dieselbe Quelle abfragen. Dieses Tool zeigt zuerst Felddaten aus dem `Chrome UX Report` (`CrUX`) – denselben Datensatz echter Nutzer, den die Suche verwendet – und greift erst dann auf einen `Lighthouse`-Labortest zurück, wenn für die Seite keine Felddaten vorliegen. Labordaten beruhen auf simulierter Drosselung und unterscheiden sich von Lauf zu Lauf; deshalb stimmt ein Laborwert nicht unbedingt mit einem Feldwert überein. Wenn Ihre `PageSpeed Insights`-Zahl aus dem Labor stammt und unsere aus Felddaten (oder umgekehrt), liegt darin der Unterschied.
Warum meldet der Prüfer für meine URL „keine Felddaten“?
`CrUX` meldet eine URL erst, wenn sie genügend `Chrome`-Besuche für eine statistisch stabile Stichprobe der letzten 28 Tage hat. Seiten mit wenigen Besuchen oder ganz neue Seiten erreichen diese Schwelle nie. Dann greift das Tool auf Felddaten auf Ursprungsebene (die gesamte Website) oder einen simulierten `Lighthouse`-Labortest zurück und kennzeichnet auf jeder Karte die verwendete Quelle, damit Sie Labornummern nicht mit Daten echter Nutzer verwechseln.
Kann dieses Tool INP messen?
Es kann INP aus Felddaten melden, weil INP anhand echter Nutzerinteraktionen gemessen wird. Ein `Lighthouse`-Labortest kann keine INP-Zahl liefern, da dort keine echten Nutzer mit der Seite interagieren; ein reines Laborergebnis zeigt für diese Metrik „kein Labor-INP“. Wenn Sie einen INP-Wert benötigen und die Seite keine Felddaten hat, brauchen Sie echte Besuche (oder die INP-Werkzeuge der `Chrome DevTools` für Ihre eigenen Interaktionen).
Welches Gerät verwendet Google für die Platzierung – Mobilgerät oder `Desktop`?
Google bewertet das Seitenerfahrungssignal auf Mobilgeräten. Der Prüfer kennzeichnet die Mobilgerätekarte als „maßgeblich für die Google-Platzierung“; `Desktop`-Werte dienen als Kontext und entscheiden die Bewertung für Mobilgeräte nicht.
 
Nächster SchrittVerlauf und Wettbewerbsvergleich der Core Web Vitals — look up the exact spec and expected values.
Anleitung auf Englisch verfügbar.
Das könnte dich auch interessieren
WerkzeugVerlauf und Wettbewerbsvergleich der Core Web VitalsWerkzeugHTTP-Header-PrüferWerkzeugDNS-Prüfer
       
 
Häufige Probleme und ihre Behebung
 
     
  •  Fehler LCP ist schlecht Lösung: Senken Sie LCP unter 2.5 Sekunden, indem Sie die gemessene LCP-Komponente und ihren kritischen Bereitstellungspfad optimieren; prüfen Sie anschließend aktuelle Felddaten. 
  •  Warnung Das LCP muss verbessert werden Lösung: Bringen Sie LCP unter 2.5 Sekunden, indem Sie die gemessene LCP-Komponente priorisieren und Verzögerungen auf ihrem Bereitstellungspfad entfernen. 
  •  Fehler INP ist schlecht Lösung: Senken Sie INP unter 200 ms, indem Sie die längsten Interaktionsaufgaben verkürzen und die JavaScript-Arbeit im Hauptthread reduzieren. 
  •  Warnung Das INP muss verbessert werden Lösung: Bringen Sie INP unter 200 ms, indem Sie lange Interaktionshandler aufteilen und die Arbeit im Hauptthread abgeben. 
  •  Fehler CLS ist schlecht Lösung: Senken Sie CLS unter 0.1, indem Sie Platz für verschiebbare Elemente reservieren und späte Wechsel von Schriften oder Inhalten verhindern. 
  •  Warnung Das CLS muss verbessert werden Lösung: Bringen Sie CLS unter 0.1, indem Sie stabile Abmessungen und Platzhalter für Elemente hinzufügen, die sich nach dem ersten Rendern bewegen. 
  •  Warnung Renderblockierende Ressourcen können das LCP verzögern Lösung: Binden Sie kritisches CSS direkt ein und verschieben Sie unkritische Formatvorlagen oder Skripte, die das Rendern der LCP-Ressource blockieren. 
  •  Warnung Die Serverantwort kann das LCP verzögern Lösung: Verringern Sie die anfängliche Serverantwortzeit mit Zwischenspeicherung, schnellerer Serververarbeitung und einem CDN in Nutzernähe, bevor Sie die LCP-Ressource optimieren. 
  •  Warnung Die Bildauslieferung kann das LCP verzögern Lösung: Verkleinern und komprimieren Sie das LCP-Bild, stellen Sie es mit srcset in einem modernen Dateityp bereit und laden Sie es vorab, wenn es spät entdeckt wird. 
  •  Information Kritisch Ursprung fehlt preconnect Lösung: Fügen Sie preconnect nur für den kritischen Ursprung eines Drittanbieters hinzu, der die LCP-Ressource bereitstellt, einschließlich crossorigin, falls erforderlich. 
  •  Warnung Code von Drittanbietern trägt zum INP bei Lösung: Stellen Sie unkritische Tag-Manager, `Chat`, Analyse- und Testskripte zurück oder verzögern Sie sie bis nach der ersten Interaktion; entfernen Sie ungenutzte Anbieter. 
  •  Warnung Arbeit im Hauptthread trägt zum INP bei Lösung: Teilen Sie lange Aufgaben im Hauptthread in kleinere Abschnitte auf, verlagern Sie aufwendige Berechnungen in einen `Worker` und minimieren Sie synchrone `Layout`-Arbeit. 
  •  Warnung Ungenutztes JavaScript trägt zum INP bei Lösung: Teilen Sie den Code nach Pfad und Komponente auf, damit die Seite nur das für die aktuelle Ansicht benötigte JavaScript herunterlädt, analysiert und ausführt. 
  •  Warnung Elemente mit Positionsverschiebung tragen zum CLS bei Lösung: Geben Sie den gemeldeten Bildern, Einbettungen, Anzeigen und eingefügten Bereichen explizite Abmessungen oder reservierte Platzhalter, bevor sie geladen werden. 
  •  Warnung Das Laden von Schriften trägt zum CLS bei Lösung: Laden Sie kritische Schriften vorab, verwenden Sie metrikkonforme Ersatzschriften und wählen Sie für font-display ein Verhalten, das einen späten, layoutverändernden Wechsel vermeidet. 
  •  Warnung Labor- und Felddaten zeigen unterschiedliche Ergebnisse Lösung: Verwenden Sie den `Lighthouse`-`Trace`, um den Engpass des simulierten Laufs zu diagnostizieren, und beobachten Sie die passende `CrUX`-Metrik, bevor Sie eine Verschlechterung bei echten Nutzern behaupten oder abschließen. 
    •