iPhone-Nutzer unsichtbar: Felddaten kennen nur einen Browser

Woher die öffentliche Bewertung ihre Zahlen nimmt

Die Core Web Vitals haben zwei Datenquellen. Im Labor misst ein Werkzeug eine Seite unter festgelegten Bedingungen, im Feld laufen Werte echter Besucher zusammen. Die öffentlich abrufbare Feldquelle ist der Chrome User Experience Report. Er speist die Bewertung, die in Berichten, Vergleichsportalen und Messwerkzeugen schlicht als Felddaten auftaucht. Die Dokumentation auf web.dev beschreibt den Zuschnitt in einem Satz: Der Bericht ist, wie der Name schon sagt, auf Chrome beschränkt (web.dev). Der Unterschied zwischen Labor und Feld steht ausführlich im Beitrag zu Felddaten und Labordaten; hier geht es um die andere Frage, nämlich wessen Erfahrung in den Felddaten überhaupt steckt.

Auch innerhalb von Chrome ist es nicht jeder Besucher. Erfasst wird laut web.dev nur der Teil der Chrome-Nutzer, der der Übermittlung der Daten bei der Installation zugestimmt hat; dazu kommen weitere Bedingungen für Gerät und Sitzung. Welchen Anteil der Nutzer diese Kriterien erfüllen, veröffentlicht Chrome nach eigener Auskunft nicht (Chrome-Dokumentation). Für die Praxis heißt das: Der Bericht liefert einen Ausschnitt, dessen Kantenlänge niemand außerhalb des Herstellers kennt. Das ist kein Vorwurf an die Quelle, sie sagt es selbst - es ist ein Grund, die Zahl nicht für die Erfahrung aller Besucher zu halten.

Wer in der Stichprobe gar nicht vorkommt

Die wichtigste Auslassung betrifft ein ganzes Betriebssystem. Chrome auf iOS zählt nicht mit, weil die App dort auf die WebKit-Engine des Systems aufsetzt und nicht auf die Engine, die den Bericht speist; web.dev benennt das ausdrücklich als Folge der Chrome-Beschränkung. Damit fällt jeder iPhone- und iPad-Besuch heraus, unabhängig davon, welchen Browser der Besucher installiert hat. Ebenfalls außen vor bleiben eingebettete App-Browser: Android-WebViews gelten laut web.dev nicht als Chrome, ihre Daten fließen nicht ein - Chrome Custom Tabs dagegen schon. Wer viel Verkehr aus sozialen Apps oder aus einer eigenen App bezieht, misst also einen Teil davon und einen anderen Teil nicht.

• Chrome auf Android und auf dem Rechner: fließt ein, sofern der Nutzer der Übermittlung zugestimmt hat und die weiteren Bedingungen erfüllt sind
• Chrome auf iOS: fließt nicht ein, weil darunter die WebKit-Engine des Systems arbeitet (web.dev)
• Safari auf iPhone, iPad und Mac: liefert keine Daten an den öffentlichen Bericht
• Firefox und andere Engines: liefern keine Daten an den öffentlichen Bericht
• Android-WebView in fremden Apps: zählt nicht als Chrome (web.dev)
• Chrome Custom Tabs: zählen mit (web.dev)

Die Zeile mit iOS ist die teure. Ein Betreiber im Handel oder in einer beratenden Dienstleistung hat häufig einen iOS-Anteil im Bereich von einem Drittel bis zur Hälfte der mobilen Besuche. Für diesen Teil des Publikums existiert in der öffentlichen Bewertung kein einziger Messwert, und zwar nicht als Rundungsfehler, sondern als Systementscheidung.

In welche Richtung die Lücke die Zahl verschiebt

Ein fehlender Teil des Publikums verschiebt das Ergebnis nicht zufällig, sondern in eine benennbare Richtung. web.dev beschreibt, dass iOS-Nutzer typischerweise auf leistungsfähigeren Geräten sitzen oder aus Ländern mit besserer Netzanbindung kommen, und dass ihre Aufnahme in die Auswertung deshalb zu insgesamt besseren Werten führen kann (web.dev). Umgekehrt gelesen: Der öffentliche Bericht zeigt tendenziell eine härtere Zahl als die Erfahrung des gesamten Publikums. Wer seine eigene Messung mit dem Bericht vergleicht und dort bessere Werte sieht, hat nicht zwangsläufig falsch gemessen.

