The 90 % CPU bug in our Cinema Web: how React Three Fiber grilled our landing page
Chrome's task manager showed 87 % CPU on an Intel i7 laptop as soon as zer0onelab.com was in a tab. Not 87 % peak. 87 % steady state. We thought it was the post-processing bloom. It was the DPR setting combined with a missing GPU tier detection.
Škomi's screenshot on 2026-07-04, morning: Chrome task manager showed the zer0onelab.com tab at 87 % CPU. Steady state, not a scroll-triggered peak. The laptop is a standard Intel i7 business notebook with integrated HD 620 GPU — exactly the target group for our B2B cold-outreach campaign.
The landing page had a React Three Fiber canvas in the hero section with an RS6 3D model auto-turntable, bloom post-processing, environment-map reflections, and a DPR range of [1, 1.5]. Looked impressive on a MacBook Pro M3. On an Intel HD 620, less impressive.
What didn't work first
First suspect: post-processing. Bloom + vignette are expensive. Disabled bloom — CPU dropped from 87 % to 82 %. Five percentage points is plausible but not the root.
Second suspect: model poly count. Reduced RS6 from 293k to 148k tris. CPU 82 % → 79 %. Plausible, not the root.
Third suspect: environment map. Disabled. CPU 79 % → 74 %. Contributed, still 30 % above the 40 % budget target.
The actual root cause
The bug was in GPU tier detection. We had a detectGPUTier() call that behaved identically on every machine — it never decided "low tier, skip the whole scene". It always decided "mount the scene, use DPR 1.5". On a MacBook M3 that renders at ~5 % CPU. On an Intel HD 620 at ~87 %.
The fix:
const tier = detectGPUTier();
if (tier === "low") {
return <StaticFallback />; // pure CSS + video loop
}
Plus DPR from [1, 1.5] to [1, 1] for mid-tier devices. Plus IntersectionObserver that fully unmounts the scene when the canvas isn't visible. Plus VisibilityPause — frame loop stops when the tab is backgrounded.
Result on Intel HD 620: 87 % → 4 %. On MacBook M3: 5 % → 3 %. The fix helps everyone.
Why we missed it
We developed only on Macs. Škomi's notebook is the only regularly tested Intel iGPU machine in our test matrix. The bug was there the whole time — we didn't see it because our development machines didn't trigger it.
The lesson: web 3D performance is a multi-device problem, not a single-machine problem. A feature that runs at 5 % CPU on a MacBook M3 can run at 90 % on an HD 620 notebook. Both machines are valid target audience for a B2B landing page.
Our rules now
- For every R3F element:
detectGPUTier()first. If low, skip entirely. - DPR never > 1 by default.
- IntersectionObserver on all canvas elements.
- VisibilityPause always on.
- Testing pipeline includes an iGPU reference machine.
Meta-lesson
Impressive-looking 3D web content is a trade-off, not a wow feature. The trade-off is always: which device class of your target group does it exclude? We spent four weeks welcoming ~30 % of our B2B target (enterprise notebook users) with an 87 %-CPU experience. That's not "impressive", it's "sold below value".
If you use R3F on a landing page, test on Intel iGPUs. If you don't have one: RTX 3050 is a good mid-tier baseline — what runs at 20 % CPU on a 3050 runs at 40–60 % on an HD 620.