This question needs a factual correction before any diagnostic steps make sense: if “field assessment” refers to CrUX (Chrome User Experience Report), which is what powers the Core Web Vitals report in Search Console and the field-data section of PageSpeed Insights, then a failure “exclusively on iOS Safari” is not something that dataset can show, because CrUX collects data only from Chrome. iOS Safari is not Chrome and does not report telemetry into CrUX at all; there is no Safari row, segment, or slice in that dataset to fail on. If iOS Chrome is involved, that’s still Chrome-based data collection, architecturally distinct from Safari/WebKit, and would appear in CrUX as Chrome data, not Safari data. So the first diagnostic step, before anything technical, is to identify which data source actually produced the “iOS Safari fails” observation, because the two realistic possibilities point in completely different directions.
Clarifying the data source: CrUX cannot show this
Google’s own CrUX documentation is explicit that the dataset is built from opted-in Chrome users, across desktop and mobile Chrome (including Chrome on Android and Chrome on iOS), plus other Chromium-based contexts Google includes under the CrUX umbrella. Safari, on any platform, uses WebKit and is developed by Apple; it does not send data to CrUX, and there is no Google-documented path by which it would. This means:
- If the failure was observed in Search Console’s Core Web Vitals report, PageSpeed Insights field data, or any tool built on the CrUX API/BigQuery dataset, it is mathematically impossible for that failure to be “iOS Safari specific,” because iOS Safari traffic isn’t represented in the numbers at all. What might actually be happening is that the site has a segment of traffic behaving differently that happens to correlate with iOS devices in some other tool, and someone has mislabeled a Chrome-on-iOS or a non-CrUX signal as “Safari.”
- If the failure was observed via a third-party RUM (real user monitoring) vendor, browser analytics platform, or a custom performance-beacon implementation that captures its own field metrics independent of CrUX, then it absolutely can segment by browser/engine including Safari, and an iOS-Safari-specific failure in that data is a real, diagnosable signal. This is the scenario the rest of this answer addresses, since it’s the only one that’s internally consistent with the premise.
Getting this distinction right matters beyond pedantry: if a team is chasing a “CrUX shows Safari failing” ticket, they’re debugging a data-interpretation error, not a performance problem, and no amount of WebKit-specific optimization will change numbers that were never measuring Safari in the first place. Confirm the actual measurement source before writing a single line of diagnostic code.
Diagnostic steps once it’s confirmed to be genuine RUM/non-CrUX Safari-specific field data
Assuming the failure is confirmed via a RUM tool or custom instrumentation that does capture Safari as a distinct segment, the diagnostic path is different from a generic CWV investigation because it needs to isolate what’s specific to WebKit/iOS Safari rather than the page in general (which the lab tests, presumably run in Chrome/Lighthouse, already passed).
Segment the RUM data by device and iOS/Safari version. iOS Safari’s rendering and JS engine (JavaScriptCore, not V8) has different performance characteristics release to release, and older iOS versions on older hardware (still a meaningful share of traffic for many sites) can behave very differently from the latest iPhone on the latest iOS. Confirm whether the failure is uniform across all iOS Safari traffic or concentrated in specific device/OS combinations, since a fix path differs substantially between “all Safari is slow” and “Safari on devices 4+ years old is slow.”
Use Safari Web Inspector, not Chrome DevTools, to reproduce. Chrome DevTools’ Performance panel, its long-task attribution, and its Lighthouse integration all run against Chromium’s rendering and JS engine, which is architecturally different from WebKit. A page can genuinely have no long tasks and fast paint timing under Chromium’s V8 engine while behaving differently under JavaScriptCore, because JIT compilation strategy, garbage collection behavior, and layout/paint scheduling all differ between engines. Safari Web Inspector (available via Safari’s Develop menu on macOS, and reachable for iOS Safari debugging via a connected device) has its own Timelines tool that shows script execution, layout, and paint phases specific to WebKit’s actual behavior, and is the only way to see the real bottleneck rather than inferring it from a different engine’s behavior.
Check for WebKit-specific API gaps causing fallback code paths. If the site’s JavaScript (including third-party scripts) feature-detects for APIs that are Chrome/Chromium-specific or arrived in WebKit later, iOS Safari may be silently executing a slower fallback or polyfill path that Chrome never triggers. Common candidates worth checking specifically: differences in Intersection Observer edge-case behavior, requestIdleCallback support (historically absent or inconsistent in Safari, meaning code written assuming its availability may fall back to a less efficient scheduling method), and differences in how each engine handles image decoding APIs or font loading events. Any of these can produce a genuine performance gap specific to WebKit without the underlying page markup or CSS being at fault at all.
Test whether it’s a scheduling/main-thread problem rather than a resource-loading problem. Since lab tests (Chrome-based Lighthouse) already pass, the resource waterfall, image sizes, and general document structure are presumably fine, since those would show up as failures in Chrome too. That points diagnostic attention toward things that are engine-behavior-dependent rather than markup-dependent: JS execution and compilation time differences, differences in how each engine schedules paint relative to script execution, and differences in how each browser handles the specific web vitals APIs themselves (the metrics are computed client-side using the browser’s own timing APIs, and any polyfill libraries used to compute them client-side, such as the web-vitals JS library, need to be confirmed to behave correctly under Safari specifically, since a broken metric-computation polyfill is itself a possible explanation for anomalous Safari-only numbers, separate from any real user-experience problem).
Rule out third-party script behavior differences by engine before assuming first-party code is the cause. Ad tech, analytics, and consent-management scripts are frequently tested primarily against Chrome by their vendors and can have less-optimized or buggier code paths under WebKit. Since these scripts are common contributors to poor INP and LCP in general, and since they’re outside first-party code control, isolating whether disabling third-party scripts (in a controlled test) closes the Safari-specific gap is a high-value early step before assuming the site’s own code is responsible.
The overall sequence: confirm the data source is genuinely capable of showing Safari-specific results (CrUX cannot; a RUM tool can), then reproduce using WebKit’s own tooling rather than Chromium’s, then look specifically at engine-behavior differences (API availability, scheduling, third-party script quality under WebKit) rather than re-running the same Chrome-oriented lab checks that already passed and won’t reveal an engine-specific gap.
A worked example of tracking down a genuine Safari-only gap
Consider a mid-size retail site whose RUM vendor segments field data by browser and shows INP failing specifically on iOS Safari sessions, around 340ms at the 75th percentile, while Chrome sessions on comparable devices sit around 150ms, well within the “good” threshold, and Lighthouse in Chrome shows no long tasks at all on the same page. Segmenting the RUM data further shows the gap is concentrated on iOS 15 and 16 devices rather than the newest iOS release, which points toward an engine or API difference rather than a universal WebKit slowdown. Reproducing the interaction in Safari Web Inspector’s Timelines tool reveals the site’s “add to cart” handler calling requestIdleCallback, an API iOS Safari has historically lacked or supported inconsistently, so the code silently falls back to a same-tick synchronous execution path instead of yielding, something Chrome never triggers because it has full requestIdleCallback support. Rewriting that one fallback to use a setTimeout-based yield instead closes most of the gap in the next reporting period. The lab tests never would have caught this, because the failure lived entirely in a WebKit-specific code path that Chromium’s engine simply never executes.
