Core Web Vitals werden multi-browser: Was sich für Mittelstands-Performance-Reports ab Mai 2026 wirklich ändert

Am 12. Dezember 2025 hat sich für jeden, der die Performance einer Mittelstands-Website ernst nimmt, etwas Grundlegendes verschoben. Mit Safari 26.2 sind Largest Contentful Paint und Interaction to Next Paint in allen drei großen Browser-Engines messbar geworden. Das offizielle web.dev-Team nennt es seitdem „Baseline Newly available“. Klingt nach Detail, ist aber das Ende einer Ära: Eure Performance-Reports waren bisher Chrome-Reports. Ab jetzt sind sie es nicht mehr automatisch, und die meisten Mittelständler merken das erst beim nächsten Benchmark-Termin.

Mit Safari 26.2 vom 12. Dezember 2025 sind Largest Contentful Paint und Interaction to Next Paint in allen drei großen Browser-Engines messbar, und damit „Baseline Newly available“ laut Google Web‑Performance-Team. (Bild: Collective Brain)

Was genau am 12. Dezember 2025 passiert ist

Bis Dezember 2025 war Web Vitals ein Chrome-Gespräch. Die Largest Contentful Paint API und das Event Timing API, auf dem INP basiert, waren in Firefox und Safari schlicht nicht verfügbar. Wer Real-User-Monitoring betrieb, schaute auf etwa 65 bis 70 Prozent seiner Besucher: den Chrome-Anteil, und extrapolierte den Rest. Mit Safari 26.2 ist diese Lücke geschlossen. Firefox hatte die nötigen APIs bereits über die Versionen 122 und 144 ausgerollt; Safari war der letzte Holdout, und mit dem Dezember-Release liegen die nötigen Web-APIs jetzt in allen drei Engines vor. Google selbst spricht im Web-Performance-Blog von einem „fantastischen Jahresend-Geschenk“.

Die zweite Verschiebung kommt aus dem Chromium-Lager. Ab Chrome 145, das im April 2026 in der Stable-Version erschienen ist, wird neben dem bisherigen presentationTime jetzt auch der paintTime-Wert exponiert. Der Unterschied klingt nerdig, ist aber praktisch wichtig: Chrome misst LCP bisher bis zum Moment, in dem der Frame tatsächlich auf dem Bildschirm erscheint. Firefox und Safari messen bis zum früheren Punkt, an dem der Renderer den Frame fertig hat. Das ergibt für identische Seiten Differenzen im niedrigen zweistelligen Millisekunden-Bereich. Für eine Seite mit 2.300 Millisekunden LCP irrelevant. Für eine Seite an der 2.500-Millisekunden-Schwelle, und damit entscheidend.

Eure Performance-Reports waren Chrome-Reports. Ab jetzt sind sie es nicht mehr automatisch.Florian Wessling, CEO Collective Brain

Was das für deutsche Mittelständler ab Mai 2026 ändert

Die ehrliche Antwort: für 90 Prozent der Mittelstands-Websites ändert sich kurzfristig in Google Search nichts. Page Experience als Ranking-Signal nutzt Chrome-User-Experience-Report-Daten, also weiter nur Chrome-Field-Daten. Wer ausschließlich auf Rankings schielt, kann den Punkt theoretisch weiter ignorieren. Wer aber RUM einsetzt, oder wer Performance als interne KPI führt, oder wer einen Lighthouse-CI-Workflow gegen Pre-Production-Builds laufen lässt, hat ab sofort drei Diagnose-Quellen statt einer.

Der größere Hebel sitzt im internen Reporting. Wenn das Marketing-Team auf einen Performance-Report schaut und der Wert für LCP plötzlich nicht mehr 2.100 Millisekunden ist, sondern 2.180, ist die erste Frage nicht „warum ist die Seite langsamer geworden?“, sondern „warum stimmen die Zahlen nicht mit denen vom Q4-Report überein?“. Diese Frage werden 2026 Hunderte deutsche Mittelständler ihren Agenturen stellen. Wer nicht vorbereitet ist, verbringt einen Vormittag mit Erklären statt mit Optimieren.

Drei praktische Konsequenzen für die nächsten 90 Tage

