WebGL o animazioni CSS: quando usare ciascuna (2026)

La scelta tra WebGL e un'animazione CSS si riduce a una domanda: l'effetto ha bisogno della GPU come renderer general-purpose, oppure solo come compositore? Un'animazione CSS passa due o tre proprietà al browser e ottiene i 60fps quasi gratis. Con WebGL prendi in mano la GPU grezza e una canvas vuota, poi costruisci tu la geometria, le luci e il ciclo di rendering. La maggior parte delle interfacce di prodotto non ha mai bisogno della seconda strada.

Questa decisione torna su ogni sito e su ogni dashboard che contiene movimento. Se sbilanci verso WebGL, spedisci un bundle da 600KB e consumi batteria per un fade che il CSS fa in quattro righe. Se sbilanci verso il CSS, passi tre settimane a combattere con il compositore per simulare un campo di particelle che WebGL disegna senza sforzo. Ecco come tracciamo la linea.

La risposta in 30 secondi: chi sceglie cosa

Usa un'animazione CSS quando l'effetto muove elementi del DOM già presenti: fade, slide, scala al passaggio del mouse, uno spinner di caricamento, un menu che si apre, una card che si solleva. Se puoi esprimere il movimento come cambiamento di transform e opacity, il CSS è lo strumento giusto e qualsiasi cosa più pesante è eccesso.

Usa WebGL quando l'effetto è il contenuto, non una decorazione sopra il contenuto: un configuratore 3D di prodotto, un sistema di particelle con migliaia di punti, un effetto fluido o uno shader, una visualizzazione che anima 10.000 nodi, una scena attorno a cui l'utente ruota. Il DOM non riesce a rappresentare queste cose, quindi la domanda se il CSS ce la farebbe non si pone nemmeno.

I casi interessanti stanno in mezzo. È lì che il confronto serve davvero.

WebGL e animazioni CSS a colpo d'occhio

Dove vince l'animazione CSS

Sulla GPU è gratis se resti su transform e opacity

Il browser accelera in hardware qualsiasi transizione o keyframe su transform e opacity, perché queste due proprietà non innescano né layout né repaint. Girano sul thread del compositore, così l'animazione resta fluida anche mentre il tuo JavaScript è occupato. Il team di rendering di Chrome lo documenta senza giri di parole: un'animazione compositata salta del tutto il main thread. MDN dà la stessa indicazione per tutto ciò che è per lo più statico e animato di rado.

Degrada in sicurezza

Un'animazione CSS che il dispositivo non regge semplicemente non si muove. Nessun crash, nessuna canvas bianca, nessun codice di fallback da scrivere. La avvolgi in @media (prefers-reduced-motion: reduce) e rispetta l'impostazione di accessibilità dell'utente in tre righe, senza una riga di JavaScript. È un risparmio reale su accessibilità e manutenzione.

Il modo in cui si rompe è facile da vedere

L'animazione CSS va storta quando animi le proprietà costose: width, height, top, left, margin. Ognuna costringe il browser a ricalcolare il layout a ogni frame, e il frame rate crolla. La soluzione è quasi sempre riscrivere l'effetto con transform. E non coprire lo scatto mettendo will-change ovunque: ogni elemento promosso diventa una texture nella memoria della GPU, e l'abuso crea una pressione sulla memoria che sfratta le texture e genera scatti durante interazioni non collegate. CSS-Tricks tratta will-change come ultima risorsa, limitata al momento subito prima dell'animazione e poi rimossa. Noi facciamo lo stesso.

Dove vince WebGL

Volumi che il DOM non regge

Anima 5.000 nodi del DOM e il browser cede. Un benchmark cross-device dei sistemi di animazione web del 2025 ha trovato WebGL come il più stabile tra 5.000 e 10.000 oggetti, dove DOM e SVG crollano molto prima. Una GPU moderna disegna decine di migliaia di poligoni a 60fps. Se il tuo effetto è uno sciame, un campo o una mesh, WebGL non è l'opzione pesante: è l'unica che gira.

Effetti che esistono solo negli shader

Simulazione di fluidi, displacement, luce per pixel, profondità di campo, rumore procedurale: vivono nei fragment shader e non hanno equivalente CSS. Non li approssimi con transform e opacity, per quanti keyframe impili. Quando il design chiede uno di questi, la scelta è già fatta.

Il costo che accetti

WebGL non è gratis. Three.js aggiunge circa 150KB prima ancora di disegnare un triangolo; usare il WebGLRenderer grezzo al posto della libreria completa taglia quel peso in modo sensibile. Su mobile la vera tassa è il calore: le GPU rallentano per throttling termico sotto carico prolungato, quindi una scena che gira a 60fps nei primi secondi può scendere a 20fps dopo 30. Molte esperienze 3D su mobile limitano di proposito a 30fps per risparmiare batteria, come nota la roadmap di Three.js sul consumo su mobile. Metti a budget un percorso reduced-motion e un'immagine statica di riserva per i dispositivi che quella scena non dovrebbero eseguirla affatto.

La via di mezzo che tutti dimenticano: Canvas 2D e SVG

WebGL e CSS sono i due estremi. Tra loro stanno due strumenti, e saltarli è l'errore più comune che vediamo. Canvas 2D gestisce centinaia di particelle o un pattern generativo senza toccare 3D o shader. SVG anima qualche decina di forme vettoriali con scaling nitido e accesso completo al DOM, così puoi stilizzare e ispezionare ogni nodo. Quando l'effetto è più di quanto il CSS possa reggere ma meno di una scena 3D, di solito la risposta è uno di questi due, e pesa meno che tirare dentro un renderer WebGL. Abbiamo spiegato dove sta ogni libreria nella panoramica sullo stack web immersivo.

Cosa usiamo, e perché

In un progetto SaaS tipico, circa il 95% del movimento è CSS: transform e opacity, guidati dallo stato, nel rispetto di prefers-reduced-motion. Per il movimento legato allo scroll scegliamo una libreria leggera invece di una canvas. Aggiungiamo WebGL solo quando la scena 3D o lo shader sono la cosa per cui l'utente è arrivato, e ogni volta lo spediamo dietro un controllo reduced-motion e un fallback statico. La regola che teniamo: l'asset più pesante che una pagina carica deve rispondere a qualcosa che il visitatore voleva, non a un fronzolo di sfondo. Se basta un fade, vince il fade. Se il prodotto è la scena 3D, paghiamo la tassa di WebGL di proposito e la teniamo fuori dal main thread e fuori dal percorso critico. Sul lato metriche di questo scambio, vedi la nostra guida per portare i Core Web Vitals in verde su Next.js.