iPhone Users Invisible: Field Data Knows One Browser

Where the public assessment gets its numbers

Core Web Vitals have two data sources. In the lab, a tool measures a page under fixed conditions; in the field, values from real visitors are aggregated. The publicly available field source is the Chrome User Experience Report. It feeds the assessment that appears in reports, comparison portals and measurement tools simply as "field data". The documentation on web.dev describes its scope in one sentence: the report is, as its name suggests, Chrome-only (web.dev). The difference between lab and field is covered in detail in the article on field data versus lab data; this article asks the other question, namely whose experience the field data actually contains.

Even within Chrome it is not every visitor. According to web.dev, only the subset of Chrome users who opted in to sharing data when the browser was installed is measured, and further conditions for device and session apply. Chrome states that it does not publish what proportion of users meet these criteria (Chrome documentation). In practice this means the report delivers an excerpt whose edge length nobody outside the vendor knows. That is not an accusation against the source, which says so itself - it is a reason not to mistake the number for the experience of all visitors.

Who never appears in the sample at all

The most important omission covers an entire operating system. Chrome on iOS does not count, because there the app sits on the system's WebKit engine rather than the engine that feeds the report; web.dev names this explicitly as a consequence of the Chrome restriction. Every iPhone and iPad visit therefore drops out, regardless of which browser the visitor has installed. Embedded in-app browsers are left out as well: according to web.dev, Android WebViews do not count as Chrome and their data is not included, while Chrome Custom Tabs are. Anyone with substantial traffic from social apps or from an own app is therefore measuring part of it and not the rest.

• Chrome on Android and on the desktop: included, provided the user opted in to sharing and the further conditions are met
• Chrome on iOS: not included, because the system's WebKit engine runs underneath (web.dev)
• Safari on iPhone, iPad and Mac: contributes nothing to the public report
• Firefox and other engines: contribute nothing to the public report
• Android WebView inside third-party apps: does not count as Chrome (web.dev)
• Chrome Custom Tabs: are included (web.dev)

The iOS row is the expensive one. A retailer or a professional services firm often sees an iOS share somewhere between a third and half of all mobile visits. For that part of the audience the public assessment holds not a single measurement - not as a rounding error, but by design.

Which way the gap moves the number

A missing part of the audience does not shift the result at random but in a nameable direction. web.dev describes that iOS users are typically on more performant devices or visit from countries with better network infrastructure, and that including them can therefore lead to higher overall performance metrics (web.dev). Read the other way round: the public report tends to show a harsher number than the experience of the full audience. Anyone comparing their own measurement against the report and seeing better values there has not necessarily measured wrongly.

The second error runs the other way and is the more dangerous one. A problem that only occurs in the WebKit engine - a font that swaps later there, a video that is not preloaded, an input delay inside a form - produces not a single data point in the public report. The assessment stays green while a substantial share of visitors experiences a noticeably different page. In that situation, green bars and complaints are not a contradiction but the expected consequence of a sample that does not contain this part of the audience.

Not every metric exists in every browser

The gap does not close simply by measuring everywhere, because the metrics themselves are unevenly distributed. According to web.dev, Cumulative Layout Shift is only available in Chromium-based browsers. Paint-based metrics such as Largest Contentful Paint, Interaction to Next Paint and First Contentful Paint do exist in Safari and Firefox, but are measured in a different way (web.dev). A first-party measurement has to reflect that: it records the engine and compares engine against engine, not engine against an average.

The thresholds themselves are documented independently of this. For a good user experience, web.dev states that Largest Contentful Paint should occur within 2.5 seconds of the page starting to load, that pages should have an Interaction to Next Paint of 200 milliseconds or less, and that they should maintain a Cumulative Layout Shift of 0.1 or less; each is read at the 75th percentile of page loads, segmented across mobile and desktop devices (web.dev). How these values come about in detail is covered in the articles on Core Web Vitals optimisation, on interaction responsiveness and on breaking down the largest contentful paint.

Areas behind a login are missing completely

The second omission concerns the page rather than the browser. A page must be publicly discoverable to be considered for inclusion in the dataset at all (Chrome documentation), and it must be sufficiently popular so that a minimum sample size comes together (web.dev). The exact threshold is not disclosed; according to the documentation it is chosen so that the statistical distribution for included pages is dependable. Pages and origins that do not meet the popularity threshold are not part of the dataset (Chrome documentation).

That removes precisely the part where the money sits: sign-in, account, basket, checkout, appointment booking, customer area. These pages are not publicly discoverable, so they do not appear in the report, no matter how slow they are. On top of that comes a rule that can remove entire origins: where more than 20 per cent of an origin's or a page's total traffic is excluded due to ineligible combinations of dimensions, the origin is excluded from the dataset entirely (Chrome documentation). In addition, a small amount of randomness is applied to the dataset so that sensitive figures such as total traffic volumes cannot be reverse-engineered from it.

Embedded frames are a special case with the opposite sign. Pages included as iframes are not reported separately, but they do contribute to the metrics of the top-level page (Chrome documentation). A slow embedded booking calendar or a heavy map view therefore degrades the number for the page without the cause becoming visible in the report.

How large the invisible share in Germany is

