Core Web Vitals: Warum Geschwindigkeit zu SEO geworden ist

Der leise Wandel von 2021

Im Mai 2021 hat Google die Core Web Vitals offiziell in seinen Ranking-Algorithmus aufgenommen. In den 18 Monaten davor hatte die Suchmaschine schrittweise darüber informiert, damit sich Entwicklerinnen und Entwickler vorbereiten konnten. Viele haben es nicht ernst genommen. Fünf Jahre später ist der Ranking-Unterschied zwischen den Websites, die optimiert haben, und denen, die es nicht getan haben, gewaltig.

Die Core Web Vitals sind kein technisches Detail. Bei umkämpften Suchanfragen sind sie zu einem Auswahlkriterium geworden, das ebenso viel wiegt wie die Relevanz des Inhalts. Bei Keywords mit starker Kaufabsicht («SEO Agentur Genf», «Website erstellen Schweiz») rankt eine Website mit Lighthouse 70 nicht, selbst wenn ihr Inhalt objektiv besser ist als der der Website mit Lighthouse 95 auf Platz eins.

Dieser Artikel erklärt, was die Core Web Vitals wirklich messen, warum Google ihnen so viel Gewicht gibt und wie Sie die Werte 2026 einhalten.

Die drei Metriken, die zählen

Google veröffentlicht über Lighthouse rund ein Dutzend Performance-Metriken. Nur drei davon gehören 2026 zu den offiziellen Core Web Vitals.

Largest Contentful Paint (LCP) misst die Ladezeit des grössten sichtbaren Elements auf dem Bildschirm bei der ersten Anzeige. Meist ist das ein Hero-Bild, ein H1-Titel oder ein Video. Googles Zielwert: weniger als 2,5 Sekunden. Über 4 Sekunden gilt das Erlebnis als schlecht.

Interaction to Next Paint (INP) hat 2024 den früheren First Input Delay (FID) abgelöst. INP misst die Zeit zwischen der Interaktion des Nutzers (Klick, Tippen, Tastatureingabe) und dem Moment, in dem die Seite sichtbar reagiert. Zielwert: weniger als 200 ms. Über 500 ms: schlecht.

Cumulative Layout Shift (CLS) misst die visuellen Verschiebungen des Layouts während des Ladens. Sie alle kennen das: Sie wollen gerade auf einen Button klicken, oben lädt ein Werbebanner, der Button rutscht weg, und Sie klicken auf etwas anderes. Zielwert: ein Score unter 0,1.

Zusammen messen diese drei Metriken eine Sache: die tatsächliche Qualität des Nutzererlebnisses beim Laden und bei der Interaktion. Keinen abstrakten Score, keinen Marketing-Durchschnitt. Die echte Wartezeit.

Warum Google diesen Metriken so viel Gewicht gibt

Drei strukturelle Gründe, nach Bedeutung geordnet.

Mobile hat den Desktop verdrängt. 2026 kommen 65 % der Google-Suchen von Smartphones. Auf dem Smartphone wirkt sich jede Verzögerung massiv auf das Nutzererlebnis aus: schwankende 4G- oder 5G-Verbindung, schwächerer Prozessor, kurze Aufmerksamkeit. Google kann es sich nicht leisten, langsame Ergebnisse auf Platz 1 zu setzen, sonst nutzen die Leute Google weniger.

Die Konkurrenz durch soziale Netzwerke und KI. Wer eine Information sucht, hat die Wahl zwischen Google, TikTok (45 % der unter 30-Jährigen), ChatGPT und anderen LLMs mit Websuche. Google hat kein Monopol mehr. Wird das Erlebnis frustrierend, wandern die Nutzer ab. Langsame Websites auf Platz 1 zu setzen, verschlechtert das eigene Produkt.

Die Messung ist präzise und anonym geworden. Seit dem Chrome User Experience Report (CrUX) misst Google die echten Ladezeiten auf Dutzenden Millionen realer Sitzungen, ohne individuelles Cookie. Diese Daten fliessen laufend in den Algorithmus ein. Eine Website, deren Core Web Vitals sich verschlechtern, verliert in den folgenden Wochen Traffic.

