Core Web Vitals 2026: Warum INP für KMU trotzdem relevant bleibt
Nur 55,9% aller Websites bestehen alle drei Core Web Vitals. LCP scheitert häufiger als INP – aber plugin-lastige Sites stolpern oft an der Interaktion. Was das für KMU bedeutet.
Viele KMU-Websites bestehen die Core Web Vitals nicht – und merken es erst, wenn organischer Traffic stockt oder PageSpeed Insights rot meldet. Laut aktuellem Chrome UX Report (CrUX, Datenstand Mai 2026) bestehen nur rund 55,9% aller erfassten Origins gleichzeitig alle drei Core Web Vitals. Das ist kein reines «INP-Problem»: LCP liegt mit etwa 68,6% im «gut»-Bereich, INP mit etwa 86,6% – LCP scheitert also häufiger. Trotzdem bleibt INP für KMU relevant: Sobald Nutzer klicken, tippen oder buchen, entscheidet die Reaktionszeit über Vertrauen und Conversion.
Für über 99% aller Schweizer Unternehmen, die laut Bundesamt für Statistik als KMU gelten, sind Core Web Vitals mehr als eine technische Randnotiz. Sie sind seit Jahren ein offizielles Google-Page-Experience-Signal – eines unter vielen, kein harter Ranking-Deckel. Dieser Beitrag ordnet ein, was die Metriken 2026 bedeuten, warum plugin-lastige Websites bei Interaktion und Ladezeit stolpern, wie sich der eigene Stand prüfen lässt – und wann sich ein technischer Kurswechsel lohnt.
Was die Core Web Vitals 2026 messen – und was sich nicht geändert hat
Die drei Core Web Vitals sind unverändert: LCP (Largest Contentful Paint, unter 2,5 Sekunden), CLS (Cumulative Layout Shift, unter 0,1) und INP (Interaction to Next Paint, höchstens 200 Millisekunden für «gut»). Laut Googles offizieller Search-Central-Dokumentation bleiben genau diese drei Werte massgeblich dafür, ob eine Seite im Page-Experience-Sinne als «gut» eingestuft wird.
Wichtig: Der INP-Schwellenwert von ≤200 ms ist seit der Aufnahme von INP in die Core Web Vitals stabil. Es gibt keine belegte «Messverschärfung 2026», die Websites ohne Codeänderung massenhaft durchfallen lässt. Wer schlechte Felddaten sieht, hat in der Regel echte Latenz – durch JavaScript, Plugins, Third-Party-Skripte, schwaches Hosting oder schwere Assets – und nicht nur eine geänderte Google-Messlatte.
Soft Navigations (Seitenwechsel in Single-Page-Applications ohne klassischen Reload) werden im CrUX-Ökosystem weiterhin experimentell bzw. als TBD behandelt und sind noch nicht flächendeckend als fertiger Standard in die CrUX-Bewertung ausgerollt. SPA-Performance bleibt relevant – aber nicht mit dem Argument «seit 2026 misst CrUX Soft Navigations vollständig».
Warum INP trotzdem zur Stolperfalle für interaktive KMU-Websites wird
INP reagiert empfindlich auf alles, was den Hauptthread des Browsers blockiert, während eine Nutzerin oder ein Nutzer klickt, tippt oder wischt. Genau hier liegt das strukturelle Problem vieler gewachsener Unternehmenswebsites: Ein Content-Management-System mit Datenbank-Backend, dazu ein Dutzend oder mehr aktive Plugins für Formulare, Cookie-Banner, Chat-Widgets, Analytics und Slider – jedes davon kann eigenes JavaScript laden, das im selben Hauptthread abgearbeitet wird wie die eigentliche Nutzerinteraktion.
Das betrifft einen erheblichen Teil aller Firmenwebsites, weil ein einzelnes CMS traditionell einen sehr grossen Marktanteil bei Unternehmenswebsites hält. Jedes zusätzliche Plugin erhöht die Wahrscheinlichkeit, dass ein Klick erst in der Warteschlange landet, statt sofort eine sichtbare Reaktion auszulösen. Das Ergebnis ist selten ein dramatischer Ausfall, sondern eine schleichende Verzögerung von einigen hundert Millisekunden – unauffällig für das blosse Auge, aber messbar im CrUX-Report.
Systemisch scheitern CMS- und WordPress-Websites allerdings oft noch stärker an LCP: grosse Bilder, Render-Blocking-Ressourcen, Shared Hosting und aufgeblähte Themes drücken die Ladezeit des Hauptinhalts. Plugins können INP also spürbar verschlechtern – sie sind aber nicht der einzige und oft nicht der häufigste Grund, warum eine Domain alle drei Core Web Vitals verfehlt.
Auch Third-Party-Skripte tragen bei: Marketing-Pixel, A/B-Testing-Tools und eingebettete Widgets laufen unabhängig vom eigentlichen Seiteninhalt und summieren sich zu spürbarer Interaktions-Latenz. Je mehr solcher Bausteine eine Website ansammelt, desto wahrscheinlicher wird ein INP-Wert über 200 Millisekunden.
Besonders tückisch: Die einzelnen Verzögerungen wirken für sich genommen oft harmlos. Ein Cookie-Banner-Skript kostet vielleicht 40 Millisekunden, ein Tracking-Pixel weitere 30, ein Chat-Widget nochmals 50. Keines davon würde allein den Schwellenwert reissen. In Summe – und genau so misst der CrUX-Report die reale Nutzererfahrung – reicht das aber, um konstant über 200 Millisekunden zu landen. Wer nur einzelne Tools isoliert testet, übersieht deshalb häufig, dass erst das Zusammenspiel aller geladenen Skripte den Ausschlag gibt.
Was das für Ranking und Conversion konkret bedeutet
Der Chrome UX Report für Mai 2026 zeigt das Ausmass: Nur rund 55,9% aller erfassten Origins bestehen alle drei Core Web Vitals gleichzeitig. Bei den Einzelmetriken liegt LCP mit etwa 68,6% «gut» unter INP mit etwa 86,6% – LCP ist damit die häufigste Stolperfalle, nicht INP. Geräteaufteilungen in CrUX-Auswertungen schwanken je nach Quelle und Segmentierung; für die Einordnung genügt der offizielle Gesamtanteil von 55,9% aller Origins, die alle drei Metriken bestehen.
Für ein Schweizer KMU heisst das zweierlei. Erstens: Schlechte Core-Web-Vitals-Werte sind ein Ranking-Nachteil und ein Page-Experience-Signal – sie «deckeln» das Ranking aber nicht hart. Relevanz und Inhalte können weiterhin gewinnen; Performance ist ein Faktor unter vielen. Zweitens – und das trifft direkt ins Geschäft – wirkt sich eine träge Website unmittelbar auf das Nutzerverhalten aus: Wer nach einem Klick auf «Anfrage senden» oder «Termin buchen» eine spürbare Verzögerung erlebt, bricht den Vorgang häufiger ab oder verliert das Vertrauen in die Professionalität des Anbieters. Bei einem Kontaktformular oder einem Buchungsprozess ist genau dieser Moment geschäftskritisch.
Die Studie «KMU in Zahlen 2026» von OBT und der Universität St. Gallen zeigt zudem, wie unterschiedlich weit Schweizer KMU beim digitalen Reifegrad stehen. Wer bei der Website-Performance ins Hintertreffen gerät, verschärft diesen Abstand zusätzlich – gerade weil die Konkurrenz um Google-Sichtbarkeit branchenübergreifend zunimmt.
Den eigenen Stand in wenigen Minuten prüfen
Eine erste Einschätzung braucht keinen externen Dienstleister. Drei Schritte genügen:
1. PageSpeed Insights aufrufen. Auf pagespeed.web.dev die eigene URL eingeben. Entscheidend ist der Abschnitt mit den Felddaten («Erfahrungsbericht für Nutzer dieser Seite») – nicht der Labortest darunter. Nur Felddaten aus echten Besuchen fliessen in die Google-Bewertung ein; ein guter Labor-Score bei schlechten Felddaten schützt nicht vor einem Ranking-Nachteil.
2. Google Search Console prüfen. Unter dem Menüpunkt «Core Web Vitals» zeigt die Search Console alle URLs der eigenen Domain, gruppiert nach «Gut», «Verbesserungswürdig» und «Schlecht» – getrennt nach Mobil und Desktop. Das macht sichtbar, ob es sich um ein Einzelseiten-Problem oder ein grundsätzliches Architekturproblem handelt.
3. Auslöser identifizieren. Meist reicht ein Blick auf die Anzahl aktiver Plugins, eingebundener Drittanbieter-Skripte (Chat, Tracking, Werbenetzwerke), Bildgrössen und die Grösse des ausgelieferten JavaScripts. Browser-Entwicklertools zeigen unter «Performance» direkt, welche Skripte den Hauptthread am längsten blockieren und was LCP verzögert.
Wichtig bei der Interpretation: Ein einzelner guter oder schlechter Testlauf sagt wenig aus. Der CrUX-Report, auf dem Googles Feldbewertung basiert, aggregiert Daten aus echten Besuchen über einen rollierenden 28-Tage-Zeitraum. Eine Domain mit wenig Traffic taucht dort teilweise gar nicht auf («keine ausreichenden Daten») – in diesem Fall lohnt sich ein manueller Labortest mit Lighthouse als Annäherung, auch wenn er die reale Nutzererfahrung nur simuliert statt misst.
Wann sich ein technischer Wechsel lohnt
Nicht jede Website mit schlechten Core Web Vitals braucht einen kompletten Neuaufbau. Wenn nur einzelne Unterseiten betroffen sind, helfen oft gezielte Massnahmen: Bilder optimieren, nicht benötigte Plugins entfernen, Drittanbieter-Skripte verzögert laden, schwergewichtige Slider oder Formular-Bibliotheken ersetzen.
Anders sieht es aus, wenn die gesamte Domain durchgehend schlechte Felddaten zeigt und ein Relaunch ohnehin ansteht. Für klassische Unternehmensauftritte, Portfolios und Content-Seiten ohne komplexe interaktive Logik ist eine statische Architektur ohne Datenbank und ohne serverseitigen CMS-Unterbau dann oft der nachhaltigere Weg: Es gibt schlicht weniger Hauptthread-Stau durch Dutzende Plugin-Skripte und weniger typische LCP-Fallen durch aufgeblähte Themes – weil diese Bausteine architektonisch gar nicht existieren. Interaktionen wie Klicks auf Navigation, Formulare oder Buttons bleiben dadurch strukturell näher am Optimum.
Als Faustregel hilft eine einfache Unterscheidung: Werden Inhalte von mehreren Personen ohne technisches Wissen häufig aktualisiert und braucht es komplexe, individuelle Interaktionslogik, bleibt ein dynamischer Ansatz mit gezielter Performance-Optimierung oft die richtige Wahl. Steht dagegen die schnelle, verlässliche Präsentation von Unternehmen, Angebot und Kontaktmöglichkeit im Vordergrund, spricht die Kombination aus tieferen Betriebskosten und strukturell besseren Core Web Vitals klar für eine statische Lösung.
Ob ein gezielter Eingriff reicht oder sich ein technischer Neuaufbau lohnt, lässt sich anhand der eigenen Search-Console-Daten meist klar beantworten. Hedinger-Digital prüft den aktuellen Stand der Core Web Vitals und zeigt auf, welcher Weg für die konkrete Website sinnvoll ist. Mehr zum Aufbau performanter Unternehmenswebsites unter Statische Websites, oder direkt unverbindlich anfragen über das Kontaktformular.
