/** * Stops hidden overlays blurring the screen. * * THE PROBLEM * A full-viewport `backdrop-filter: blur()` is among the most expensive things * a page can ask for: on every frame the compositor snapshots everything behind * the layer and gaussian-blurs it. Hiding such a layer with opacity, or by * sliding it off-screen, does NOT stop that — the element stays in the render * tree and keeps paying the cost while completely invisible. * * This site hid overlays both ways, so the browser was continuously blurring * copies of the viewport nobody could see: twelve of them on the admin panel, * four on the services page, and the mobile menu on all six public pages — * including on desktop, where that menu is never opened. * * The symptom is distinctive: data loads fast, then everything *feels* sluggish, * because the work is in the compositor rather than in the network or the * database. * * THE FIX * Switch the blur off while the overlay is hidden. No JavaScript changes are * needed — the existing open/close code already toggles these exact classes, so * opening an overlay stops the rule matching and the blur returns instantly. * * WHAT IS DELIBERATELY NOT TOUCHED * Blurs on genuinely visible elements — the sticky header, frosted cards — keep * working. Rule 1 is scoped to `.inset-0` so it only ever matches full-screen * overlays, never a decorative layer that happens to use `pointer-events-none`. */ /* 1. Overlays hidden with opacity, e.g.
and overlays whose blurred backdrop is a child of that container. */ .pointer-events-none.inset-0[class*="backdrop-blur"], .pointer-events-none.inset-0 [class*="backdrop-blur"] { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* 2. Panels slid off-screen by a transform, e.g. the mobile menu
Off-screen is not hidden: it is still composited, and still blurring. */ [class*="translate-x-full"][class*="backdrop-blur"], [class*="translate-y-full"][class*="backdrop-blur"], [class*="translate-x-full"] [class*="backdrop-blur"], [class*="translate-y-full"] [class*="backdrop-blur"] { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* --------------------------------------------------------------------------- * PART 2 — blur on elements that ARE visible. * * Part 1 above stops hidden overlays blurring. That was real, but it left the * larger cost untouched: `backdrop-filter` on elements the user can actually * see. A visible backdrop-filter is re-evaluated on EVERY frame that anything * moves behind it, so a blurred sticky header or a blurred card makes the whole * page expensive to scroll — which is why data loads fast and scrolling still * feels jumpy. * * MEASURED, not guessed (scratch/measure_jank.js, CPU throttled 4x, 1366x768): * * dropped frames worst frame * treatments, first visit 22 216.7ms * ...with blur disabled 0 16.8ms * admin, schedule tab 12 33.5ms * ...with blur disabled 0 16.8ms * * And the blur was buying almost nothing, because nearly every blurred surface * here sits behind a background that is 60-98% opaque. Screenshot comparison * with blur on vs off: * * treatments page 0.14% of pixels differ * admin dashboard 0.24% of pixels differ * admin schedule 0.33% of pixels differ * * So these rules remove an effect that costs 200ms frames and is very close to * invisible. Nothing else changes: no markup, no classes, no JavaScript. * * Scoped by the BACKGROUND OPACITY rather than switched off globally, so a * genuinely translucent surface that relies on blur keeps it. * ------------------------------------------------------------------------- */ /* 3. Surfaces that are 60% opaque or more — the sticky header (95%), the services-page dialog backdrops (98%), the admin cards (60%) and the admin dialog panels (95%). At these opacities the blur is barely perceptible. */ [class*="bg-background-light/9"], [class*="bg-background-dark/9"], [class*="bg-white/9"], [class*="bg-white/8"], [class*="bg-white/7"], [class*="bg-white/6"] { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* 4. The cookie dialog. It is injected by consent.js with raw CSS rather than utility classes, so none of the rules above can see it — and on a first visit it is the single most expensive thing on the page: a FULL-VIEWPORT blur(8px) with a blur(20px) dialog on top. The panel is 95% opaque, so losing its blur is invisible. NOTE: the overlay is only 40% opaque, so this one rule IS a real (small) visual change — the page behind the cookie dialog is dimmed but no longer blurred. It only ever affects a visitor's FIRST page view. If the blur is wanted back, delete the #yoki-consent-overlay selector on the next line and leave the rest of this file alone. */ #yoki-consent-overlay, #yoki-consent-modal { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* 5. The treatments comparison panel. Its background is only 10% opaque, so unlike the surfaces in rule 3 the blur could in principle show — but it is laid over a flat background colour, and blurring a flat colour produces the same flat colour. Measured on the element itself: max channel delta 9 of a possible 765, and NO pixel changed by a visible amount. It is 1184x450, so it was being re-blurred across half the viewport on every scroll frame for nothing. */ [class*="bg-yoki-beige/10"], [class*="bg-yoki-slate/10"] { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; }