Der zweite Fehler läuft in die andere Richtung und ist der gefährlichere. Ein Problem, das nur in der WebKit-Engine auftritt - eine Schrift, die dort später umschaltet, ein Video, das dort nicht vorgeladen wird, eine Eingabeverzögerung in einem Formular - erzeugt im öffentlichen Bericht keinen einzigen Datenpunkt. Die Bewertung bleibt grün, während ein erheblicher Teil der Besucher eine spürbar andere Seite erlebt. Grüne Balken und Beschwerden sind in dieser Konstellation kein Widerspruch, sondern die erwartbare Folge einer Stichprobe, die diesen Teil des Publikums nicht enthält.

Nicht jede Kennzahl gibt es in jedem Browser

Die Lücke schließt sich nicht dadurch, dass man einfach überall misst, denn die Kennzahlen selbst sind ungleich verteilt. Die Layoutverschiebung (Cumulative Layout Shift) steht laut web.dev nur in Chromium-basierten Browsern zur Verfügung. Die auf dem Rendern beruhenden Kennzahlen wie der größte Inhaltsbereich (LCP), die Reaktionszeit auf Eingaben (INP) und der erste sichtbare Inhalt (FCP) gibt es in Safari und Firefox zwar, sie werden dort aber anders gemessen (web.dev). Eine eigene Messung muss das abbilden: Sie schreibt die Engine mit und vergleicht Engine gegen Engine, nicht Engine gegen Durchschnitt.

Die Schwellenwerte selbst sind unabhängig davon dokumentiert. Für eine gute Erfahrung soll der größte Inhaltsbereich laut web.dev innerhalb von 2,5 Sekunden nach Ladebeginn erscheinen, die Reaktionszeit auf Eingaben bei 200 Millisekunden oder darunter liegen und die Layoutverschiebung 0,1 oder weniger betragen; abgelesen wird jeweils am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgerät und Rechner (web.dev). Wie diese Werte im Einzelnen zustande kommen, steht in den Beiträgen zur Optimierung der Core Web Vitals, zur Reaktionszeit auf Eingaben und zur Zerlegung des größten Inhaltsbereichs.

Geschlossene Bereiche fehlen vollständig

Die zweite Auslassung betrifft nicht den Browser, sondern die Seite. Eine Seite muss öffentlich auffindbar sein, um überhaupt für die Aufnahme in den Datensatz in Frage zu kommen (Chrome-Dokumentation), und sie muss ausreichend populär sein, damit eine Mindestzahl an Messwerten zusammenkommt (web.dev). Die genaue Schwelle wird nicht veröffentlicht; sie ist nach Angabe der Dokumentation so gewählt, dass die statistische Verteilung der aufgenommenen Seiten belastbar ist. Seiten und Ursprünge, die diese Schwelle nicht erreichen, sind im Datensatz nicht enthalten (Chrome-Dokumentation).

Damit fehlt genau der Teil, an dem Geld hängt: Anmeldung, Konto, Warenkorb, Kasse, Terminbuchung, Kundenbereich. Diese Seiten sind nicht öffentlich auffindbar, also kommen sie im Bericht nicht vor - egal wie langsam sie sind. Dazu kommt eine Regel, die ganze Ursprünge herausnehmen kann: Werden mehr als 20 Prozent des Verkehrs eines Ursprungs oder einer Seite wegen nicht zulässiger Kombinationen von Merkmalen ausgeschlossen, fällt der Ursprung vollständig aus dem Datensatz (Chrome-Dokumentation). Zusätzlich wird dem Datensatz nach eigener Auskunft eine kleine Menge Zufall beigemischt, damit sich daraus keine sensiblen Größen wie das Verkehrsaufkommen zurückrechnen lassen.

Eingebettete Rahmen sind ein Sonderfall mit umgekehrtem Vorzeichen. Seiten, die als iframe eingebunden sind, werden im Bericht nicht getrennt ausgewiesen, tragen aber zu den Kennzahlen der umgebenden Seite bei (Chrome-Dokumentation). Ein langsamer eingebetteter Terminkalender oder eine schwerfällige Kartenansicht verschlechtert damit die Zahl der Seite, ohne dass die Ursache im Bericht sichtbar wird.

Wie groß der unsichtbare Anteil in Deutschland ist

