Zum Inhalt springen
SEO NW – Alexander Müller 18 FachportaleHotline 0800 188 7 100 rund um die UhrGratis Sprechstundewww.seo-manager.info
SEO CMSStatische Seiten, die ranken
Menü

News · Blog zum SEO CMS

Core Web Vitals: was statische Auslieferung wirklich löst

Statische Auslieferung verkürzt vor allem die Zeit, bis der Server das erste Byte schickt, und hilft damit dem Largest Contentful Paint. Layoutverschiebungen, die Reaktionszeit nach einer Eingabe und zu große Bilder hängen dagegen am Frontend. Bewertet werden die Core Web Vitals nach Felddaten echter Besuche im 75. Perzentil.

Radfahrerin um die dreißig fährt bei Sonnenaufgang schnell auf einer leeren Landstraße, Hintergrund leicht verwischt
Bild: KI-generiert

"Statische Seiten sind schnell" stimmt, aber nur für einen Teil dessen, was die Core Web Vitals messen. Eine fertige HTML-Datei verkürzt die Zeit, die der Server für seine Antwort braucht. Was danach im Browser passiert, also wie schnell das größte Element erscheint, ob sich das Layout verschiebt und wie schnell die Seite auf eine Eingabe reagiert, hängt an Bildern, Schriften und JavaScript. Dieser Beitrag trennt beides.

Die drei Messwerte und ihre Grenzen

Die Core Web Vitals bestehen aus drei Messwerten. Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element geladen ist, als gut gelten 2,5 Sekunden oder weniger. Interaction to Next Paint (INP) misst die Reaktion auf Eingaben, gut sind 200 Millisekunden oder weniger. Cumulative Layout Shift (CLS) misst, wie stark sich das Layout beim Laden verschiebt, gut ist ein Wert von 0,1 oder weniger [1]. Maßgeblich ist jeweils das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop [1]. Die einzelnen Werte erklärt das Glossar unter LCP, INP und CLS.

Was statisch gelöst wird: die Serverzeit

Ein dynamisches System fragt bei jedem Aufruf die Datenbank ab und setzt die Seite aus Vorlagen zusammen. Eine statische Website hat diese Arbeit beim Build erledigt, der Webserver liefert nur noch eine Datei aus. Das verkürzt die Time to First Byte (TTFB), also die Zeit bis zum ersten Byte der Antwort. Darin stecken Weiterleitungen, DNS-Abfrage, Verbindungsaufbau und die Wartezeit auf die Antwort [2].

Stapel fertig gepackter Pakete in einem Regal eines hellen kleinen Lagers, eine Hand greift nach dem obersten
Bild: KI-generiert

Die TTFB ist selbst kein Core-Web-Vitals-Wert. Als Richtwert nennt web.dev 0,8 Sekunden oder weniger [2]. Sie liegt aber vor dem ersten Rendern und damit auch vor dem LCP. Eine schnelle Serverantwort verschafft dem LCP also Luft, garantiert ihn aber nicht. Was die TTFB genau umfasst, steht im Glossar unter TTFB.

Noch eine Frage offen?

In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.

Was nicht gelöst wird

Layoutverschiebungen

Ob Inhalte beim Laden springen, hängt an Größenangaben für Bilder, an Platzhaltern für nachgeladene Bereiche und am Austausch der Schrift. Eine fertige HTML-Datei kann all das genauso falsch machen wie eine dynamisch erzeugte. Nach unserer Erfahrung lässt sich der CLS mit vergleichsweise wenig Aufwand verbessern: Breite und Höhe an jedes Bild, feste Flächen für nachgeladene Elemente, eine Ersatzschrift mit ähnlichen Maßen.

Reaktion auf Eingaben

Der INP hängt vor allem am JavaScript im Browser. Ein überladenes Frontend bleibt überladen, auch wenn die HTML-Datei statisch kommt. Statische Seiten haben hier eher einen indirekten Vorteil, weil sie oft mit wenig Skript auskommen. Die Bauart erzwingt das nicht.

Bilder

