Il bug della CPU al 90 % nel nostro Cinema Web: come React Three Fiber ha grigliato la nostra landing page

Lo screenshot di Škomi del 2026-07-04, mattina: il task manager di Chrome mostrava il tab di zer0onelab.com al 87 % di CPU. Steady state, non un picco durante lo scroll. Il laptop è un normale business notebook Intel i7 con GPU integrata HD 620 — esattamente il target group della nostra campagna B2B di cold-outreach.

La landing page aveva nella sezione hero un canvas React Three Fiber con un modello 3D dell’RS6 (auto-turntable), Bloom di post-processing, riflessioni EnvironmentMap e un DPR range di `[1, 1.5]`. Faceva colpo. Su un MacBook Pro M3. Su un’Intel HD 620: colpo minore.

Cosa non ha funzionato all’inizio

Primo sospettato: il post-processing. Bloom + Vignette + DPI-Scale sono costosi. Abbiamo disattivato il Bloom — la CPU è scesa dall’87 % al 82 %. Cinque punti percentuali per il Bloom su un’HD 620 sono assolutamente plausibili, ma ovviamente non risolvono il problema.

Secondo sospettato: il poly-count del modello. Abbiamo ridotto il modello RS6 da 293k a 148k tris. La CPU è scesa dall’82 % al 79 %. Di nuovo plausibile, ma il problema di fondo resta irrisolto.

Terzo sospettato: la EnvironmentMap. Disattivata. CPU al 74 %. Anche questo ha contribuito — ma eravamo ancora 30 punti sopra il budget target del 40 %.

La vera root cause

Il bug era nella GPU-Tier-Detection. Avevamo una chiamata a `detectGPUTier()` che si comportava allo stesso modo su tutte le macchine — non decideva mai „low-tier, skip the whole scene“. Decideva sempre „mount the scene, use DPR 1.5“. Su un MacBook M3 questo renderizza a ~5 % di CPU. Su un’Intel HD 620 al ~87 %.

Il fix in `src/components/lab-hero-r3f/index.tsx`:

```tsx const tier = detectGPUTier(); if (tier === "low") { return <StaticFallback />; // solo CSS + video loop } ```

In più: DPR abbassato da `[1, 1.5]` a `[1, 1]` per i dispositivi mid-tier. In più: un IntersectionObserver che smonta completamente la scena quando il canvas non è visibile. In più: `VisibilityPause` — il frame-loop si ferma quando il tab è in background.

Risultato su Intel HD 620: 87 % → 4 %. Su un MacBook M3: 5 % → 3 %. Il fix aiuta tutti — gli utenti con GPU discreta non perdono qualità visiva, gli utenti iGPU ottengono un sito che funziona.

Perché non l’abbiamo visto prima

In fase di sviluppo lavoravamo solo su Mac. Il notebook di Škomi è l’unica macchina Intel iGPU testata regolarmente nella nostra matrice di test. Il bug era lì da sempre — non l’abbiamo visto perché le nostre development machines non lo triggeravano.

La lezione: la performance del 3D web è un problema multi-device, non un problema di singola macchina. Una feature che gira al 5 % di CPU su un MacBook M3 può girare al 90 % su un notebook HD 620. Entrambe le macchine sono target legittimo per una landing page B2B.

Le regole che applichiamo ora

1. Per ogni elemento R3F: prima `detectGPUTier()`. Se low, skip completo.
2. DPR mai sopra 1 di default. Se un cliente vuole un’esperienza high-DPR, può attivarla manualmente.
3. IntersectionObserver su tutti gli elementi canvas. Nessun rendering per elementi non visibili.
4. VisibilityPause sempre attivo. Il frame-loop si ferma quando document.visibilityState === "hidden".
5. La pipeline di test include ora una macchina di riferimento iGPU (notebook Intel HD 620). Nessun deploy esce se la CPU della macchina di riferimento è sopra il 15 % a idle.

Meta-lezione

Il contenuto 3D web „impressive-looking“ è un trade-off, non una wow-feature. Il trade-off è sempre: quale classe di dispositivi del tuo target viene esclusa? Per 4 settimane abbiamo accolto ~30 % del nostro target B2B (utenti di notebook enterprise) con un’esperienza al 87 % di CPU. Non è „impressive“, è „venduto sotto valore“.

Se usi R3F su una landing page, testa obbligatoriamente su Intel iGPU. Se non ne hai una: la RTX 3050 è un buon candidato baseline per „mid-tier“ — ciò che gira al 20 % di CPU su una 3050, gira al 40–60 % su un’HD 620. Ciò che gira sotto il 10 % su una 3050, è safe per tutti i business notebook standard.

Il fix è documentato nel repository e live su zer0onelab.com. Il perf-fix brief fa parte delle nostre 3D-Rendering-Rules in LEKTIONEN-3D.md.