Was den LCP verschlechtert

Der LCP ist die Metrik, die am stärksten vom technischen Stack der Website abhängt. Fünf Hauptursachen.

Zu schwere oder nicht optimierte Bilder. Ein Hero-Bild von 2 MB auf dem Smartphone bedeutet mindestens 2 Sekunden Ladezeit bei durchschnittlichem 4G. Die Lösung: Komprimierung in WebP oder AVIF (moderne Formate, 30 bis 50 % leichter als JPEG), responsive Bilder mit einem auf jeden Viewport abgestimmten srcset und Lazy Loading für alles unterhalb des sichtbaren Bereichs.

Blockierende Webfonts. Eine synchron geladene eigene Schrift blockiert das Rendering, bis sie da ist. Die Lösung: font-display: swap, um sofort eine Ersatzschrift anzuzeigen, oder die Schriften lokal ausliefern, um die Latenz eines Drittanbieters zu vermeiden.

Render-blockierendes CSS und JavaScript. Jede Datei im <head> ohne async oder defer blockiert das Rendering. Die Lösung: das kritische CSS inline ins HTML übernehmen, den Rest nicht blockierend laden, JavaScript-Bundles in logische Chunks aufteilen.

Hohe Antwortzeit. Ein Server, der in 500 ms antwortet (hohe TTFB), verlängert den LCP zwangsläufig um 500 ms. Die Lösung: HTTP/2 oder HTTP/3, Brotli-Komprimierung.

Ungeeigneter technischer Stack. WordPress mit 30 Plugins oder eine React-SPA, die eine redaktionelle Seite im Browser hydratisiert, belasten den LCP unweigerlich. Die Lösung: einen modernen Stack wählen, der zum Seitentyp passt (Astro für Redaktionelles, Next.js für Interaktives, Remix für Transaktionales).

Was den INP verschlechtert

Der INP hängt davon ab, wie viel JavaScript läuft, wenn der Nutzer mit der Seite interagiert.

Überdimensioniertes JavaScript. Viele Websites laden 500 KB JavaScript für eine Seite, die mit 50 KB auskäme. Jedes zusätzliche KB muss heruntergeladen, geparst, kompiliert und ausgeführt werden. Auf einem Mittelklasse-Smartphone ist das verheerend.

Blockierende Long Tasks. Eine JavaScript-Funktion, die länger als 50 ms läuft, blockiert den Main Thread. Klickt der Nutzer währenddessen, verzögert sich die Interaktion. Die Lösung: Long Tasks aufteilen (setTimeout, requestIdleCallback, Web Workers für rechenintensive Aufgaben).

Falsch eingesetzte SPA-Frameworks. React, Vue und Svelte sind ausgezeichnet für Anwendungen. Für eine Firmenwebsite sind sie überdimensioniert. Wenn Sie React für eine Seite «Über uns» einsetzen, bezahlen Sie 200 KB JavaScript für nichts.

Was den CLS verschlechtert

Der CLS ist die am wenigsten technische der drei Metriken, für den Nutzer aber die sichtbarste.

Bilder ohne angegebene Abmessungen. Ein <img> ohne definierte Breite und Höhe verursacht beim Laden eine Verschiebung. Die Lösung: die Abmessungen systematisch angeben, entweder als HTML-Attribute oder per CSS aspect-ratio.

Webfonts, die das Layout verändern. Der Wechsel von der Ersatzschrift zur eigenen Schrift kann den ganzen Text verschieben. Die Lösung: eine Ersatzschrift mit ähnlichen Metriken wählen oder size-adjust in @font-face verwenden, um die Abmessungen festzulegen.

Per JavaScript nach dem ersten Rendering eingefügte Inhalte. Cookie-Banner, Pop-ups, Chat-Widgets. Die Lösung: den Platz mit einem Platzhalter in der richtigen Grösse reservieren oder das Einfügen auf den idealen Moment verschieben (Interaktion des Nutzers).