Ein Titelbild mit mehreren Megabyte bremst den LCP, egal woher die HTML-Datei kommt. Nach unserer Erfahrung ist das der häufigste Engpass, der nach einer Umstellung auf statische Auslieferung übrig bleibt. Wie man Bilder für den LCP vorbereitet, beschreibt der Ratgeber Bilder und Core Web Vitals auf der Hauptseite.

Labor gegen Feld

Ein guter Wert im Labortest sagt wenig, wenn die Felddaten schlecht sind. Für die Core Web Vitals zählen echte Besuche auf echten Geräten. Google verweist für die eigene Website auf den Core-Web-Vitals-Bericht in der Search Console [4]. Ein Test am Büro-PC mit schnellem Anschluss misst vor allem diesen Anschluss. Für kleine Websites liegen oft nicht genug Felddaten vor, dann bleibt der Labortest als Anhaltspunkt. Wie der Bericht zu lesen ist, erklärt die SEO FAQ zum Core-Web-Vitals-Bericht.

Frau um die zwanzig mit Smartphone, Bildschirm abgewandt, auf einem regnerischen Bahnsteig im Abendlicht
Bild: KI-generiert

Wie viel das für das Ranking bedeutet

Google schreibt, dass die Ranking-Systeme die Core Web Vitals nutzen. Gute Werte allein machen aber noch keine gute Nutzererfahrung, und die Google Suche versucht immer, die relevantesten Inhalte zu zeigen, auch wenn die Nutzerfreundlichkeit einer Seite in mancher Hinsicht unterdurchschnittlich ist [3]. Eine Seite, die die Frage schlecht beantwortet, wird durch eine schnellere Auslieferung nicht besser.

Was konkret bleibt

  • Bilder in passender Größe und mit moderner Kompression ausliefern.
  • Breite und Höhe an jedes Bild schreiben.
  • Die Hauptschrift vorladen und ohne Umweg über Drittanbieter laden.
  • JavaScript auf das beschränken, was die Seite wirklich braucht.
  • Felddaten ansehen, bevor man an Laborwerten feilt.

Das SEO CMS baut statische Seiten und lädt die Hauptschrift mit preload vor. Die Schriften liegen in der Installation selbst, eine Verbindung zu einem Schriftanbieter ist nicht nötig. Die Grundlagen des Builds beschreibt die Funktionsgruppe Statischer Build und Auslieferung, den Vergleich der Bauarten der Beitrag Statisch oder dynamisch. Soll SEO NW die Werte einer bestehenden Website verbessern, beschreibt die Hauptseite die Leistung Core Web Vitals verbessern.

Deine Felddaten sind rot, und du weißt nicht, wo du anfangen sollst? Bring die Adresse deiner Website in die gratis Sprechstunde mit. Dort sprechen wir darüber, welcher Messwert dich gerade bremst und woran das liegen kann.

  1. Organisation Web Vitals. Google, web.dev. Stand 31.10.2024. abgerufen am 31.10.2026
  2. Organisation Time to First Byte (TTFB). Google, web.dev. Stand 21.01.2025. abgerufen am 31.10.2026
  3. Organisation Nutzerfreundlichkeit der Seite in den Google-Suchergebnissen. Google Search Central. Stand 24.09.2026. abgerufen am 31.10.2026
  4. Organisation Core Web Vitals und Google-Suchergebnisse. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026

Häufige Fragen

Welche Werte gelten bei den Core Web Vitals als gut?

LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, jeweils im 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.

Ist die TTFB ein Core-Web-Vitals-Wert?

Nein. Sie liegt aber vor dem LCP, eine langsame Serverantwort verzögert ihn deshalb. web.dev nennt 0,8 Sekunden oder weniger als Richtwert.

Wie stark wirkt die Ladezeit auf das Ranking?

Google nutzt die Core Web Vitals in den Ranking-Systemen, zeigt aber immer die relevantesten Inhalte, auch wenn die Nutzerfreundlichkeit nicht in allem gut ist. Inhaltliche Schwächen gleicht eine schnelle Seite nicht aus.

Wo sehe ich meine Felddaten?

Im Core-Web-Vitals-Bericht der Search Console, sofern genug Besuche vorliegen. Für kleine Websites bleibt oft nur der Labortest als Anhaltspunkt.

Noch eine Frage offen?

In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.

Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.

Weiterlesen