How to measure LCP and INP in Safari 26.2 (and what still only Chrome reports)

For years, many agency Core Web Vitals programmes had a quiet blind spot. Chrome users filled CrUX, Search Console, and PageSpeed Insights field panels. Safari users on iPhone and Mac still felt slow pages, yet your JavaScript often never saw largest-contentful-paint or Event Timing entries in WebKit. That gap mattered whenever a client’s traffic mix was heavy on iOS, education, or consumer brands with strong Apple share.

Safari 26.2, released 12 December 2025, adds the Largest Contentful Paint API and the Event Timing API in WebKit. You can finally collect Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) from real Safari sessions through the Performance API, your own analytics, or a real user monitoring (RUM) tool. What follows is a practical measurement guide: how to observe the new entries, how to use Google’s web-vitals library, what still only Chrome reports in public Google tools, and where scheduled PageSpeed monitoring still fits beside Safari RUM.

What Safari 26.2 changed for LCP and INP measurement

Apple’s WebKit Features for Safari 26.2 post states that Safari 26.2 adds support for Event Timing and Largest Contentful Paint. Event Timing follows an interaction from input through event handlers and DOM updates until the next paint, which is the raw material for INP. Largest Contentful Paint reports when the largest visible element in the viewport finished painting during load. Web Inspector also shows LCP entries in the Timelines tab, which is useful for verifying a hero image or text block before you trust a production pipeline.

Google’s web.dev note on Baseline marks LCP and INP measurement APIs as Baseline Newly available after Safari 26.2 completed the major-browser set (Chromium already had them; Firefox added the INP pieces earlier). Newly available does not mean every visitor has upgraded. Users on older iOS builds, managed devices, or delayed OS updates still will not emit these entries until they move to a supporting Safari. Plan for mixed support for months, not for a single overnight switch.

Metric definitions have not changed. LCP still describes load feel for the main content. INP still describes responsiveness across interactions on the page. CLS still measures layout stability and remains Chromium-led in many RUM stacks. If you need a refresher before you change reporting templates, start with LCP, INP, and CLS explained and our INP guide.

How to measure LCP in Safari with PerformanceObserver

Once Safari exposes largest-contentful-paint entries, you can observe them the same way you do in Chromium. Register a PerformanceObserver with buffered: true so candidates that fired before your script loaded still appear. Log or beacon each candidate, and treat the last candidate before the page is hidden as the LCP you report for that navigation.

const lcpObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    // Candidates update as larger elements paint; keep the latest.
    console.log('LCP candidate', entry.startTime, entry.element, entry.url);
  }
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

Finalise on visibilitychange or pagehide when the document becomes hidden, then disconnect the observer. That pattern matches how production RUM libraries avoid reporting a mid-load candidate as the permanent LCP. Feature-detect with PerformanceObserver.supportedEntryTypes.includes('largest-contentful-paint') so older Safari builds stay quiet instead of throwing.

Use Web Inspector’s Layout and Rendering timeline to confirm the element you think is LCP is the one Safari records. Agencies often discover that a cookie banner, carousels, or a late web font swap changes the LCP element on iOS even when Chrome’s lab run pointed at the hero image. Fix the template once you see the Safari element; do not argue from a single Chrome Lighthouse screenshot alone.

How to measure INP in Safari with the Event Timing API

INP is not a single Event Timing entry. You observe event entries (with interactionId where available), keep the interaction latencies that matter, and apply the INP selection rules across the page lifetime. Safari 26.2’s Event Timing support is what makes that pipeline possible in WebKit. A minimal observer looks like this:

const eventObserver = new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.interactionId) continue;
    console.log('Interaction', {
      name: entry.name,
      duration: entry.duration,
      startTime: entry.startTime,
      interactionId: entry.interactionId,
    });
  }
});
eventObserver.observe({ type: 'event', buffered: true, durationThreshold: 16 });

Lower durationThreshold (for example 1) if you are debugging and need more events. Production pipelines usually keep a higher threshold and let a library compute INP so you do not re-implement selection logic incorrectly. Finalise INP when the page is hidden, because the metric can improve or worsen as the user keeps interacting.

Treat early Safari INP numbers with care. DebugBear notes that Safari’s INP implementation has had cases of unreasonably high scores while the engine settles. Segment by browser family before you tell a client that “INP exploded on iPhone.” Confirm the Safari version share in your analytics, re-check on a physical device, and compare against Chrome INP for the same URL template.

How to collect Safari LCP and INP with web-vitals.js

For most sites, Google’s web-vitals library is the safer path than hand-rolled observers. It handles buffering, attribution helpers, and finalisation when the page is hidden. After Safari gained the underlying APIs, the same onLCP and onINP callbacks can receive Safari sessions once those users are on 26.2 or later.

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  navigator.sendBeacon('/rum', JSON.stringify(metric));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Ask your RUM vendor whether Safari LCP and INP are already flowing, or whether you need a library upgrade. Shopify’s performance team warned store owners that dashboards can shift once Safari data arrives, and that prior “Safari” LCP or INP rows in some tools were not true Safari field samples. Establish browser-family baselines before you treat a combined p75 as gospel.

Keep CLS in the pipeline where your stack supports it, and label browser coverage in client decks. CLS support is still uneven compared with LCP and INP across engines. A Safari-heavy site can look healthy on LCP while layout shift problems remain visible mainly in Chromium field data.

What still only Chrome reports (CrUX, Search Console, PageSpeed Insights field)

Safari RUM and Google’s public field panels are not the same system. CrUX, the Chrome User Experience Report, remains a Chrome-user sample. Search Console’s Core Web Vitals report and the field block in PageSpeed Insights draw on that CrUX world. Turning on Safari observers does not fill those Google UIs with iPhone percentiles.

