Backdrop-filter blur performance

2025-12-19 09:02 UTC gpt-5-2 Open in ChatGPT ↗

What actually costs time with `backdrop-filter: blur(...)` (today)

A backdrop-filter blur is not “just a bit of GPU magic on top of a solid layer”. Engines generally have to:

Identify the backdrop region covered by your element plus an expansion margin (because blur samples pixels outside the element bounds).
Render / fetch those pixels into an offscreen surface (often a texture).
Run the blur (typically separable Gaussian-style passes, frequently with downsampling for large radii).
Composite the blurred result back under your element’s contents.

On a sticky/fixed navbar while the page scrolls, step (1)–(4) effectively happens every frame because the pixels “behind” the bar change continuously as content moves. That’s why the “it only recomputes when the background changes” line is misleading in practice: scrolling is a continuous background change.

Also, there are second-order costs:

Filters can force different text rendering paths (e.g., subpixel AA may be disabled in some filtered contexts, which has quality and sometimes perf implications). citeturn1search0
The blur needs a larger offscreen area as radius increases (more memory bandwidth, more texture sampling).

About “radius 100px”: two very different meanings

People say “radius 100px” to mean either:

backdrop-filter: blur(100px) (blur radius/amount), or
border-radius: 100px on the navbar shape.

They impact performance differently:

If you mean `blur(100px)` (the expensive case)

100px is huge. Even with downsampling optimizations, the blur tends to become a bandwidth-heavy fullscreen-ish effect for that region because the kernel footprint expands and/or requires multiple passes.
Visually, blur(100px) on a navbar is often indistinguishable from something like blur(16–32px) once you add the usual translucent fill + subtle border. So you’re frequently paying extra for blur you can’t perceive.

If you mean `border-radius: 100px` (pill-shaped navbar)

The rounded clipping itself is usually not the big ticket item.
But rounded corners + backdrop-filter can change how the engine needs to allocate/clip the offscreen surface (more bookkeeping, sometimes extra edge pixels). This is typically minor compared to the blur amount, but it’s not “free”.

Current browser reality (late 2024–2025)

backdrop-filter is now considered “Baseline newly available” as of Sep 2024 (i.e., broadly shipped in modern engines). citeturn0search32
WebKit continues to highlight backdrop-filter as a long-supported feature (Safari has had it for years), but Safari releases still ship regressions around it in real pages. citeturn0search13turn0search9
MDN’s reference is up to date on the API surface, but Safari prefixing / behavioral quirks are still reported in 2025 (notably around -webkit-backdrop-filter behavior). citeturn0search20turn0search21
Firefox: there are longstanding reports/bugs of lagginess in some backdrop-filter scenarios (especially with lots of filtered elements). citeturn1search17

Performance characteristics you should assume (and validate)

For a single navbar blur, the dominant factors are:

Area (in pixels) of the blurred region
- A 64px-tall bar across a 3× DPR mobile screen can be “small in CSS px” but large in device pixels.
Blur amount
- Larger blur → more samples/passes and/or more downsample steps. Past a point, you’re trading quality for speed internally, and results vary by engine/GPU.
Backdrop dynamism
- Scrolling content underneath is basically the worst case: you demand an updated blurred backdrop every frame.
What else is happening
- Video behind the bar, heavy shadows, blending, large sticky elements, etc., compound cost.

Benchmarks / measurements that exist publicly (and how to interpret them)

There aren’t great standardized cross-browser “blur(100px) navbar” benchmarks published by vendors, but we do have useful field measurements from real projects:

VitePress navbar blur: an issue report measured that disabling backdrop-filter improved framerate by “almost 30%” in Chrome DevTools on scroll. That’s not a lab benchmark, but it’s a realistic “docs site + blurred sticky nav” datapoint. citeturn1search12
Older but still directionally correct reports show double-digit FPS drops with blur filters when the effect is visible and updating (especially during scroll). Treat the numbers as workload-specific, not universal. citeturn0search5

What you should not take from these:

“Backdrop blur always costs 30%.” (No.)
“It’s fine on any modern GPU.” (Also no—bandwidth, DPR, and continuous updates matter more than raw shader throughput.)

If you care about scroll smoothness on mid/low devices, this is the playbook that tends to hold up:

