Kurz und einfach erklärt
Google zeigt in der Search Console einen Bericht über das Tempo Ihrer Website. Er heißt Core-Web-Vitals-Bericht. Die Werte stammen von echten Besuchern.
Der Bericht fasst ähnliche Seiten zu Gruppen zusammen. Eine Gruppe sind zum Beispiel alle Seiten mit Produkten. In der Liste steht nur eine Seite als Beispiel.
Hinter einer Gruppe steht meist eine Vorlage. Die Vorlage ist das Gerüst für viele Seiten. Wer dort einen Fehler behebt, hilft allen Seiten zugleich.
Für Handy und Computer gibt es zwei getrennte Teile. Nach einer Reparatur können Sie eine Prüfung starten. Google prüft dann vier Wochen lang nach. Erst dann steht das Ergebnis fest.
Wir helfen Ihnen, den Bericht zu lesen. Wir finden die Ursache und verbessern die Vorlage.
Der Core-Web-Vitals-Bericht ist für viele Betreiber die erste Stelle, an der Google ihnen sagt, dass ihre Seiten zu langsam sind. Er zeigt Balken in drei Statusfarben, eine Tabelle mit Problemen und dazu einzelne Beispiel-URLs. Wer ihn wie eine Liste einzelner Seiten liest, optimiert schnell an der falschen Stelle: an der einen Adresse, die als Beispiel dasteht, statt an der Vorlage, die hinter vielen ähnlichen Seiten steckt. Und wer nach einer Korrektur auf „Tracking starten“ klickt, wartet oft länger als erwartet und hält die träge Validierung für einen Misserfolg. Dieser Beitrag erklärt, wie der Bericht gruppiert, welche Zahl hinter einem Gruppenwert steht, warum Mobilgeräte und Desktop getrennt laufen, was „Keine Daten verfügbar“ bedeutet und wie aus dem Bericht ein konkreter Arbeitsauftrag für Ihr Team wird.
Das Wichtigste in Kürze
- Der Bericht gruppiert nach Status, Messwert und URL-Gruppe. Eine Gruppe erhält je Gerätetyp den Status ihres schlechtesten Messwerts: Ein langsamer CLS macht sie „Langsam“, auch wenn LCP und INP gut sind (Search Console-Hilfe).
- Der Gruppenwert ist kein Durchschnitt: Er gibt an, welchen Wert 75 Prozent (Search Console-Hilfe) der Seitenaufrufe der letzten 28 Tage erreicht oder unterschritten haben. Einzelne Ausreißer-URLs liegen besser oder schlechter.
- Eine Beispiel-URL steht für eine Gruppe ähnlicher Seiten, hinter der vermutlich ein gemeinsames Gerüst steckt. Korrigiert wird die Vorlage, nicht die eine Adresse; die Mitglieder einer Gruppe sind nach Impressionen sortiert.
- Mobilgeräte und Desktop haben getrennte Berichte mit eigenem Status. Mobil fällt das Ergebnis meist schwächer aus: 48 Prozent gegenüber 56 Prozent der Websites bestanden 2025 alle drei Core Web Vitals (Web Almanac 2025).
- Nach „Tracking starten“ beobachtet die Search Console 28 Tage (Search Console-Hilfe) lang, ob das Problem noch bei einer URL auftritt. Schon eine einzige betroffene URL lässt die Validierung scheitern.
- Für den Arbeitsauftrag gilt: erst alle Probleme mit Status „Langsam“, dann die Gruppen mit den meisten oder wichtigsten URLs. Im Export stehen nicht verfügbare Werte als Null – sie sind ungemessen, nicht gut.
Was der Bericht zeigt und was nicht
Der Bericht stützt sich auf tatsächliche Nutzungsdaten, also auf Messungen bei echten Besuchern und nicht auf einen Testlauf. Die Daten stammen aus dem Chrome UX Report (CrUX), der anonymisierte Messwerte von Chrome-Nutzern sammelt, die Ihre Seiten aufrufen (Search Console-Hilfe). Daraus folgen einige Eigenschaften, die man kennen sollte, bevor man aus einer Farbe Schlüsse zieht. Wer den Core-Web-Vitals-Wert seiner Website bewerten will, braucht sie alle.
- Nur indexierte URLs: Im Bericht können nur indexierte Adressen erscheinen. Seiten, die per noindex gesperrt sind oder nach Weiterleitungen nicht erfolgreich antworten, fallen schon bei CrUX heraus, weil dort dieselben Kriterien wie bei Suchmaschinen gelten (Chrome for Developers).
- Eine Stichprobe: Der Bericht enthält keine vollständige Liste aller indexierten URLs, sondern eine Auswahl, an der sich die Leistung der Website beurteilen lässt (Search Console-Hilfe).
- Die aufgerufene Adresse zählt: Die Daten werden der tatsächlichen URL zugeordnet, nicht der kanonischen. Bei der Unterscheidung von Seiten berücksichtigt der Bericht URL-Parameter, PageSpeed Insights entfernt sie dagegen (Search Console-Hilfe).
- Alle Standorte zusammen: Zugriffe aus allen Ländern werden kombiniert. Viele Besuche aus Regionen mit langsamen Verbindungen drücken die Werte, auch wenn Ihr Server schnell antwortet (Search Console-Hilfe).
- Nicht jeder Browser zählt: In CrUX fließen Chrome am Desktop und Chrome unter Android ein. Chrome unter iOS, Android-Apps mit WebView und andere Chromium-Browser liefern keine Daten (Chrome for Developers).
Der Bericht ist damit ein Frühwarnsystem für Muster und kein Messgerät für einzelne Seiten. Die Hilfe sagt das selbst: Es sei nicht die primäre Aufgabe des Berichts, Aussagen über den Status einzelner URLs zu treffen; er soll die Leistung der Website als Ganzes transparent machen und Probleme aufdecken, die mehrere Seiten betreffen (Search Console-Hilfe). Für eine konkrete Adresse ist ein externer Test gedacht, etwa PageSpeed Insights.
Warum sich der genaue Blick lohnt: Google empfiehlt Websiteinhabern, gute Core-Web-Vitals-Werte anzustreben, um in der Google Suche erfolgreich zu sein und allgemein eine hohe Nutzerfreundlichkeit zu bieten (Google Search Central). Search Console, PageSpeed Insights und web.dev nennen dieselben Grenzwerte: Ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1 gelten als gut. Der Bericht übersetzt diese Grenzen in drei Farben – und genau in dieser Übersetzung stecken die Regeln, die man kennen muss.
Abgrenzung
Die Gruppenlogik: Status, Messwert, URL-Gruppe
Der Bericht ordnet jede erfasste Adresse auf drei Achsen ein: nach Status („Langsam“, „Optimierung erforderlich“, „Gut“), nach Messwerttyp (CLS, INP und LCP) und nach URL-Gruppe, also nach Gruppen ähnlicher Seiten (Search Console-Hilfe). Wer das im Kopf behält, liest jede Zeile der Übersichtstabelle richtig: Sie steht für eine Kombination aus Status und Problem, etwa ein LCP-Problem auf Mobilgeräten, und nennt, wie viele URLs gerade in diese Kombination fallen.
Entscheidend ist die Regel für den Gruppenstatus. Einer URL-Gruppe wird je Gerätetyp jeweils der schlechteste Status zugewiesen (Search Console-Hilfe). Hat eine Gruppe auf Mobilgeräten einen langsamen CLS und einen LCP mit „Optimierung erforderlich“, gilt sie mobil als „Langsam“. Eine Gruppe mit guten LCP- und INP-Werten kann also allein an Layoutsprüngen scheitern. Damit eine Gruppe überhaupt im Bericht erscheint, braucht sie ausreichend Daten für LCP und für CLS; liegen nur für einen der beiden Messwerte genug Daten vor, wird sie nicht angezeigt (Search Console-Hilfe).
| Messwert | Gut | Optimierung erforderlich | Langsam |
|---|---|---|---|
| LCP (Laden) | bis 2,5 s | bis 4 s | über 4 s |
| INP (Reaktion) | bis 200 ms | bis 500 ms | über 500 ms |
| CLS (Stabilität) | bis 0,1 | bis 0,25 | über 0,25 |
Neben dem Status zeigt die Detailseite je Gruppe einen Gruppenwert, etwa „Group LCP“. Er ist kein Mittelwert. Er besagt, dass bei 75 Prozent (Search Console-Hilfe) der Seitenanfragen in den letzten 28 Tagen höchstens dieser Wert erreicht wurde. Das 75. Perzentil ist die übliche Messlatte: web.dev empfiehlt, die Grenzwerte am 75. Perzentil (web.dev) der Seitenaufrufe zu messen, getrennt nach Mobilgeräten und Desktop. Ein Viertel der Besuche darf also schlechter liegen, ohne dass die Gruppe ihren Status verliert. Umgekehrt genügt es nicht, wenn die Hälfte der Besuche schnell ist: Liegt der Gruppen-LCP knapp über 2,5 Sekunden, müssen so viele der langsameren Aufrufe unter die Grenze rutschen, dass höchstens ein Viertel darüber bleibt. Den typischen Besuch weiter zu beschleunigen, reicht dafür nicht.
Eine häufige Verwirrung betrifft die Summen. Im Diagramm wird jede URL nur einmal gezählt, und zwar unter ihrem langsamsten Problem; in der Tabelle erscheint sie in jeder Zeile, deren Problem sie hat (Search Console-Hilfe). Die Zeilensummen liegen deshalb höher als die Zahl im Diagramm. Zudem zeigen die Reiter über dem Diagramm die Zahl der URLs, nicht die Zahl der URL-Gruppen (Search Console-Hilfe). Viele langsame URLs können also eine einzige Gruppe sein – und damit ein einziges Problem.
FID ist Geschichte
Beispiel-URL gegen Vorlage
Klickt man in der Übersicht eine Zeile an, öffnet sich die Detailseite mit einer Tabelle von Beispiel-URLs. Jede Zeile dieser Tabelle steht für eine Gruppe ähnlicher URLs (Search Console-Hilfe), und die Tabelle fasst höchstens 200 Zeilen (Search Console-Hilfe). Genau hier entsteht der teuerste Lesefehler: Die Beispiel-URL wird für die kranke Seite gehalten. Ein Entwickler verkleinert das Bild auf genau dieser Produktseite, testet sie in PageSpeed Insights, sieht eine Verbesserung – und die Gruppe bleibt rot, weil die übrigen Produktseiten dieselbe Schwäche haben.
Es wird angenommen, dass diese Gruppen ein gemeinsames Framework haben und die Gründe für eine schlechte Leistung der Gruppe deshalb wahrscheinlich gleich sind.
Übersetzt heißt das: Hinter einer URL-Gruppe steht in der Regel eine Vorlage. In einem Shop sind das Kategorieseite, Produktseite, Suchergebnis, Warenkorb und Ratgeber; auf einer Unternehmenswebsite Leistungsseite, Standortseite und Blogbeitrag. Ein großes Kopfbild, das die Vorlage ohne Vorrang lädt, ein nachgeladener Bewertungsblock ohne reservierte Höhe oder ein schweres Filterskript wirken auf jede Seite, die mit dieser Vorlage gebaut ist. Die Korrektur gehört deshalb in die Vorlage, in das gemeinsame CSS oder in das Skript, das alle Seiten der Gruppe laden – das ist der Kern jeder Frontend-Optimierung, die im Bericht sichtbar werden soll.
Welche Seiten in eine Gruppe fallen, zeigt ein Klick auf die Beispiel-URL: Die Search Console blendet weitere Seiten der Gruppe ein, samt den Werten der Gruppenmitglieder, sofern für sie genug Daten vorliegen (Search Console-Hilfe). Die Mitglieder sind absteigend nach Impressionen sortiert. Die zuerst aufgeführten URLs haben deshalb den größten Einfluss auf den Gruppenstatus. Liegt eine Gruppe knapp an einer Grenze, können aber auch wenige URLs am unteren Ende der Liste den Ausschlag geben (Search Console-Hilfe).
- Mehrere Mitglieder der Gruppe öffnen und notieren, mit welcher Vorlage sie im System gebaut sind.
- Prüfen, ob alle Mitglieder dieselbe Vorlage nutzen. Mischt eine Gruppe zwei Vorlagen, etwa Produktseiten mit und ohne Variantenauswahl, gehören beide in die Untersuchung.
- Eine typische Seite je Vorlage im Labor untersuchen, mit gedrosseltem Netz und gedrosseltem Prozessor, und die Ursache für den schwachen Messwert suchen – etwa in einem Lighthouse-Audit.
- Die Korrektur in der Vorlage umsetzen und an mehreren Mitgliedern der Gruppe gegenprüfen, nicht nur an der Beispiel-URL.
Ein Wort zu PageSpeed Insights: Das Werkzeug zeigt Felddaten normalerweise für die einzelne URL. Diese Zahl kann vom Gruppenergebnis abweichen, weil einzelne URLs in ihrer Gruppe Ausreißer sein können (Search Console-Hilfe). Hat die einzelne Seite zu wenig Daten, fällt PageSpeed Insights auf den Ursprung zurück, also auf alle Besuche auf allen Seiten der Website (PageSpeed-Insights-Dokumentation). Wer für eine Beispiel-URL eine gute Zahl sieht und die Gruppe trotzdem rot findet, misst deshalb nicht falsch, sondern etwas anderes.
Bei kleineren Websites taucht oft eine besondere Zeile auf: die Ursprungsgruppe. Reichen die Daten für eine URL-Gruppe nicht, bildet die Search Console eine übergeordnete Gruppe aus allen URLs mit demselben Protokoll, Host und Port, etwa https://www.example.com (Search Console-Hilfe). http und https gelten dabei als getrennte Ursprünge. Eine solche Zeile sagt: Über alle Vorlagen hinweg reicht es nicht. Dann führt der Weg über die meistbesuchten Vorlagen, eine nach der anderen. Bei Shops auf Shopware-Basis liegen diese Vorlagen meist im Theme; wie wir dort ansetzen, beschreibt die Seite Shopware-Performance.
Mobilgeräte und Desktop getrennt lesen
Die Übersichtsseite zeigt zwei Diagramme, eines für Mobilgeräte und eines für Computer. Status und Probleme werden je Gerätetyp vergeben (Search Console-Hilfe): Dieselbe Gruppe kann auf Mobilgeräten „Gut“ sein und am Desktop „Optimierung erforderlich“ – oder umgekehrt. Auch die Empfehlung von web.dev trennt beim 75. Perzentil ausdrücklich nach Mobilgeräten und Desktop (web.dev). Ein Mittelwert über beide Gerätetypen würde die schwächere Seite verdecken.
Im Netz schneidet die mobile Fassung bei den meisten Messwerten schwächer ab. 2025 bestanden 48 Prozent (Web Almanac 2025) der im Chrome UX Report mobil erfassten Websites alle drei Core Web Vitals, am Desktop waren es 56 Prozent (Web Almanac 2025). Beim LCP erreichen 62 Prozent der mobilen Seiten einen guten Wert gegenüber 74 Prozent am Desktop (Web Almanac 2025). Am größten ist der Abstand bei der Reaktionszeit: 77 Prozent (Web Almanac 2025) der Websites erreichen mobil einen guten INP, am Desktop sind es 97 Prozent (Web Almanac 2025).
Für die Arbeit heißt das: Der mobile Bericht ist in den meisten Fällen der strengere und der, der zuerst bearbeitet wird. Er bildet allerdings nur Chrome-Nutzer ab, denn Chrome unter iOS liefert keine Daten an CrUX (Chrome for Developers). Ein Shop mit vielen iPhone-Kunden sieht im Bericht also nur einen Teil seiner mobilen Kundschaft. Wer wissen will, wie es den übrigen Besuchern geht, braucht eigene Messungen bei echten Besuchern, die alle Browser erfassen.
Der Desktop-Bericht verdient trotzdem Aufmerksamkeit, vor allem beim Layout. 2025 erreichten 72 Prozent der Desktop-Seiten einen guten CLS, mobil waren es 81 Prozent (Web Almanac 2025). Breite Layouts mit Seitenleisten, nachgeladenen Bannern und Werbeflächen bieten mehr Gelegenheit für Verschiebungen als eine schmale Spalte. Steht der Desktop-Bericht beim CLS schlechter da als der mobile, lohnt der Blick in den Beitrag CLS im Shop vermeiden.
„Keine Daten“ und zu wenig Daten
Nicht jede Website bekommt einen vollständigen Bericht. Zeigt die Search Console „Keine Daten verfügbar“, gibt es dafür zwei Gründe: Entweder ist die Property neu, oder im CrUX-Bericht liegen für den Gerätetyp nicht genug Daten vor (Search Console-Hilfe). Bei einer neuen Property kann es einige Tage dauern, bis vorhandene CrUX-Daten ausgewertet und angezeigt werden; gesammelt werden die Daten unabhängig davon, ob es eine Property gibt.
Der zweite Grund ist häufiger, als viele denken. CrUX nimmt eine Seite oder einen Ursprung nur auf, wenn eine Mindestzahl an Besuchern erreicht ist; die genaue Zahl veröffentlicht Google nicht (Chrome for Developers). Auch URL-Gruppen müssen aus Datenschutzgründen eine Mindestmenge an Daten enthalten, um im Bericht zu erscheinen (Search Console-Hilfe). Bei kleineren Websites kann sich daraus ein lückenhaftes Bild ergeben: Am Desktop fehlt der Bericht ganz, mobil erscheint nur die Ursprungsgruppe, und einzelne Vorlagen bleiben unsichtbar.
„Zu wenig Daten“ heißt nicht „kein Problem“. Es heißt nur, dass der Bericht dazu nichts sagen kann. Drei Wege helfen weiter:
- PageSpeed Insights für den Ursprung: Fehlen Daten für eine einzelne Seite, zeigt das Werkzeug die Werte des gesamten Ursprungs, sofern dieser genug Daten hat (PageSpeed-Insights-Dokumentation).
- Eigene Felddaten: Eine schlanke Messung bei echten Besuchern liefert Werte je Vorlage und erfasst auch Safari und Firefox. Wie sich das datensparsam aufsetzen lässt, zeigt der Beitrag Performance-Messung ohne Einwilligung.
- Labor je Vorlage: Ein gedrosselter Testlauf je Vorlage ersetzt keine Felddaten, zeigt aber, wo die Ursachen liegen und welche Vorlage zuerst Aufmerksamkeit braucht.
Für die Auswertung wichtig: Fehlen nur für den INP genug Daten, bleibt eine Gruppe trotzdem im Bericht, solange LCP und CLS ausreichen. PageSpeed Insights bewertet in diesem Fall nur LCP und CLS; fehlen Daten für LCP oder CLS, ist keine Bewertung möglich (PageSpeed-Insights-Dokumentation). Eine grüne Gruppe ohne INP-Wert ist deshalb bei der Reaktionszeit ungeprüft – gerade bei Seiten mit Filtern, Konfiguratoren und Formularen.
Validierung: warum „Tracking starten“ vier Wochen dauert
Ist ein Problem behoben, bietet die Detailseite die Schaltfläche „Tracking starten“. Ab dann beobachtet die Search Console 28 Tage (Search Console-Hilfe) lang, ob das Problem noch irgendwo auf der Website auftritt. Tritt es in dieser Zeit bei keiner URL mehr auf, gilt es als behoben; tritt es auch nur bei einer einzigen URL auf, gilt es als nicht behoben (Search Console-Hilfe). Den Status der einzelnen URLs wertet die Search Console dabei über die gesamte Frist aus.
Die Schaltfläche löst keine Neuindexierung und keine sonstige Aktion bei Google aus. Sie startet lediglich eine Überwachung der CrUX-Daten über vier Wochen (Search Console-Hilfe). Das passt zur Art der Daten: Die Felddaten in PageSpeed Insights und der CrUX-Datensatz bilden jeweils einen gleitenden Zeitraum von 28 Tagen (PageSpeed-Insights-Dokumentation) ab. Ein Wert, der heute verbessert wird, mischt sich Tag für Tag mit den alten, langsamen Besuchen. Erst wenn diese aus dem Zeitfenster gefallen sind, zeigt der Gruppenwert den neuen Stand vollständig.
- Gestartet: Die Überprüfung läuft, und es wurden keine verbleibenden Fälle des Problems gefunden.
- Bisher alles in Ordnung: Alle bisher geprüften Fälle sind behoben, die Frist läuft noch.
- Bestanden: Alle URLs haben den Status „Bestanden“; erreicht wird er nur über eine gestartete Überprüfung.
- Fehlgeschlagen: Eine oder mehrere URLs sind nach der Überprüfung weiter betroffen.
- Nicht zutreffend: Das Problem ist bei allen URLs verschwunden, ohne dass eine Überprüfung gestartet wurde (Search Console-Hilfe).
Nicht zu früh starten
Manchmal ändert sich der Status ganz ohne eigenes Zutun. Die Hilfe nennt als Ursache Seiten, die knapp an einer Grenze lagen und durch ein websiteübergreifendes Ereignis darüber gerutscht sind: stark gestiegene Zugriffe oder eine veränderte Latenz des Dienstes, über den die Bilder ausgeliefert werden (Search Console-Hilfe). Wie sich Bilder schlanker ausliefern lassen, zeigt die Seite Bildoptimierung. Als weniger wahrscheinliche Ursache nennt die Hilfe eine flächendeckend aktualisierte Browserversion oder mehr Besucher mit langsamer Verbindung. Wer im Bericht Gruppenwerte dicht an 2,5 Sekunden oder 0,1 sieht, plant deshalb Abstand zur Grenze ein, statt sie gerade so zu erreichen.
Aus dem Bericht einen Arbeitsauftrag machen
Der Bericht beantwortet, wo Besucher warten. Er sagt nicht, warum. Damit aus roten Balken eine erledigte Aufgabe wird, braucht es eine Übersetzung in Vorlagen, Ursachen und Reihenfolge. Die Reihenfolge gibt Google vor: zuerst alle Probleme mit dem Status „Langsam“ beheben, danach nach Problemen priorisieren, die die meisten oder die wichtigsten URLs betreffen; „Optimierung erforderlich“ ist weniger dringend (Search Console-Hilfe).
- Exportieren: Der Export enthält Diagramm- und Tabellendaten. Werte, die im Bericht als „~“ (nicht verfügbar) oder „-“ (keine Zahl) erscheinen, stehen in der Datei als Null (Search Console-Hilfe). Eine Null im Export ist also ein fehlender Wert, kein perfekter.
- Gruppen den Vorlagen zuordnen: Je Zeile die Vorlage notieren, die hinter der Beispiel-URL steht, und Mobilgeräte und Desktop getrennt führen.
- Priorisieren: erst „Langsam“, dann nach Zahl und Bedeutung der betroffenen URLs. Eine Kategorie-Vorlage mit vielen Einstiegen wiegt schwerer als ein selten besuchter Ratgeber.
- Ursache im Labor finden: je Vorlage ein Testlauf oder eine Aufzeichnung im Browser. Wie man die Befunde eines Laborlaufs gewichtet, zeigt der Beitrag Lighthouse-Report lesen.
- Korrektur in der Vorlage umsetzen, ausliefern und an mehreren Gruppenmitgliedern gegenprüfen.
- Eigene Felddaten beobachten, bis die Wirkung bestätigt ist, und erst dann „Tracking starten“.
- Ergebnis festhalten: Datum der Auslieferung, betroffene Vorlage, erwarteter Messwert und Beginn der Überprüfung.
| Zeile im Bericht | Häufige Ursache in der Vorlage | Erste Prüfung |
|---|---|---|
| LCP über 4 s (mobil) | großes Bild ohne Vorrang, späte Serverantwort, blockierendes CSS | LCP-Element und seine vier Ladephasen im Labor bestimmen |
| INP über 500 ms | schwere Event-Handler, Filter- oder Variantenskripte, Code von Drittanbietern | Interaktion aufzeichnen und lange Aufgaben suchen |
| CLS über 0,25 | nachgeladene Banner, Bilder ohne Abmessungen, Schriftwechsel | Layoutverschiebungen im Browser sichtbar machen |
Für den LCP lohnt die Zerlegung in seine Teilphasen, beschrieben im Beitrag LCP-Subparts analysieren; liegt die Ursache in der Serverantwort, gehört sie in die Server-Optimierung. Für Nicht-Techniker nennt die Hilfe zusätzlich Faustregeln: weniger als 500 KB (Search Console-Hilfe) für eine Seite samt aller zugehörigen Ressourcen und höchstens 50 Ressourcen (Search Console-Hilfe) für Seiten auf Mobilgeräten. Sie taugen als Gesprächsanlass, ersetzen aber keine Ursachensuche je Vorlage – ein leichtes Seitengewicht hilft wenig, wenn ein einzelnes Skript die Reaktion auf jeden Klick bremst.
Die Leseregel in einem Satz
Was ein richtig gelesener Bericht spart
Der Core-Web-Vitals-Bericht ist kein Zeugnis für einzelne Seiten, sondern eine Landkarte der Vorlagen. Wer ihn so liest, arbeitet an wenigen Stellen mit großer Wirkung: an der Vorlage, die hinter vielen Adressen steht, am Gerätetyp mit dem schwächeren Wert und am Messwert, der den Gruppenstatus nach unten zieht. Wer ihn als Seitenliste liest, poliert Beispiel-URLs und wartet vier Wochen auf ein Ergebnis, das so nicht kommen kann.
In einer Performance-Analyse lesen wir den Bericht gemeinsam mit Ihnen aus, ordnen jede Gruppe ihrer Vorlage zu und messen die Ursachen im Labor und bei echten Besuchern. Die Umsetzung folgt dort, wo sie für alle Seiten einer Gruppe wirkt, und die Überprüfung in der Search Console starten wir erst, wenn die eigenen Messungen den Erfolg zeigen. Einen Überblick über alle Bausteine finden Sie unter Leistungen.
Quellen
Verwandte Artikel
RUM vs. CrUX: Felddaten richtig für Tempo nutzen
Lighthouse-Laborwerte beeinflussen kein Ranking. Google bewertet Core Web Vitals über CrUX-Felddaten am 75. Perzentil. So nutzen Sie RUM, CrUX und Budgets.
Was kostet PageSpeed-Optimierung? Aufwand ehrlich planen
Was PageSpeed-Optimierung kostet, entscheiden Vorlagen, Shopsystem, Skripte, Server und Bilder. So planen Sie Analyse, Festpreis, Überwachung und Budget 2027.
Aktionsbanner zur Black Week ohne Layoutsprung einbauen
Hinweisleiste, Countdown, Pop-up und Badges zur Black Week ohne Sprung einbauen: Platz reservieren, serverseitig ausliefern, CLS bei höchstens 0,1 halten.