For an order of magnitude, the share of mobile operating systems helps. According to the StatCounter data set for Germany, the iOS share of page views from mobile devices between September 2025 and August 2026 ranged from 27.59 per cent in August 2026 to 44.82 per cent in May 2026; Android correspondingly ranged from 54.95 to 72.40 per cent over the same period. The spread of roughly seventeen percentage points within a single year also shows how little a single monthly figure carries for planning.

These numbers are a map, not a land register. StatCounter counts page views within its own measurement network, not the visitors of a particular website; in a premium audience the iOS share regularly sits above this, in a price-driven one below. Your own share exists only in your own measurement, and that is where it belongs: anyone who knows that four in ten mobile visits arrive over WebKit reads a green public number differently than someone assuming ninety per cent Chrome. The article on speed on mobile devices sorts out what follows from this for optimisation.

Putting your own measurement alongside

The values the public report is built from are delivered by the browser itself through its measurement interfaces. They are not reserved: the same script that collects values in Chrome collects them in Safari and Firefox as well, just with the smaller set of metrics. A first-party field measurement therefore consists of three parts - a small script in the page, an endpoint that accepts the values, and an analysis that separates by engine, platform and page type. An example of such a transmission, sent as the page is left:

{
  "page": "/product/trail-running-shoe-42",
  "type": "product-detail",
  "engine": "webkit",
  "platform": "ios",
  "device_class": "mobile",
  "connection": "4g",
  "metrics": {
    "lcp_ms": 3120,
    "fcp_ms": 1480,
    "inp_ms": 264,
    "ttfb_ms": 410,
    "cls": null
  },
  "note": "cls not measurable in this engine",
  "triggered_by": "visibilitychange",
  "timestamp": "2026-10-02T09:14:22Z"
}

Two things about this record matter. First, the engine is in there, not just the product name of the browser - only that makes the row comparable against the public report later. Second, the layout shift field is empty rather than zero: a zero would claim that no shift occurred, while the value simply cannot be collected in this engine. That distinction later decides whether an average is correct or quietly computed around the missing measurements.

The sample output shows the whole point: the Chrome row on its own looks respectable, the WebKit row sits clearly above it, and the public report only knows the first. A measurement without device storage is enough for this, because no recognition across visits is required - analytics without cookies counts events, not people. How the script is embedded and which fields it sends is described in the tracker documentation. How many measurements are lost in transit and what helps against it is covered in the article on measurement loss caused by content blockers.

Measure alike, or argue about artefacts

As soon as two numbers sit side by side, the argument about the difference begins. Most of those differences are not measurement errors but a consequence of different scopes. The documentation names the four adjustments that align a first-party analysis with the public report: Chrome users only, separated into desktop and mobile, values at the 75th percentile, a period of 28 days (web.dev). The period is not a setting but fixed: the report is based on a sliding 28-day window of traffic that cannot be changed.

The 75th percentile is a deliberate decision as well, not a smoothing. What is read is the value that 75 per cent of page views achieved (web.dev); the reasoning is that field data contains extremes and that, after removing the worst quarter, the value should describe what the majority of visitors can reasonably expect. Anyone forming averages in their own analysis gets a different number and has not found a contradiction but answered a different question. What percentiles do in operational measurement is covered in the article on the p95 and p99 percentiles.

Two further differences regularly show up as supposed errors. Restores from the back/forward cache are treated as page navigations by the public report even though no conventional page load happens (web.dev) - many first-party analyses do not do this and therefore see fewer, but faster, page views. And applications that swap their views in the browser instead of reloading produce transitions that are missing from the public report as page views of their own; the article on soft navigations goes into this.

A number that knows only one browser is not a wrong number. It is a correct answer to a question nobody asked - the experience of those who happened to arrive with the right engine.

— XICTRAQ

What this means for the way you work

The public number stays useful: it is collected independently, comparable across sites and available in many tools without infrastructure of your own. It just does not work as the sole basis for a decision whose result is supposed to hold for all visitors. Five points turn both sources into a picture that carries:

• Know your own share of engines and platforms, monthly, from your own measurement rather than from a market statistic.
• Evaluate field data per engine and never average across engines while the set of metrics differs between them.
• Only hold the public number against the matching slice of your own data: Chrome, same device class, 75th percentile, 28 days.
• Measure journeys behind the login yourself, because they are absent from the public report by definition.
• Carry missing values as missing rather than as zero, so that an average does not quietly compute around the gap.

For work with service providers this has an immediate consequence. Anyone agreeing on speed as a deliverable should record which source counts in a dispute, over which period and on which device class - otherwise one side presents the public report, the other their own measurement, and both are right. What such a measurement record looks like at acceptance is covered in the article on acceptance with a measurement record; which measurement point applies in an availability contract is covered in the article on the measurement point in the contract. For day-to-day work, a budget per metric helps, as described in the article on budgets for web vitals.

The pragmatic start takes fifteen minutes: pull the public number for your most important pages once, for example with the Core Web Vitals check, set up your own measurement for the same pages alongside it, and put both states side by side after four weeks. If they differ markedly, the cause is almost always found in this order: a different engine mix, a different period, a different read-out point, a different page selection. Only once those four are settled is it worth looking for a technical defect.