Cross-Browser Performance in 2026: Safari Is No Longer an Excuse

For years, there was a go-to excuse in web performance: "Safari measures it differently." That excuse died in January 2026.

The Safari 26.2 update brought full native support for INP (Interaction to Next Paint), LCP, and CLS — measured with exactly the same standards as Chrome and Firefox. PPC Land confirmed it in their January 2026 analysis: "These additions complete cross-browser support for Core Web Vitals assessment, eliminating measurement gaps that previously prevented accurate performance comparison across Safari, Chrome, and Firefox environments."

DebugBear also documented the shift: Firefox and Safari now support the two remaining Core Web Vitals — INP and LCP — with native APIs. The fragmentation that for years justified performance differences between browsers simply disappeared.

At Mintec, this forced us to rethink how we optimize. Here's what it means and how we're applying it in real projects.

What Actually Changed

Before January 2026, Safari didn't report INP natively. In practice, that meant a site could score an excellent INP in Chrome (say, 150 ms) but deliver a choppy experience on Safari (400 ms+) — and you had no accurate way to measure it. Teams relied on Chrome DevTools and assumed the rest would follow.

The result: sites that passed Core Web Vitals in Lighthouse but offered a stuttering experience on Safari and Firefox.

Today, with cross-browser parity, the equation changed. You can no longer ignore Safari because "its metrics don't count." Now they count exactly the same.

The Number That Should Worry You

According to StackNotice's June 2026 analysis, 43% of websites fail INP — the 200-millisecond threshold Google requires for a good user experience. INP replaced FID in 2024, and the difference is brutal: where FID measured only the first interaction, INP measures the worst interaction of the entire visit (98th percentile).

That means 43 out of every 100 sites have at least one interaction — a click, a tap, a key press — that takes longer than 200 ms to respond. And now Safari reports it exactly like Chrome does.

Tom Brigl summed it up: Apple finally brought real transparency to Core Web Vitals in Safari. There's nowhere to hide.

How It Changed Our Approach at Mintec

Before: We optimized in Chrome, checked Lighthouse, and crossed our fingers for Safari. We used third-party tools with synthetic data that tried to estimate Safari performance, but it was never accurate.

Now: Our workflow has three concrete changes:

1. Real Cross-Browser Testing in CI

Every PR touching interactive components (forms, sliders, modals, menus) runs performance tests on both Chrome and Safari headless. If INP goes above 180 ms in either browser, the PR doesn't pass. This has caught cases where an inefficient event handler in Safari doubled the latency compared to Chrome.

2. Astro 6 as the Default for Content-Driven Sites

In a recent project for a media client with heavy video content, we migrated from Next.js to Astro 6 deployed on Cloudflare Workers. The results were striking:

• LCP dropped from 2.8 s to 0.9 s on Chrome and from 3.4 s to 1.2 s on Safari
• INP held steady at 140 ms across both browsers
• CLS went from 0.18 to 0.02

The main reason: Astro 6 renders HTML on the server and ships zero JavaScript until it's actually needed. Its Server Islands API lets interactive components load lazily without blocking the main thread. Combined with Astro 6's native Content Security Policy API (shipped in May 2026), we can control exactly which scripts run and when.

3. INP Became Our Priority Metric

With cross-browser parity, INP is the most treacherous metric. LCP is relatively straightforward to optimize — server rendering, lazy loading, modern image formats. CLS is solved with explicit dimensions and layout best practices. But INP requires rethinking your interactivity architecture.

Our decision framework now looks like this:

Does the component need client-side JavaScript?

• No → static render in Astro, zero JS. Case closed.
• Yes, but not critical → Server Island with lazy loading. JS loads after paint.
• Yes, and it's critical (forms, search, navigation) → hydrated component with useTransition for update prioritization and scheduler.yield() to yield the main thread.

Choosing the Right Framework

Zorinto's 2026 benchmarks compared SvelteKit (1,200 RPS), Next.js 16 (980 RPS), and Astro 6 (1,050 RPS) on raw throughput. Useful numbers, but they don't tell the whole story.

For mixed-media projects — sites combining content with interactive sections and video — Astro 6 is unbeatable. You can have a video hero as LCP-friendly static HTML, a product carousel as a Server Island, and a contact form as hydrated React, all on the same page, each component loading only what it needs.

What's Next

Cross-browser parity in performance metrics isn't the end of the road. It's the start of an era where excuses no longer work. Google has confirmed that Core Web Vitals remain ranking signals. Now that every browser measures them the same way, there's no dodging the data.

At Mintec, this means we're optimizing with a clarity we didn't have before. When Chrome and Safari report the same INP on the same site, you know the problem is real — not a measurement artifact. And that lets you make architecture decisions on clean data.

If you're considering a stack migration or just want to know where your site is failing on Safari, get in touch for a cross-browser performance audit. We'll show you the numbers others won't.