Use the smallest blur that achieves the look
- Start around blur(8px)–blur(20px). Jumping to 100px is rarely perceptible once you tune translucency and add a border.
Keep the blurred area small
- Don’t blur the entire header container if only the bar needs it.
- Avoid extra padding/margins that expand the region.
Avoid animating the filter
- Animating blur radius forces continual re-evaluation and often defeats caching.
Prefer opacity + subtle noise/border over “more blur”
- A slightly more opaque background + 1px border often reads as “frosted” with far less blur.
Be careful with “just add will-change”
- Promoting layers can help or hurt (memory pressure → worse jank). Measure, don’t cargo-cult.
Have a fallback for constrained environments
- Feature-detect and/or offer a reduced-motion / reduced-transparency mode (or use a solid/semi-opaque background) for users/devices that struggle.

How to measure it correctly (so you don’t repeat misconceptions)

For Chrome/Edge:

Use Performance panel while doing a steady scroll:
- Look for Compositor / GPU raster workload spikes.
- Check if the navbar triggers large “Paint” or “CompositeLayers” costs.
Use Rendering → FPS meter and Paint flashing to confirm whether you’re forcing repaints vs mostly compositing.
Compare:
1. no blur, 2) blur(12px), 3) blur(100px) (same opacity), same page, same device.

For Safari:

Test on real iOS hardware, not just desktop Safari. Safari has had real-world regressions/quirks around backdrop-filter interactions. citeturn0search9turn0search21

For Firefox:

If Firefox behavior is a target, test scenarios with and without blur; there are known lag reports in some backdrop-filter cases. citeturn1search17

If you tell me whether you meant blur(100px) or border-radius: 100px, and what your target devices are (desktop only vs iOS/Android), I can give a more opinionated recommendation (including what I’d ship by default and what I’d gate behind a preference/media query).

Mostly, yes — modern iPhones and Apple-silicon Macs can handle a single blurred navbar “fine” if the blur is in a sane range and the blurred area is small. But “blur(100px) on a sticky nav while scrolling” is still a real performance footgun in some cases, even on high-end Apple hardware.

Here’s the honest version.

On modern iPhones (Safari / WKWebView)

A single frosted navbar with backdrop-filter: blur(8–24px) + translucent fill is usually OK.
With blur(100px), you’re much more likely to hit:
- higher GPU bandwidth cost per frame (large-radius blur is expensive by design),
- scroll hitching on heavier pages (images, shadows, large DOM, video),
- battery/thermal throttling if the effect stays on-screen during lots of interaction.

Also: iOS is effectively “Safari engine everywhere” (WebKit). So you can’t escape engine behavior by telling users to “use Chrome” on iPhone.

On Apple-silicon Macs (Safari / Chromium)

Apple Silicon has plenty of GPU, and desktop can brute-force more.
But the same principle applies: backdrop-filter has to re-sample the pixels behind the bar as you scroll, and that can show up as reduced FPS on large/high-DPI displays or content-heavy pages.
Real-world reports regularly show noticeable scroll improvement when backdrop-filter is removed from a sticky navbar (example: VitePress report measuring ~30% FPS improvement when disabling it). citeturn0search4

Why “100px blur” is the risky part (even on fast devices)

Backdrop blur isn’t a cheap “post-process”; it typically implies an extra rendering pass of the backdrop region and then the blur/composite work. The FXTF discussion notes this separate pass is inherently expensive. citeturn0search19
And because a sticky navbar’s backdrop changes during scroll, you’re often paying that cost every frame.

What I’d ship

Default: backdrop-filter: blur(12px) or 16px + background-color: rgba(..., 0.6–0.9) + 1px border.
Avoid: blur(100px) on a scrolling/sticky surface unless you’ve profiled it on your actual worst-case pages and devices.
Add a “reduced transparency” mode (or gate the blur) because backdrop-filter can harm performance; even Google’s own guidance is basically “test before deploying.” citeturn0search11

If you want, paste your navbar CSS + typical page complexity (hero images? video? parallax?) and I’ll tell you where the hidden multipliers are and how to get 90% of the look for a fraction of the cost.

