How can you measure Core Web Vitals on Firefox and Safari without native API support?

Why do certain browsers still block Core Web Vitals APIs?

Firefox and Safari have yet to natively integrate the APIs that measure LCP, FID, and CLS on the client side. This stance is not due to technical reasons but political factors: both vendors believe these metrics favor the Google ecosystem.

In concrete terms, if you rely solely on traditional JavaScript RUM (Real User Monitoring), you miss out on 25 to 35% of your actual user data depending on your audience. This represents a significant analytical black hole considering that Safari dominates mobile in the US with nearly 50% market share.

What exactly are frame timings and why 60 fps?

Frame timings measure the time it takes for the browser to calculate and render each frame. The 60 fps target corresponds to a frame every 16.67 ms — the threshold below which the human eye perceives perfect fluidity.

When your main thread is blocked by heavy JavaScript or the GPU struggles with complex CSS animations, the frame rate drops. This signal is much more direct than attempting to reconstruct an equivalent CLS or FID on these browsers. You measure the direct impact felt by the user.

Are lab data reliable enough to replace RUM?

No, and Martin Splitt is not saying that. Lab data (DevTools, Lighthouse) provide a technical baseline: under controlled conditions, does your site hold up? But they do not replace real-world conditions: unstable 3G connections, low mobile CPU, browser extensions.

The recommended approach here is a tactical compromise: since it is not possible to measure native CWV on Firefox/Safari in RUM, use DevTools to identify structural bottlenecks. Then cross-reference with your Chrome RUM data to extrapolate. It’s not ideal, but it’s better than nothing.

• Firefox and Safari represent ~30% of global web traffic, which cannot be ignored in SEO
• Frame timings provide a reliable proxy for perceived smoothness, even without CWV APIs
• Lab data complement RUM but do not replace it — they can identify structural issues, not actual user friction
• Systematically monitor performance across all browsers, not just Chrome, to avoid critical blind spots

Is this recommendation truly actionable for an SEO practitioner?

Let's be honest: Martin Splitt is primarily addressing front-end developers rather than SEOs here. Opening Firefox’s DevTools to analyze frame timings is not a daily task for most SEO professionals, even seniors.

The advice remains valid in principle — frame timings are a great indicator of perceived performance — but it lacks a layer of tooling. How many SEOs know how to interpret a timeline profiler or identify that a drop to 45 fps is due to CSS reflow rather than a third-party script? [To be verified]: The lack of guidance on automation tools (Selenium scripts, CI/CD with lighthouse-ci) limits practical applicability.

Is targeting 60 fps coherent with Core Web Vitals thresholds?

Not directly. The official CWV do not measure frame rate: LCP targets 2.5s, FID 100ms, CLS 0.1. Aiming for 60 fps is a heuristic for overall smoothness, relevant for user experience but does not mechanically translate into a good CWV score.

For instance, you could have a site consistently at 60 fps but a catastrophic LCP of 4s because your hero image is 3 MB. Conversely, a site with excellent LCP can experience micro-stutters at 45 fps while scrolling, which can negatively affect user perception without impacting official metrics. The two approaches are complementary, not interchangeable.

What is the limit of this approach on mobile Safari?

Mobile Safari imposes specific constraints: aggressive background CPU throttling, strict memory management, historical CSS bugs (notably on transform animations). Measuring in a lab on a MacBook Pro does not reflect what happens on an iPhone 12 in real-world conditions.

Moreover, Safari blocks many profiling APIs for privacy reasons (limited User Timing API, no Long Tasks API). As a result, even if you want to apply Splitt's recommendation, you encounter technical impossibilities. The only true solution remains real device testing via BrowserStack or equivalent, which adds complexity and cost.

How can you effectively collect frame timings without native APIs?

The manual method via DevTools works for occasional debugging, not for continuous monitoring. Open the Performance tab on Firefox/Safari, record a typical browsing session (scrolling, clicks, interactions), then analyze the flame chart to identify frames that exceed 16.67 ms.

To automate, use Lighthouse in navigation mode on Firefox via Playwright or Puppeteer (which has supported Gecko since 2023). Set up CI/CD tests that run across multiple rendering engines. Tools like SpeedCurve or Calibre can monitor cross-browser, but at a non-negligible monthly cost.

What are the typical bottlenecks that interrupt 60 fps?

Forced reflows (layout thrashing) top the list: reading then modifying a geometric property in a JavaScript loop forces the browser to recalculate the layout on every iteration. A classic example: animating an element's height with JavaScript instead of using transform: scaleY().

Non-composited CSS animations are another pitfall: animating width, height, top, left triggers costly repaints. Stick to transform and opacity, the only properties GPU-accelerated across all browsers. Finally, third-party scripts (analytics, ads, chat) frequently block the main thread — audit them ruthlessly.

Is it really necessary to optimize for Firefox and Safari if Google is not crawling them?

Google crawls and indexes using Chromium/Blink, that's a fact. But the Core Web Vitals used for ranking come from the Chrome User Experience Report (CrUX), which aggregates real user data from Chrome only. So technically, a slow site on Safari does not directly affect your SEO.

However — and this is where it becomes critical — a sluggish site on Safari leads to bounces, less engagement, fewer conversions. These indirect behavioral signals influence your ranking through other mechanisms (organic CTR, return rates, potential dwell time). Ignoring 30% of your audience to scrape 2 points of CWV on Chrome is a short-sighted strategy.

• Set up automated Lighthouse tests on Firefox and Safari using Playwright in your CI/CD pipeline
• Systematically audit CSS animations: use only transform and opacity to ensure cross-browser smoothness
• Deploy paid cross-browser monitoring (SpeedCurve, Calibre, WebPageTest) if your Safari/Firefox traffic exceeds 20%
• Manually measure frame timings via DevTools on real devices (iPhone, iPad) at least quarterly
• Cross-reference your CrUX data (Chrome RUM) with your behavioral analytics (GA4) to identify cross-browser performance gaps
• Prioritize optimizations that benefit all engines: image compression, lazy loading, JS reduction, aggressive caching