Website-Geschwindigkeit und Core Web Vitals

Die Geschwindigkeit einer Website beeinflusst sowohl das Crawl-Budget, das Bots ihr widmen, als auch die tatsächliche Erfahrung der Besucher: Eine langsame Website wird seltener und weniger tiefgehend gecrawlt und verliert Besucher, noch bevor diese den Inhalt überhaupt gelesen haben. Die Core Web Vitals sind das Standardwerkzeug, um diese Geschwindigkeit vergleichbar über verschiedene Websites hinweg zu messen.

Warum Geschwindigkeit Crawl-Budget und Nutzererfahrung beeinflusst

Das Crawl-Budget bezeichnet die Anzahl an Seiten, die ein Bot bereit ist, in einem bestimmten Zeitraum auf Ihrer Website zu erkunden. Dieses Budget ist nicht unbegrenzt: Es hängt teilweise davon ab, wie schnell Ihr Server antworten kann. Es lässt sich generell beobachten, dass eine langsame oder instabile Website Bots dazu veranlasst, ihre Besuchsfrequenz und die Anzahl der pro Besuch gecrawlten Seiten zu reduzieren, was die Entdeckung neuer Inhalte und deren Aktualisierung im Index automatisch verlangsamt.

Auf Nutzerseite ist der Effekt direkter: Eine lange Ladezeit erhöht die Abbruchrate, noch bevor der Inhalt überhaupt angezeigt wird. Für ein GEO-Ziel zählt das doppelt: Eine langsame Seite hat geringere Chancen, von einem KI-Crawler erfasst zu werden, und geringere Chancen, von einem Nutzer, der über eine generierte Antwort geklickt hat, bis zum Ende gelesen zu werden.

Die drei Core-Web-Vitals-Metriken erklärt

Google hat drei Metriken definiert, die zusammen die Core Web Vitals bilden:

• LCP (Largest Contentful Paint): die Zeit, die benötigt wird, um das größte sichtbare Element auf dem Bildschirm anzuzeigen (oft ein Hauptbild oder eine Überschrift). Allgemein empfohlener Zielwert: unter 2,5 Sekunden.
• INP (Interaction to Next Paint): die Verzögerung zwischen einer Nutzerinteraktion (Klick, Tastendruck) und der entsprechenden visuellen Aktualisierung. Diese Metrik hat 2024 den FID (First Input Delay) ersetzt. Allgemein empfohlener Zielwert: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift): die Messung unerwarteter visueller Verschiebungen während des Ladens (etwa ein Button, der sich verschiebt, kurz bevor Sie darauf klicken). Allgemein empfohlener Zielwert: unter 0,1.

Diese Schwellenwerte sind von Google kommunizierte Orientierungswerte, keine absoluten Regeln, die überall gelten: Eine Website mit vielen komplexen interaktiven Inhalten kann je nach Anwendungsfall leicht abweichende Spielräume vertragen.

Messen mit PageSpeed Insights (und warum nicht nur damit)

pagespeed.web.dev ist das Referenztool, um eine bestimmte Seite zu testen. Es liefert zwei Arten von Daten, die Sie nicht verwechseln sollten:

• Felddaten (Field Data) aus dem Chrome User Experience Report, die die tatsächliche Erfahrung Ihrer Besucher der letzten 28 Tage widerspiegeln – nur verfügbar, wenn Ihre Website ausreichend Chrome-Traffic erhält.
• Labordaten (Lab Data), die bei einem simulierten Test im Moment der Analyse erzeugt werden – nützlich für die Diagnose, können aber von Test zu Test je nach simulierten Netzwerkbedingungen variieren.

Der Core-Web-Vitals-Bericht der Google Search Console, der in einer früheren Lektion behandelt wurde, ergänzt dieses Tool durch eine aggregierte Sicht auf die gesamte Website statt Seite für Seite, was hilft, nach Vorlage statt nach einzelner URL zu priorisieren.

Mobil und Desktop: zwei unterschiedliche Realitäten

Die Core Web Vitals werden für Mobilgeräte und Desktop getrennt bewertet, und die Ergebnisse weichen oft deutlich voneinander ab. Da der Großteil des Web-Traffics heute über Mobilgeräte erfolgt und Google die „Mobile-first"-Indexierung verwendet (die mobile Version Ihrer Seite dient als Referenz für Crawling und Bewertung), empfiehlt es sich, im Zweifelsfall die mobilen Ergebnisse als vorrangig zu behandeln. Eine Website, die auf dem Desktop gute Werte erzielt, aber auf Mobilgeräten schlecht abschneidet, bleibt aus Sicht von Google eine Website mit einem zu behebenden Geschwindigkeitsproblem.

Die häufigsten Korrekturen und ihre Priorität

In den meisten Audits stammen die schnellsten Verbesserungen aus:

1. Komprimierung und Größenanpassung von Bildern: Bilder in der tatsächlich angezeigten Größe ausliefern, in einem modernen Format (WebP oder AVIF), mit verzögertem Laden (lazy loading) für Bilder außerhalb des sichtbaren Bereichs.
2. Reduzierung blockierenden JavaScripts: das Laden von Skripten verzögern, die für das anfängliche Rendering nicht essenziell sind (Live-Chat, Drittanbieter-Widgets, sekundäre Werbe-Pixel).
3. Platzreservierung für dynamische Elemente: explizite Abmessungen für Bilder, Videos und Anzeigen vor deren Laden festlegen, um Layout-Verschiebungen (CLS) zu vermeiden.
4. Caching und CDN: ein Content Delivery Network nutzen, um statische Dateien näher an die Besucher zu bringen, und ein passendes Browser-Caching konfigurieren.
5. Wahl des Hostings: günstiges Shared Hosting bleibt oft der limitierende Faktor, der sich am schwersten beheben lässt, ohne die technische Lösung zu wechseln.

Den Einfluss über die Zeit verfolgen

Prüfen Sie nach jeder wesentlichen Korrektur erneut mit PageSpeed Insights und beobachten Sie den Core-Web-Vitals-Bericht der Search Console in den folgenden Wochen statt in der folgenden Stunde: Felddaten basieren auf einem gleitenden 28-Tage-Fenster und reagieren nicht sofort auf eine Änderung.

Ist die Geschwindigkeit unter Kontrolle, ist das technische Fundament der Website weitgehend gelegt. Zeit, sich der Kontrolle des Bot-Zugriffs zu widmen – mit der Lektion zur robots.txt-Datei und der Steuerung von KI-Crawlern, und anschließend im Detail zu verstehen, wie eine Suchmaschine eine Seite liest.