Werbung und eingebettete Inhalte von Drittanbietern. YouTube-iframes, Twitter-Widgets, Werbebanner. Die Lösung: Platz reservieren mit aspect-ratio oder einer festen Mindesthöhe.

So testen Sie Ihre Website

Drei Werkzeuge, die Sie kennen sollten.

PageSpeed Insights (https://pagespeed.web.dev) liefert den Lighthouse-Wert für Mobile und Desktop mit detaillierten Empfehlungen. Es ist das offizielle Werkzeug von Google. Eine Momentaufnahme, keine Verlaufsmessung.

Search Console (Bericht Core Web Vitals) liefert die realen Daten Ihrer Website, aggregiert über 28 Tage und nach URL-Gruppen. Genau das verwendet Google tatsächlich für Ihr Ranking. Laufend im Auge behalten.

WebPageTest (https://webpagetest.org) liefert eine detaillierte Analyse des Lade-Wasserfalls. Ausgezeichnet, um konkrete Engpässe zu finden.

Zielwerte 2026: mobiler Lighthouse-Wert über 90 in PageSpeed Insights und 75 % der URLs als «gut» im Core-Web-Vitals-Bericht der Search Console. Darunter ist Ihre Website bei umkämpften Suchanfragen im Nachteil.

Was wir bei Voren tun

Alle Voren-Websites werden mit den Core Web Vitals als architektonischer Vorgabe konzipiert, nicht als Kontrolle am Projektende.

Ein Stack, der zum Seitentyp passt. Astro für Redaktions- und Firmenwebsites (statisches HTML mit partieller Hydration), Next.js für Websites mit viel Interaktivität, Remix für transaktionale Anwendungen. Wir liefern nie eine SPA für eine Website, die keine braucht.

Standardmässig optimierte Bilder. Automatische Komprimierung in WebP oder AVIF, responsive Bilder mit srcset, Lazy Loading unterhalb des sichtbaren Bereichs.

Lokal ausgelieferte Schriften mit font-display: swap. Keine synchron geladenen Google Fonts, weder FOIT (Flash of Invisible Text) noch sichtbarer FOUT.

Kritisches CSS inline. Das CSS der ersten Ansicht steht im <head>, der Rest wird nicht blockierend geladen.

Lighthouse über 95 als Ziel bei den Paketen Premium und Individuell, über 90 bei Essential, gemessen beim Go-live.

Der eigentliche Grund für den Unterschied

Viele Agenturen behandeln die Core Web Vitals als Optimierung am Projektende: Man entwickelt die Website, geht online, schaut sich Lighthouse an und flickt nach. Das funktioniert teilweise, lässt aber immer 10 bis 20 Punkte liegen.

Der Unterschied entsteht in der Konzeption. Wer zu Projektbeginn Astro statt WordPress wählt, gewinnt 30 Lighthouse-Punkte ohne jeden Optimierungsaufwand. Wer komprimierte WebP-Bilder statt PNG wählt, gewinnt 10 Punkte.

Werden diese Entscheidungen zu Projektbeginn getroffen, geht Ihre Website mit Lighthouse 95 in Produktion, ohne mühsame Optimierung. Werden sie es nicht, verbringen Sie danach Wochen mit nachträglicher Optimierung, bei geringem Ertrag.

Weiterführend

Wenn Ihre Website mobil einen Lighthouse-Wert unter 75 hat, ist das wahrscheinlich die Hauptursache für Ihren SEO-Stillstand. Bevor Sie in Inhalte oder Backlinks investieren, muss die technische Basis stimmen.

Ein kostenloses SEO-Audit anfordern: Wir prüfen Ihren Lighthouse-Wert, Ihre Core Web Vitals und Ihren Stack und sagen Ihnen innerhalb von 7 Tagen, was Vorrang hat.

Unsere Pakete für die Website-Erstellung entdecken: Alle unsere Websites werden mit einem beim Go-live gemessenen Lighthouse-Wert ausgeliefert (über 90 bis über 95, je nach Paket).