Erstens: Field-Data-Setup auditieren. Wer Web Vitals via web-vitals.js sammelt, sollte prüfen, ob die eingesetzte Library-Version (mindestens 4.0) die neuen Browser unterstützt. Die Library funktioniert in Firefox und Safari erst, wenn sie die nötigen APIs zur Laufzeit detektiert. Bei alten Versionen werden Werte für diese Browser stillschweigend übersprungen. Ergebnis: Eure Daten sehen sauber aus, repräsentieren aber weiter nur Chrome.

Zweitens: Schwellenwerte browser-spezifisch dokumentieren. Die offiziellen Core-Web-Vitals-Schwellen liegen weiter bei 2.500 Millisekunden für LCP (gut), 200 Millisekunden für INP und 0,1 für CLS, aber diese Werte sind in Chrome kalibriert. Eine Firefox-Messung an der 2.500-Millisekunden-Grenze kann auf Chrome-Niveau bei 2.530 oder 2.560 Millisekunden liegen. Für interne Dashboards heißt das: Browser als Dimension einbauen, sonst vergleicht man Birnen mit Äpfeln.

Drittens: Erwartungsmanagement im Reporting. Spätestens beim ersten Quartals-Report 2026 wird ein Geschäftsführer fragen, warum die LCP-Zahl plötzlich zwei Komma-Stellen anders aussieht als im Vorquartal. Eine vorbereitete Antwort schlägt eine improvisierte Antwort. Eine kurze Folie zur Multi-Browser-Baseline gehört in das nächste Performance-Review.

Warum Google den paintTime-Switch jetzt pusht

Aus Anwender-Perspektive ist die Erklärung schlicht: Google möchte nicht, dass Chrome strukturell schlechter aussieht als Firefox und Safari. Solange Chrome bis zum vollen presentationTime misst und die anderen nur bis paintTime, hat Chrome bei jeder Messung systematisch leicht höhere LCP-Werte. Das ist für Google eine ungemütliche Story, sobald die Zahlen vergleichbar werden. Mit dem Chrome-145-Release wird der paintTime-Wert jetzt zusätzlich exponiert. Wer will, kann beide messen, vergleichen und auswählen, welcher Wert in den eigenen RUM-Stack fließt.

Für die SEO-Praxis ist die Konsequenz interessant: Chrome dokumentiert seine eigenen Metrik-Veränderungen offen, und der CrUX-Datensatz wird im Laufe von 2026 mehrere kleine, aber konsistente Anpassungen sehen. Wer LCP-Werte über mehrere Quartale historisch vergleicht, sollte den Chrome-Versions-Wechsel als Annotation in der Zeitreihe markieren: sonst wirken normale Methodik-Updates wie echte Performance-Regressionen.

Was Mittelständler in den nächsten zwei Wochen tun sollten

Es braucht keinen Sechs-Monats-Plan. Es reicht eine zweistündige Bestandsaufnahme. Wer die Hand-aufs-Herz-Frage „läuft unser RUM eigentlich auch in Firefox und Safari?“ mit „weiß ich nicht“ beantwortet, hat sein Q2-2026-Performance-Reporting schon verloren. Drei Schritte: web-vitals-Library-Version checken, RUM-Tool-Provider eine Mail schicken (alle Major-Provider haben seit Q1 2026 Cross-Browser-Support ausgerollt), interne Dashboard-Dimensionen erweitern. Mehr nicht.

Der größere Punkt liegt aber tiefer. Die Multi-Browser-Baseline ist Symptom einer breiteren Verschiebung: Web-Plattform-Features konsolidieren sich seit 2024 deutlich schneller über die drei großen Engines hinweg, als das in den 15 Jahren davor je der Fall war. Baseline als Konzept war 2023 noch ein Marketing-Begriff. Inzwischen ist es eine ernsthafte Plattform-Diagnose. Wer 2026 noch „funktioniert nur in Chrome“ als Ausrede für eine Feature-Entscheidung benutzt, hat die Verschiebung nicht mitbekommen, und seine Mittelstands-Website fährt damit in eine Engineering-Sackgasse.

Arno Hoffrichter

Chief Technology Officer, Collective Brain GmbH · Hamburg

CTO bei Collective Brain. Verantwortlich für die technische Umsetzung von Web-Projekten und SEO-Architektur.

Beratung anfragen