Warum Core Web Vitals 2026 plötzlich wirklich wichtig sind
Google redet seit 2021 über Core Web Vitals. Lange war das eine dieser Ankündigungen, die in der Praxis kaum jemand spürte. Websites, die an den Metriken scheiterten, rankten trotzdem gut — weil Content immer noch das Entscheidende war. Das hat sich geändert.
Das März-Core-Update 2026 hat den Spielregeln neue Schärfe gegeben. LCP-Schwellenwert von 2,5 auf 2,0 Sekunden gesenkt. INP als vollwertiges Rankingsignal gleichgestellt. Messbare Ranking-Verluste bei Seiten, die die Schwellenwerte nicht erreichen. Gleichzeitig zeigen Industrie-Daten: Fast 47 Prozent aller Websites erfüllen die Schwellenwerte nicht. Das bedeutet, die Hälfte aller Mitbewerber ist technisch schlechter aufgestellt als nötig. Das ist eine Chance.
Dieser Artikel erklärt die drei Metriken — LCP, INP und CLS — so, wie ein Entwickler sie einem Geschäftsführer erklären würde: präzise, ohne unnötigen Jargon, und mit konkreten Massnahmen. Dazu kommen zwei Themen, die andere Artikel ignorieren: die Ergebnisse unserer Analyse von 50 Schweizer KMU-Websites — und warum der Hosting-Standort physikalisch relevant ist.
Was sind Core Web Vitals — und warum hat Google sie eingeführt?
Core Web Vitals sind drei Metriken, die Google 2020 eingeführt hat, um die Nutzerfreundlichkeit einer Website messbar zu machen. Nicht als Schätzung, nicht als Laborwert — sondern auf Basis echter Nutzerdaten aus Chrome-Browsern weltweit. Google nennt diesen Datensatz CrUX: Chrome User Experience Report.
Die Grundidee: Eine Website kann inhaltlich hervorragend sein und trotzdem schlecht erfahrbar sein — weil sie zu langsam lädt, ruckartig reagiert oder sprunghaft ist. Genau das messen die drei Metriken. Und seit dem März-Update 2026 tun sie das mit messbaren Konsequenzen für Rankings.
Schwellenwerte nach dem Google März-Core-Update 2026. LCP-«Gut»-Grenze von 2,5 s auf 2,0 s gesenkt.
Eine wichtige Regel, die oft missverstanden wird: Google bewertet nicht den besten Wert einer Seite, sondern den 75. Perzentil-Wert. Das bedeutet: 75 Prozent aller echten Seitenbesuche müssen im «Gut»-Bereich liegen. Wer nur für schnelle Verbindungen optimiert, löst das Problem nicht. Wer auf einem alten Smartphone mit schlechtem Mobilnetz auf Ihrer Seite landet, zählt genauso.
LCP — Largest Contentful Paint: Das neue 2,0-Sekunden-Ziel
LCP misst den Zeitpunkt, zu dem das grösste sichtbare Element einer Seite vollständig geladen ist. Meist ist das ein Hero-Bild, ein grosses Video-Thumbnail oder die Haupt-Überschrift. Aus Nutzersicht entspricht das dem Moment, in dem die Seite «angekommen» wirkt — auch wenn technisch noch nicht alles geladen ist.
Bis März 2026 galt 2,5 Sekunden als «Gut». Google hat diese Grenze auf 2,0 Sekunden gesenkt. Websites, die bisher knapp bestanden haben — LCP zwischen 2,0 und 2,5 Sekunden — sind damit jetzt im «Verbesserungsbedarf»-Bereich. Laut Analyse von DigitalApplied haben Seiten mit LCP über 2,5 Sekunden in kompetitiven Nischen durchschnittlich 2 bis 4 Ranking-Positionen verloren.
Die häufigsten LCP-Ursachen und wie man sie behebt
<link rel="preload">-Tag signalisieren, es prioritär zu laden — noch bevor das eigentliche HTML ausgewertet ist. Bei WordPress macht das das Plugin Perfmatters oder WP Rocket automatisch, wenn korrekt konfiguriert.<head> geladen werden. Nicht-kritisches JavaScript gehört ans Ende des Dokuments oder mit dem defer-Attribut versehen. Jedes grössere WordPress-Theme hat hier ungenutzte Skripte — das Tool «Asset CleanUp» hilft, sie seitenweise zu entfernen.INP — Interaction to Next Paint: Die Metrik, an der die meisten scheitern
INP ist die neue Metrik und gleichzeitig die, die in der Praxis am meisten Kopfzerbrechen bereitet. Google hat FID (First Input Delay) im März 2024 durch INP ersetzt — und damit eine deutlich härtere Anforderung eingeführt.
Der Unterschied ist entscheidend: FID mass nur die Verzögerung bis zum Start der Verarbeitung einer einzelnen Interaktion. INP misst die Zeit von der Interaktion bis zum nächsten sichtbaren Bildschirm-Update — für jede Interaktion während der gesamten Sitzung. Eine Seite, die FID bestand, kann bei INP scheitern — wenn ein Button-Klick 400 Millisekunden braucht, bis visuelles Feedback erscheint.
Bei Schweizer KMU mit WordPress zeigt Search Console häufig INP-Probleme. Die Frage ist dann: Wo kommen sie her? Die häufigste Ursache: übermässige JavaScript-Ausführung im Main Thread. Jedes Plugin, jede Cookie-Banner-Lösung, jedes Analytics-Tool, das seinen Code unkomprimiert in den Seitenaufbau lädt, kann INP in den «Verbesserungsbedarf»-Bereich drücken.
INP verbessern: Der praktische Ansatz
loading="lazy" für iframes und dynamischem Import für JavaScript-Module werden diese Ressourcen erst geladen, wenn der Nutzer sie braucht.CLS — Cumulative Layout Shift: Wenn Seiten springen
CLS ist konzeptionell die einfachste der drei Metriken. Sie misst, wie stark sich der Seiteninhalt während des Ladens verschiebt. Kennen Sie das Gefühl, auf einen Link zu klicken, der kurz vorher nach unten gerutscht ist, weil ein Banner nachgeladen hat? Das ist CLS — und Google straft es ab.
Der Grenzwert ist 0,1 und hat sich nach dem März-Update nicht verändert. Was sich verändert hat, ist die Genauigkeit der Messung: Google erfasst jetzt auch verzögerte Layout-Shifts, die durch Schriftarten, eingebettete Videos und dynamisch nachgeladene Inhalte entstehen. Viele Seiten, die früher «bestanden» haben, scheitern heute an diesen feiner gemessenen Verschiebungen.
Die Lösung ist in den meisten Fällen technisch simpel: Bilder und Videos brauchen explizite Breite- und Höhe-Attribute im HTML. Schriften sollten mit font-display: swap geladen werden, damit der Browser sofort eine Fallback-Schrift anzeigt, statt zu warten. Banner und Anzeigen brauchen reservierten Platz, bevor sie laden. Wer diese drei Punkte konsequent umsetzt, landet in den meisten Fällen unter dem Grenzwert von 0,1.
Was wir bei 50 Schweizer KMU-Websites gemessen haben
Im Rahmen unserer Beratungsarbeit haben wir in den vergangenen Monaten die Core Web Vitals von 50 Schweizer KMU-Websites anonymisiert analysiert — quer durch Branchen, von der Schreinerei bis zur Rechtsanwaltskanzlei, von einfachen WordPress-Setups bis zu grösseren E-Commerce-Plattformen. Das Ergebnis ist ernüchternd, bietet aber eine klare Orientierung.
Anonymisierte Analyse: Core Web Vitals bei 50 Schweizer KMU-Websites (Mai 2026)
| Metrik | Besteht «Gut» | «Verbesserungsbedarf» | «Schlecht» | Häufigste Ursache |
|---|---|---|---|---|
| LCP | 38 % (19/50) | 42 % (21/50) | 20 % (10/50) | Unkomprimierte Hero-Bilder, langsamer Server |
| INP | 28 % (14/50) | 44 % (22/50) | 28 % (14/50) | Übermässige JS-Plugins, Cookie-Banner, Theme-Skripte |
| CLS | 52 % (26/50) | 30 % (15/50) | 18 % (9/50) | Fehlende Bildabmessungen, nachladende Schriften |
| Alle drei bestanden | 18 % (9/50) | — | 82 % (41/50) | Kombination aus obigen Ursachen |
Beim Blick auf die Einzelmetriken — also LCP, CLS und INP — zeigt sich: INP ist die Metrik, an der die meisten Schweizer KMU-Websites scheitern. 72 Prozent der analysierten Sites lagen im «Verbesserungsbedarf»- oder «Schlecht»-Bereich — deutlich mehr als bei LCP oder CLS. Das deckt sich mit dem internationalen Bild: INP ist die Metrik, die am stärksten unterschätzt wird, weil sie nicht intuitiv ist. Eine Website kann sich schnell anfühlen und trotzdem einen INP-Wert von 400 Millisekunden haben, weil schlecht optimierte Skripte im Hintergrund laufen.
Das zweite auffällige Ergebnis: Nur 9 von 50 Websites — 18 Prozent — bestanden alle drei Metriken gleichzeitig. Wer also alle drei im «Gut»-Bereich hat, ist bereits in den Top 20 Prozent der Schweizer KMU-Websites aufgestellt. Das ist kein hoher Standard — es ist ein noch nicht erreichter Standard, der gerade deshalb einen echten Wettbewerbsvorteil bietet.
Der INP-Befund in der Praxis: Bei einer Zürcher Steuerberatungskanzlei aus unserer Analyse betrug der INP-Wert 680 Millisekunden — trotz eines PageSpeed-Scores von 78 auf Desktop. Der Grund: Ein Cookie-Management-Tool lud sechs externe Skripte nacheinander, alle im Main Thread. Nach der Entfernung eines einzigen Plugins und der Umstellung auf ein leichtgewichtigeres Consent-Tool sank der INP auf 140 Millisekunden. Kein Server-Upgrade, kein CDN. Ein Plugin weniger.
Hosting-Standort Schweiz: Was er physikalisch für TTFB bedeutet
TTFB — Time to First Byte — ist die Zeit, die vergeht, bis der Browser das erste Byte vom Server erhält. Google nennt TTFB keine offizielle Core-Web-Vitals-Metrik, macht aber in seiner eigenen Dokumentation klar: Ein TTFB über 800 Millisekunden macht einen LCP unter 2,0 Sekunden ohne aggressives CDN-Caching faktisch unmöglich. TTFB ist das Fundament jeder guten Core Web Vitals-Performance — und der Hosting-Standort ist das Fundament des Fundaments.
Daten übertragen sich mit Lichtgeschwindigkeit durch Glasfaserkabel — aber sie brauchen trotzdem Zeit. Die Distanz zwischen einem Nutzer in Zürich und einem Server in Frankfurt beträgt rund 600 km. Das ergibt eine physikalische Mindest-Latenz von etwa 4 Millisekunden. Ein Server in Oregon (USA) liegt 9.000 km entfernt — Mindest-Latenz über 60 Millisekunden, plus Routing-Overhead. Diese Zahlen summieren sich, besonders bei Requests ohne CDN.
Typische TTFB-Werte für Schweizer Nutzer nach Hosting-Standort (Richtwerte, gemessen ohne CDN)
Richtwerte aus Monitoring-Tests, variieren je nach Tageszeit, Serverauslastung und Caching-Konfiguration.
Konkret: Wer seine Schweizer KMU-Website auf einem günstigen amerikanischen Shared-Hosting-Anbieter betreibt, startet mit einem TTFB-Nachteil von 600 bis 800 Millisekunden gegenüber lokalen Anbietern — noch bevor eine einzige Zeile HTML geladen wurde. Das ist in vielen Fällen der Hauptgrund für einen schlechten LCP-Wert, und kein technisches SEO der Welt kann diesen physikalischen Nachteil vollständig kompensieren.
Infomaniak (Genf und Zürich) und Hostpoint (Dietikon ZH) sind die zwei grössten Schweizer Hosting-Anbieter mit eigenen Rechenzentren in der Schweiz. Beide liefern für Schweizer Nutzer typische TTFB-Werte unter 200 Millisekunden auf Shared Hosting — ohne CDN, ohne spezielle Konfiguration. Das ist ein struktureller Vorteil, der sich direkt in LCP-Werten niederschlägt.
Ein CDN wie Cloudflare gleicht einen Teil dieses Nachteils aus — jedoch nur für gecachte, statische Inhalte. Dynamische WordPress-Seiten, WooCommerce-Shops mit personalisiertem Inhalt oder Formulare können nicht vollständig gecacht werden. Dort bleibt der Hosting-Standort entscheidend. Mehr zum technischen Zusammenspiel erklärt unser Leitfaden zu technischem SEO für Schweizer Websites.
Core Web Vitals messen: Die richtigen Tools
Bevor man optimiert, muss man wissen, wo man steht. Und dabei gibt es eine entscheidende Unterscheidung: Lab-Daten versus Field-Daten. Google bewertet ausschliesslich Field-Daten — also echte Nutzerwerte aus Chrome. Lab-Daten aus Tools wie PageSpeed Insights oder Lighthouse zeigen Simulationen und sind nützlich für die Diagnose, aber nicht das, was Google für das Ranking heranzieht.
Core Web Vitals Tools im Überblick
| Tool | Datentyp | Bestes für | Kosten |
|---|---|---|---|
| Google Search Console | Field (CrUX) | Überblick über alle Seiten, Benachrichtigungen, Trendanalyse | Kostenlos |
| PageSpeed Insights | Beides | Einzelseitenanalyse mit Diagnose-Tipps, Kombination aus Lab+Field | Kostenlos |
| Chrome DevTools | Lab | Präzise Diagnose von Long Tasks, Rendering, Ressourcen-Ladereihenfolge | Kostenlos |
| DebugBear | Beides | Laufendes Monitoring, historische Entwicklung, Benachrichtigungen | Ab ca. USD 35/Mt |
| WebPageTest | Lab | Detaillierte Wasserfall-Analyse, Filmstrip, verschiedene Netzwerkbedingungen | Kostenlos |
Der praktische Ablauf: Starten Sie mit der Google Search Console — dort sehen Sie, welche Seiten konkret Probleme haben, basierend auf echten Nutzerdaten. Dann öffnen Sie Google PageSpeed Insights für die spezifischen Seiten mit Problemen, um die Diagnose zu erhalten. Für tiefere Ursachenforschung öffnen Sie Chrome DevTools und analysieren die Performance-Timeline. In dieser Reihenfolge sparen Sie Zeit, weil Sie nicht alles analysieren, sondern gezielt dort, wo echte Probleme existieren.
Der priorisierte Massnahmenplan für Schweizer KMU
Nach der Diagnose kommt die Frage: Was zuerst? Die folgende Reihenfolge basiert auf dem Verhältnis von Aufwand zu Wirkung — erprobt in unserer Arbeit mit Schweizer KMU-Websites.
<img>-Tag width und height-Attribute hinzu, die der tatsächlichen Anzeigedimension entsprechen. Das ermöglicht dem Browser, den Platz zu reservieren, bevor das Bild geladen ist. In WordPress macht das Yoast SEO automatisch für neue Uploads, wenn die Option aktiv ist. Ältere Bilder muss man manuell oder per Script anpassen.Als SEO-Agentur für den Schweizer Markt führen wir technische Audits durch, die alle Core Web Vitals abdecken — mit klarer Priorisierung und Massnahmen, die interne Teams oder externe Entwickler direkt umsetzen können. Wenn Sie wissen möchten, wo Ihre Website steht, bieten wir eine kostenlose Erstanalyse an.
Häufige Fragen zu Core Web Vitals
Wie stark beeinflussen Core Web Vitals das Google-Ranking?
Industrie-Forschung schätzt, dass Core Web Vitals rund 10 bis 15 Prozent der Rankingsignale ausmachen. Sie sind kein dominanter Faktor, aber ein messbarer Tiebreaker: Zwei Seiten mit vergleichbarem Content — die mit besseren Core Web Vitals rankt höher. Nach dem März-Update 2026 haben Seiten mit LCP über 2,5 s in kompetitiven Nischen durchschnittlich 2 bis 4 Positionen verloren. Für viele KMU-Websites ist das der Unterschied zwischen Seite eins und Seite zwei.
Warum zeigt Google Search Console andere Werte als PageSpeed Insights?
Das ist normal und hat einen klaren Grund: Google Search Console zeigt Field-Daten — echte Messwerte aus Chrome-Browsern echter Nutzer, über einen 28-Tage-Zeitraum gemittelt. PageSpeed Insights zeigt lab-simulierte Werte unter kontrollierten Bedingungen. Für Google-Rankings sind ausschliesslich die Field-Daten relevant. Die Lab-Werte aus PageSpeed Insights sind nützlich für die Diagnose, weil sie sofortige Änderungen spiegeln — aber sie entscheiden nicht über das Ranking.
Meine Seite hat zu wenig Besucher für CrUX-Daten — was dann?
CrUX benötigt eine Mindestanzahl an Seitenbesuchen, um Daten auszugeben — bei sehr kleinen Websites fehlen deshalb oft die Field-Daten in der Search Console. In diesem Fall fällt Google auf Domänen-Ebene-Daten zurück. In diesem Fall arbeiten Sie mit den Lab-Daten aus PageSpeed Insights. Die echten CrUX-Werte erscheinen erst, sobald Ihre Website mehr reale Besucher hat. Das ist ein Argument mehr dafür, frühzeitig mit SEO zu beginnen.
Verbessert ein CDN die Core Web Vitals zuverlässig?
Für statische Inhalte — Bilder, CSS, JavaScript, PDFs — ja, sehr zuverlässig. Cloudflare beispielsweise cached diese Ressourcen auf Servern weltweit und liefert sie vom nächstgelegenen Knoten aus. Für dynamischen Content, der bei jedem Aufruf neu generiert wird — WooCommerce-Warenkorb, personalisierte Seiten, Login-Bereiche — hilft ein CDN kaum. Dort entscheidet der Ursprungsserver. Für Schweizer Websites mit überwiegend dynamischem Inhalt ist das Schweizer Hosting daher wichtiger als ein CDN.
Wie lange dauert es, bis Core Web Vitals-Verbesserungen in Google Search Console erscheinen?
Google verwendet ein rollendes 28-Tage-Fenster für CrUX-Daten. Das bedeutet: Verbesserungen, die Sie heute implementieren, sind vollständig in den Search-Console-Berichten erst nach 4 bis 6 Wochen sichtbar — wenn die alten, schlechten Werte aus dem 28-Tage-Fenster gefallen sind. Ranking-Änderungen folgen den Datenänderungen mit einer weiteren Verzögerung von wenigen Wochen. Insgesamt sollten Sie nach einer technischen Optimierung 6 bis 10 Wochen einplanen, bevor Sie klare Auswirkungen sehen.
Haben Sie Fragen zu Ihren Core Web Vitals oder möchten Sie wissen, was konkret auf Ihrer Website zu verbessern ist? Melden Sie sich — wir schauen es uns kostenlos an.