You can’t reliably detect “low-end device” on the web in a way that’s both accurate and future-proof. What you can do is gate blur by (a) explicit user prefs, (b) known capability hints where available, and (c) a runtime performance probe—and always provide an opt-out.

Here are the approaches that actually work in 2025, in descending order of sanity.

1) Gate by user preference (best signal)

`prefers-reduced-transparency`

This is the closest thing to “don’t do frosted glass” the platform has. It’s now a real media query and increasingly supported. citeturn0search2turn0search6turn0search10

.nav {
  background: color-mix(in srgb, Canvas 70%, transparent);
  -webkit-backdrop-filter: blur(16px);
  backdrop-filter: blur(16px);
}

@media (prefers-reduced-transparency: reduce) {
  .nav {
    -webkit-backdrop-filter: none;
    backdrop-filter: none;
    background: Canvas; /* or a near-opaque token */
  }
}

Also consider prefers-reduced-motion: reduce as a secondary hint (not equivalent, but often correlated with “avoid heavy effects”).

2) Gate by “capability hints” (useful, but patchy)

`navigator.deviceMemory` (Chromium only)

This is not available on Safari (and not Baseline). citeturn0search0turn0search16
So it won’t help for iPhones/iOS Safari, but it can help on low-end Android/Chromebooks.

`navigator.connection.saveData` (not widely available; notably missing in Safari)

The Network Information API is “limited availability” and WebKit has an open feature request around saveData. citeturn0search1turn0search9turn0search17

`navigator.hardwareConcurrency` (available on modern Safari)

This one is supported in Safari (Apple documents it), so you can use it as a weak heuristic. citeturn0search11turn0search7turn0search3

Example heuristic (don’t treat as truth; treat as “maybe be conservative”):

function shouldDisableBlurByHints() {
  // Respect explicit user pref first (handled in CSS above).
  // Now apply coarse hints where present.

  // Chromium-only
  const mem = navigator.deviceMemory; // undefined on Safari
  if (typeof mem === "number" && mem <= 2) return true;

  // Weak signal; iPhones are usually >=6 cores these days, but don't assume.
  const cores = navigator.hardwareConcurrency;
  if (typeof cores === "number" && cores <= 4) return true;

  // Network hints (often undefined on Safari)
  const conn = navigator.connection;
  if (conn?.saveData) return true;

  return false;
}

3) Gate by measured performance (most honest for “low-end”)

If your concern is “does blur cause scroll jank on this device on this page?”, measure it.

A simple, practical strategy:

Enable blur by default.
On first interaction (or after a short sample), run a requestAnimationFrame FPS probe while the user scrolls, and if it’s consistently bad, disable blur for that session (or remember the choice).

Minimal version (session-only):

const root = document.documentElement;

function setBlurEnabled(enabled) {
  root.classList.toggle("no-blur", !enabled);
}

if (shouldDisableBlurByHints()) setBlurEnabled(false);

// Optional: runtime probe
let samples = 0, bad = 0;
let last = performance.now();

function tick(now) {
  const dt = now - last;
  last = now;

  // ~60fps => 16.7ms; treat sustained >24ms as trouble (tune to your UX)
  if (dt > 24) bad++;
  samples++;

  if (samples < 120) {
    requestAnimationFrame(tick);
  } else {
    // If >20% of frames were "slow", disable blur
    if (bad / samples > 0.2) setBlurEnabled(false);
  }
}

requestAnimationFrame(tick);

And the CSS toggle:

.no-blur .nav {
  -webkit-backdrop-filter: none;
  backdrop-filter: none;
  background: Canvas;
}

This avoids guessing “low-end” and instead answers “is this effect harming this user right now?”

What I’d avoid

UA sniffing for “old iPhone models” (fragile, and you’ll still be wrong on thermal/battery states).
Assuming “modern iPhones are always fine” (they often are, until the page is heavy or you pick huge blur radii like 100px).

If you’re serious about gating, the simplest robust policy is:

Default blur to ~12–20px, not 100px.
Disable blur on prefers-reduced-transparency: reduce. citeturn0search2turn0search6
Optional: run the short FPS probe and disable if it’s janky.

If you paste your navbar CSS and whether it’s position: sticky or fixed and its height, I can suggest a “looks the same, costs less” set of values and structure.