Source	What you get after Safari 26.2	Still Chrome-skewed?
First-party RUM / `web-vitals` / vendor RUM	LCP and INP from Safari 26.2+ users when instrumented	No, if you segment by browser
CrUX (origin or URL)	Real-user Chrome percentiles	Yes
Search Console CWV report	Field issues from CrUX	Yes
PageSpeed Insights field section	CrUX slices beside lab	Yes for field; lab is synthetic
Scheduled Lighthouse / PageSpeed Insights lab	Controlled lab run on a listed URL	Lab is not Safari field

That split is why agencies still need both layers. Safari RUM answers “how do our iOS users experience this template?” Chrome field tools answer “what does Google’s Chrome-based field sample say for ranking and Search Console?” Scheduled lab runs answer “did yesterday’s deploy regress the URL we listed?” Confusing any two of those produces the same failure mode as treating a missing CrUX row as proof the page has no CLS. We covered missing field rows in When PageSpeed Insights shows no CLS or INP.

Why Safari and Chrome LCP timings can differ slightly

Even when both browsers expose LCP, the clocks are not identical down to the millisecond. web.dev explains that Chrome has historically included a later presentationTime in LCP, while Firefox and Safari stop at an earlier paintTime. The difference is usually small, but it is enough to create noisy comparisons if you merge browser families into one percentile without labelling the engine. Chrome has been exposing more comparable paint timing for cross-browser work; still segment reports by browser until your tooling documents like-for-like fields.

Expect distribution shifts when Safari volume turns on in RUM. Some teams see slower Safari LCP than Chrome on the same URL; others see the opposite. Image decoding, font loading, and main-thread contention differ by engine and device. Use the new visibility to find Safari-specific issues (lazy-loaded LCP images, large hero assets on cellular, third-party scripts that hurt INP on iOS). Do not panic-rewrite the entire stack because a combined dashboard moved after Safari data landed.

Agency checklist: segment Safari RUM beside Chrome lab and CrUX

Confirm Safari version share in analytics for priority clients (especially education, consumer, and US mobile-heavy brands).
Upgrade or verify RUM so web-vitals or your vendor actually receives Safari LCP and INP.
Baseline by browser family for two to four weeks before rewriting client SLAs.
Keep CrUX and Search Console as the Chrome field story for SEO conversations.
Keep scheduled lab tests on money URLs for deploy regression, independent of Safari RUM noise.
Document the stack in the monthly deck: Safari RUM for iOS experience, CrUX for Google field, lab for release confidence.
Re-test INP outliers on device before escalating Safari INP spikes to engineering as production incidents.

For journey-heavy products (enrolment, lessons, checkout), map which steps matter on iPhone first. Our EdTech performance monitoring guide is a useful pattern even outside education: measure the stages users feel, not only the marketing homepage. The same habit applies to SaaS onboarding and ecommerce checkout when Safari share is material.

Where Apogee Watcher fits after Safari starts reporting LCP and INP

Apogee Watcher runs scheduled PageSpeed Insights tests across multi-tenant portfolios: discovery, mobile and desktop strategies, budgets, alerts, and client-ready trends. Those runs give you lab metrics plus CrUX field slices when Google has enough Chrome sample for the URL or origin. Watcher does not inject a Safari RUM snippet, and it does not claim Safari LCP or INP inside the product UI.

That boundary is deliberate. Safari field collection belongs in your RUM or first-party web-vitals pipeline. Watcher stays on the deploy and portfolio side: catch regressions on listed URLs after theme, tag, or CDN changes, while Safari RUM tells you whether iOS users improved after the fix. Layer the two. Do not rip out Chrome field reporting, and do not pretend a lab score is a Safari percentile.

If you need the wider lab versus field decision tree, see synthetic versus real user monitoring and PageSpeed Insights versus automated monitoring. Soft navigations and SPA route measurement remain a separate Chromium-led topic. Scheduled PageSpeed Insights still measures full document loads of the URLs you list, as we described for Chrome 151 soft navigations.

Start a free trial to schedule PageSpeed tests and budgets across client sites while you instrument Safari RUM for iOS-heavy accounts. Or run a free PageSpeed check on a priority URL before you change reporting templates.

FAQ

Does Safari 26.2 mean CrUX now includes iPhone users?

No. CrUX remains a Chrome user experience sample. Safari 26.2 lets your own RUM or analytics read LCP and INP from Safari sessions. It does not rewrite Search Console or PageSpeed Insights field panels into multi-engine field data.

Is CLS now available in Safari the same way as LCP and INP?

Do not assume parity. This release is about Largest Contentful Paint and Event Timing for INP. Check your RUM vendor’s browser support table for CLS before you promise Safari layout-shift percentiles in a retainer report.

Should we stop using PageSpeed Insights lab scores?

No. Lab scores remain useful for controlled comparisons after deploys. Pair them with Chrome field data where CrUX exists, and with Safari RUM where iOS traffic matters. Each layer answers a different question.

Why did our RUM LCP get worse after Safari data appeared?

Combined percentiles often move when a new browser family joins the sample. Segment by Safari versus Chrome, confirm users are on 26.2+, and inspect the LCP element on a real iPhone before you treat the shift as a pure regression from your last release.

Can Apogee Watcher show Safari LCP and INP today?

No. Watcher stores scheduled PageSpeed Insights lab results and available CrUX field slices for the URLs you monitor. Use RUM or web-vitals for Safari field collection, and Watcher for portfolio lab cadence and alerts.