fix(gallery): stop cloning hidden magazine variants (10 imgs -> 2292 DOM nodes)#102
fix(gallery): stop cloning hidden magazine variants (10 imgs -> 2292 DOM nodes)#102fabiodalez-dev wants to merge 1 commit into
Conversation
The magazine layout renders all three responsive variants (mobile/tablet/ desktop) server-side; CSS shows one at a time. The runtime marquee filler ensureTrackFill() was invoked for every variant, and the call-sites' `|| window.innerHeight` fallback meant a hidden variant (clientHeight 0) was still filled to a phantom viewport-tall target — cloning cells for the two variants the user never sees. Effect on a 10-image album: the live DOM exploded to ~2292 image links / 4.7 MB (server HTML was only ~140 / 544 KB — the bloat was entirely client-side cloning of hidden tracks). Fix: skip ensureTrackFill when the track is not rendered (offsetParent === null, true under display:none). One guard covering all four call-sites. The visible variant is still filled to colHeight*2 so the seamless marquee loop is intact. Verified in-browser (template=3): 2292 -> 132 nodes (-94%), 4.7 MB -> ~290 KB, marquee still loops at desktop (1200px) and mobile (390px), 0 console errors. Shared runtime, so home benefits too.
|
Warning Review limit reached
More reviews will be available in 20 minutes and 58 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Problem
Template 3 (magazine/marquee layout, also used on home) exploded a 10-image album into 2292 image links / 4.7 MB of live DOM — each photo present ~74–148×. Heavy page, high memory, animation fallback (
gsap-failed).Root cause
The magazine renders all three responsive variants (mobile/tablet/desktop) server-side (~140 links / 544 KB — fine); CSS shows one at a time. The bloat is entirely client-side: the runtime marquee filler
ensureTrackFill()(_gallery_runtime.twig) was run for every variant, and the call-sites'|| window.innerHeightfallback meant a hidden variant (clientHeight === 0) was still filled to a phantom viewport-tall target → cloning cells for the two variants the user never sees.Fix
One guard inside
ensureTrackFill: bail when the track isn't rendered (offsetParent === null, true underdisplay:none). Covers all four call-sites. The visible variant is still filled tocolHeight*2, so the seamless marquee loop is intact.Verification (in-browser,
?template=3)Validated at both desktop (1200px) and mobile (390px) viewports; visible variant fills correctly, hidden variants stay at server base, 0 console errors. Server-rendered HTML unchanged. Shared runtime → home benefits too.