Für eine Größenordnung hilft der Anteil der mobilen Betriebssysteme. Der Erhebung von StatCounter für Deutschland zufolge lag der iOS-Anteil an den Seitenaufrufen mobiler Geräte im Zeitraum September 2025 bis August 2026 zwischen 27,59 Prozent im August 2026 und 44,82 Prozent im Mai 2026; Android liegt im selben Zeitraum entsprechend zwischen 54,95 und 72,40 Prozent. Die Spannweite von rund siebzehn Prozentpunkten innerhalb eines Jahres zeigt zugleich, wie wenig belastbar ein einzelner Monatswert für eine Planung ist.

Diese Zahlen sind eine Landkarte, kein Grundbuch. StatCounter zählt Seitenaufrufe im eigenen Messnetz, nicht die Besucher einer bestimmten Website; in einer Premium-Zielgruppe liegt der iOS-Anteil regelmäßig darüber, in einer preisorientierten darunter. Der eigene Anteil steht ausschließlich in der eigenen Messung, und genau dort gehört er hin: Wer weiß, dass vier von zehn mobilen Besuchen über WebKit kommen, bewertet eine grüne öffentliche Zahl anders als jemand, der von neunzig Prozent Chrome ausgeht. Der Beitrag zur Geschwindigkeit auf Mobilgeräten ordnet ein, was daraus für die Optimierung folgt.

Die eigene Messung daneben legen

Die Werte, aus denen der öffentliche Bericht entsteht, liefert der Browser selbst über seine Messschnittstellen. Sie sind nicht reserviert: Dasselbe Skript, das in Chrome Werte erhebt, erhebt sie in Safari und Firefox ebenfalls, nur mit dem kleineren Kennzahlensatz. Eine eigene Messung im Feld besteht deshalb aus drei Teilen - einem kleinen Skript in der Seite, einem Endpunkt, der die Werte annimmt, und einer Auswertung, die nach Engine, Plattform und Seitentyp trennt. Ein Beispiel für eine solche Übertragung, wie sie beim Verlassen der Seite abgeschickt wird:

{
  "seite": "/produkt/laufschuh-trail-42",
  "typ": "produktdetail",
  "engine": "webkit",
  "plattform": "ios",
  "geräteklasse": "mobil",
  "verbindung": "4g",
  "messwerte": {
    "lcp_ms": 3120,
    "fcp_ms": 1480,
    "inp_ms": 264,
    "ttfb_ms": 410,
    "cls": null
  },
  "hinweis": "cls in dieser Engine nicht messbar",
  "ausgeloest_durch": "visibilitychange",
  "zeitpunkt": "2026-10-02T09:14:22Z"
}

Zwei Dinge sind an diesem Datensatz wichtig. Erstens steht die Engine drin, nicht nur der Produktname des Browsers - nur so lässt sich die Zeile später gegen den öffentlichen Bericht halten. Zweitens steht bei der Layoutverschiebung ein leeres Feld und keine Null: Eine Null wäre die Behauptung, es habe keine Verschiebung gegeben, während der Wert in dieser Engine schlicht nicht erhoben werden kann. Diese Unterscheidung entscheidet später darüber, ob ein Mittelwert stimmt oder still um die fehlenden Messungen herumgerechnet wird.

Die Beispielausgabe zeigt den Punkt, um den es geht: Die Chrome-Zeile allein sieht ordentlich aus, die WebKit-Zeile liegt deutlich darüber, und der öffentliche Bericht kennt nur die erste. Eine Messung ohne Endgerätespeicher reicht dafür aus, weil kein Wiedererkennen über Besuche hinweg nötig ist - die Analyse ohne Cookies zählt Ereignisse, keine Personen. Wie das Skript eingebunden wird und welche Felder es sendet, steht in der Dokumentation zum Tracker. Wie viele Messungen unterwegs verloren gehen und was dagegen hilft, behandelt der Beitrag zu den Messverlusten durch Inhaltsblocker.

Gleich messen, sonst streitet man über Artefakte

Sobald zwei Zahlen nebeneinander liegen, beginnt der Streit über die Abweichung. Der größte Teil dieser Abweichungen ist kein Messfehler, sondern eine Folge unterschiedlicher Zuschnitte. Die Dokumentation nennt die vier Stellschrauben, an denen eine eigene Auswertung an den öffentlichen Bericht angeglichen wird: nur Chrome-Nutzer, getrennt nach Rechner und Mobilgerät, Werte am 75. Perzentil, Zeitraum 28 Tage (web.dev). Der Zeitraum ist dabei keine Einstellung, sondern fest: Der Bericht beruht auf einem gleitenden Fenster von 28 Tagen, das sich nicht ändern lässt.

