Der 90-Prozent-CPU-Bug in unserem Cinema-Web: Wie React Three Fiber unsere Landing-Page grillte
Chromes Task-Manager zeigte 87 % CPU auf einem Intel-i7-Laptop, sobald zer0onelab.com im Tab war. Nicht 87 % Peak. 87 % Steady State. Wir dachten es liegt am Post-Processing-Bloom. Es lag am DPR-Setting kombiniert mit einer fehlenden GPU-Tier-Detection.
Škomi's Screenshot vom 2026-07-04, morgens: der Chrome-Task-Manager zeigte den Tab von zer0onelab.com auf 87 % CPU. Steady State, nicht ein Peak beim Scrollen. Der Laptop ist ein Standard-Intel-i7-Business-Notebook mit integrierter HD 620 GPU — genau die Zielgruppe unserer B2B-Cold-Outreach-Kampagne.
Die Landing-Page hatte in der Hero-Sektion einen React-Three-Fiber-Canvas mit einem RS6-3D-Modell (Auto-Turntable), Bloom-Post-Processing, EnvironmentMap-Reflections, und einer DPR-Range von [1, 1.5]. Sah beeindruckend aus. Auf einem MacBook Pro M3. Auf einem Intel HD 620: nicht so beeindruckend.
Was zuerst nicht funktioniert hat
Erster Verdacht: Post-Processing. Bloom + Vignette + DPI-Scale sind teuer. Wir haben Bloom deaktiviert — CPU fiel von 87 % auf 82 %. 5 Prozentpunkte für Bloom bei einer HD 620 ist absolut plausibel, aber löst das Problem offensichtlich nicht.
Zweiter Verdacht: Model-Poly-Count. Wir haben das RS6-Modell von 293k auf 148k Tris reduziert. CPU fiel von 82 % auf 79 %. Wieder plausibel, aber Kernproblem nicht gelöst.
Dritter Verdacht: EnvironmentMap. Deaktiviert. CPU auf 74 %. Auch das trug bei — aber wir waren immer noch 30 % über dem Ziel-Budget von 40 %.
Der eigentliche Root Cause
Der Bug lag in der GPU-Tier-Detection. Wir hatten einen detectGPUTier()-Aufruf, der auf allen Rechnern das gleiche Verhalten produzierte — er entschied nie „low-tier, skip the whole scene". Er entschied immer „mount the scene, use DPR 1.5". Auf einem MacBook M3 rendert das mit ~5 % CPU. Auf einer Intel HD 620 mit ~87 %.
Der Fix in src/components/lab-hero-r3f/index.tsx:
const tier = detectGPUTier();
if (tier === "low") {
return <StaticFallback />; // reines CSS + Video-Loop
}
Plus: DPR gesenkt von [1, 1.5] auf [1, 1] für mid-tier Geräte. Plus: IntersectionObserver, der die Scene komplett unmountet wenn der Canvas nicht sichtbar ist. Plus: VisibilityPause — Frame-Loop stoppt wenn der Tab im Background läuft.
Ergebnis auf Intel HD 620: 87 % → 4 %. Auf einem MacBook M3: 5 % → 3 %. Der Fix hilft allen — die Discrete-GPU-User verlieren keine visuelle Qualität, die iGPU-User bekommen eine funktionierende Website.
Warum wir das übersehen haben
Wir haben in der Entwicklung nur auf Macs entwickelt. Škomis Notebook ist der einzige regelmäßig getestete Intel-iGPU-Rechner in unserer Test-Matrix. Der Bug war die ganze Zeit da — wir haben ihn nicht gesehen weil unsere Development-Machines ihn nicht triggerten.
Die Lektion: Web-3D-Performance ist ein Multi-Device-Problem, kein Single-Machine-Problem. Ein Feature das auf einem MacBook M3 mit 5 % CPU läuft kann auf 90 % CPU auf einem HD-620-Notebook laufen. Beide Rechner sind valide Zielgruppe für eine B2B-Landing-Page.
Die Rules die wir jetzt haben
- Für jedes R3F-Element:
detectGPUTier()zuerst. Wenn low, komplett skip. - DPR nie über 1 default. Wenn ein Kunde eine High-DPR-Erfahrung will, kann er sie manuell aktivieren.
- IntersectionObserver für alle Canvas-Elemente. Kein Rendering für Elemente die nicht sichtbar sind.
- VisibilityPause immer aktiv. Frame-Loop stoppt bei document.visibilityState === "hidden".
- Testing-Pipeline enthält jetzt eine iGPU-Referenzmaschine (Intel HD 620 Notebook). Kein Deploy geht raus wenn CPU auf der Referenzmaschine über 15 % im Idle liegt.
Meta-Lektion
Impressive-looking-3D-Web-Content ist ein Trade-off, kein Wow-Feature. Der Trade-off ist immer: welche Geräte-Klasse deiner Zielgruppe wird dadurch aussortiert? Wir haben 4 Wochen lang ~30 % unserer B2B-Zielgruppe (Enterprise-Notebook-Nutzer) mit einer 87 %-CPU-Erfahrung willkommen geheißen. Das ist nicht „Impressive", das ist „unter Wert verkauft".
Wenn du R3F auf einer Landing-Page verwendest, teste zwingend auf Intel iGPUs. Wenn du keine hast: RTX 3050 ist ein guter Baseline-Kandidat für „mid-tier" — was auf einer 3050 auf 20 % CPU läuft, läuft auf einer HD 620 auf 40–60 %. Was auf einer 3050 unter 10 % läuft, ist safe für alle Standard-Business-Notebooks.
Der Fix ist im Code-Repository dokumentiert und live auf zer0onelab.com. Der Perf-Fix-Brief ist Teil unserer 3D-Rendering-Rules in LEKTIONEN-3D.md.
Ähnlicher Brand bei dir?
Wir haben vermutlich schon etwas ähnliches gesehen. Sprich mit uns.
Gespräch starten→