perf(nav): drop the backdrop-blur behind the sticky header (scroll jank) - #175
Merged
Conversation
Scrolling in the desktop app was painful while the app sat at 0% CPU when idle - the cost was entirely per-frame, and only while the view moved. The header is `sticky top-0` and carried `backdrop-blur-xl` over a 55%-opaque background. A backdrop-filter has to sample whatever is behind the element and blur it; because the header is sticky, "whatever is behind it" is different on every scroll frame. So the browser re-sampled and re-blurred the full width of the viewport ~60 times a second, at Tailwind's largest radius. On a 3840x2160 display that is a lot of pixels, and WebKitGTK - which is what the desktop app renders with, since the AppImage is a shell over the site - is substantially slower at backdrop-filter than Chromium. Replaced with an opaque background. On a dark theme the two are nearly indistinguishable, and the per-frame cost goes to zero. Also dropped the blur on the nav dropdown: its background was already bg-card/95, so the filter bought almost nothing visually while still forcing a filtered layer. It sits over static content anyway, so it was never the scroll problem. The other 23 backdrop-blur uses are on ordinary cards that do not sit over moving content, and are left alone - blur is not the problem, blur over a scrolling backdrop is. Verified: tsc clean, 673 tests, eslint clean, next build succeeds.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scrolling in the desktop app was painful while the app measured 0% CPU at idle — the entire cost was per-frame, and only while the view moved. That shape is what pointed here.
The header is
sticky top-0and carriedbackdrop-blur-xlover a 55%-opaque background. A backdrop-filter samples whatever sits behind the element and blurs it — and because the header is sticky, what's behind it changes on every scroll frame. So the browser re-sampled and re-blurred the full viewport width ~60×/second at Tailwind's largest radius (24px).At 3840×2160 that's a lot of pixels, and WebKitGTK is substantially slower at backdrop-filter than Chromium — which matters because the AppImage is a shell over this site, so the desktop app renders with WebKit, not Chrome.
Replaced with an opaque background. On the dark theme the two are near-indistinguishable; the per-frame cost goes to zero.
Also dropped the blur on the nav dropdown — its background was already
bg-card/95, so the filter bought almost nothing visually while still forcing a filtered layer. It sits over static content, so it was never part of the scroll problem.Left alone: the other 23
backdrop-bluruses. They're on ordinary cards that don't sit over moving content. Blur isn't the problem — blur over a scrolling backdrop is.Verified:
tscclean · 673 tests · eslint clean ·next buildsucceeds.