Das 75. Perzentil ist ebenfalls eine bewusste Entscheidung und keine Glättung. Abgelesen wird der Wert, den 75 Prozent der Seitenaufrufe erreicht haben (web.dev); die Begründung lautet, dass es im Feld Ausreißer gibt und der Wert nach Abzug des schlechtesten Viertels beschreiben soll, was die Mehrheit der Besucher vernünftigerweise erwarten darf. Wer in der eigenen Auswertung Mittelwerte bildet, bekommt eine andere Zahl und hat damit keinen Widerspruch gefunden, sondern eine andere Frage beantwortet. Was Perzentile in der Betriebsmessung leisten, steht im Beitrag zu den Perzentilen p95 und p99.

Zwei weitere Unterschiede tauchen regelmäßig als vermeintliche Fehler auf. Wiederherstellungen aus dem Vor- und Zurück-Zwischenspeicher zählt der öffentliche Bericht als Seitenaufrufe, obwohl kein gewöhnlicher Ladevorgang stattfindet (web.dev) - viele eigene Auswertungen tun das nicht und haben deshalb weniger, aber schnellere Aufrufe. Und Anwendungen, die ihre Ansichten im Browser wechseln, statt neu zu laden, erzeugen Übergänge, die dem öffentlichen Bericht als eigene Seitenaufrufe fehlen; der Beitrag zu den weichen Navigationen geht darauf ein.

Eine Zahl, die nur einen Browser kennt, ist keine falsche Zahl. Sie ist eine richtige Antwort auf eine Frage, die niemand gestellt hat - nämlich die nach der Erfahrung derjenigen, die zufällig mit der richtigen Engine vorbeikamen.

— XICTRAQ

Was daraus für die Arbeitsweise folgt

Die öffentliche Zahl bleibt nützlich: Sie ist unabhängig erhoben, über Seiten hinweg vergleichbar und kostet keine eigene Infrastruktur. Sie taugt nur nicht als alleinige Grundlage für eine Entscheidung, deren Ergebnis für alle Besucher gelten soll. Fünf Punkte machen aus beiden Quellen ein Bild, das trägt:

• Den eigenen Anteil an Engines und Plattformen kennen, monatlich, aus der eigenen Messung und nicht aus einer Marktstatistik.
• Die Felddaten je Engine getrennt auswerten und nie über alle Engines mitteln, solange der Kennzahlensatz unterschiedlich ist.
• Die öffentliche Zahl nur gegen den passenden Ausschnitt der eigenen Daten halten: Chrome, gleiche Geräteklasse, 75. Perzentil, 28 Tage.
• Strecken hinter der Anmeldung eigenständig messen, weil sie im öffentlichen Bericht grundsätzlich fehlen.
• Fehlende Werte als fehlend führen und nicht als Null, damit ein Durchschnitt nicht still um die Lücke herumrechnet.

Für die Zusammenarbeit mit Dienstleistern hat das eine unmittelbare Folge. Wer Geschwindigkeit als Leistung vereinbart, sollte festhalten, welche Quelle bei Streit zählt, über welchen Zeitraum und auf welcher Geräteklasse - sonst legt die eine Seite den öffentlichen Bericht und die andere die eigene Messung vor, und beide haben recht. Wie ein solches Messprotokoll bei der Abnahme aussieht, steht im Beitrag zur Abnahme mit Messprotokoll; welcher Messpunkt in einem Vertrag über Verfügbarkeit gilt, behandelt der Beitrag zum Messpunkt im Vertrag. Für die laufende Arbeit hilft ein Budget je Kennzahl, wie es der Beitrag zu den Budgets für Web Vitals beschreibt.

Der pragmatische Einstieg dauert eine Viertelstunde: einmal die öffentliche Zahl für die wichtigsten Seiten abrufen, etwa über die Prüfung der Core Web Vitals, daneben die eigene Messung für dieselben Seiten aufsetzen und nach vier Wochen beide Stände nebeneinanderlegen. Weichen sie deutlich voneinander ab, ist die Ursache fast immer in dieser Reihenfolge zu finden: anderer Engine-Mix, anderer Zeitraum, anderer Ablesepunkt, andere Seitenauswahl. Erst wenn diese vier geklärt sind, lohnt die Suche nach einem technischen Defekt.