Google ha chiarito senza ambiguità: i Core Web Vitals sono un fattore di ranking. E le animazioni con JavaScript sono tra i principali colpevoli di scarse performance. Ma allora come si fa a creare siti web con animazioni coinvolgenti senza rovinare i punteggi di Google? In questo articolo analizziamo l”impatto delle animazioni sui Core Web Vitals e scopriamo come ottenere 100/100 Lighthouse anche con animazioni complesse.
Cosa sono i Core Web Vitals
I Core Web Vitals sono un insieme di metriche introdotte da Google per misurare l”esperienza utente di una pagina web:
- LCP (Largest Contentful Paint): misura il tempo di caricamento del contenuto principale. Dovrebbe essere inferiore a 2.5 secondi.
- FID (First Input Delay): misura il tempo che intercorre tra il primo click dell”utente e la risposta del browser. Dovrebbe essere inferiore a 100 millisecondi. (Sostituito da INP – Interaction to Next Paint nel 2024)
- CLS (Cumulative Layout Shift): misura la stabilità visiva della pagina. Dovrebbe essere inferiore a 0.1.
- INP (Interaction to Next Paint): nuova metrica che misura la reattività complessiva della pagina. Sostituisce FID dal 2024.
- TBT (Total Blocking Time): misura il tempo totale in cui il thread principale è bloccato. Dovrebbe essere inferiore a 200ms.
Come le animazioni JavaScript impattano queste metriche
LCP: il peso degli script
Ogni libreria JavaScript per animazioni (AOS, GSAP, ScrollMagic) aggiunge decine di KB che devono essere scaricati, analizzati ed eseguiti PRIMA che la pagina possa diventare interattiva. Questo ritarda il rendering del contenuto principale e peggiora l”LCP.
Esempio con AOS: 35KB di JavaScript che bloccano il rendering. L”LCP passa da 1.2s a 2.1s (+75%).
INP: il thread principale occupato
Le librerie di animazioni spesso eseguono codice durante lo scroll, occupando il thread principale. Questo significa che se l”utente prova a cliccare o interagire con la pagina durante un”animazione, la risposta potrebbe essere ritardata.
TBT: blocking time
Più JavaScript significa più blocking time. Le librerie di animazioni possono facilmente aggiungere 100-200ms di TBT.
CLS: il pericolo delle animazioni non dichiarative
Se un”animazione modifica le dimensioni o la posizione di un elemento dopo che è stato renderizzato, può causare layout shift. Le animazioni CSS dichiarative non hanno questo problema perché il browser conosce in anticipo il risultato finale.
Il confronto: animazioni JS vs CSS Scroll-Driven
| Metrica | AOS (35KB) | GSAP (50KB) | CSS Scroll-Driven (0KB) |
|---|---|---|---|
| LCP | 2.1s | 2.4s | 1.2s |
| TBT | 120ms | 180ms | 0ms |
| CLS | 0.05-0.15 | 0.03-0.10 | 0.00 |
| Lighthouse Performance | ~85 | ~78 | 100 |
| Peso pagina | +35KB | +50KB | 0KB |
8 regole per animazioni performanti in WordPress
Regola 1: preferisci animazioni CSS a JS
Le animazioni CSS sono processate dal browser su un thread separato (compositor thread), senza occupare il thread principale. Le animazioni JavaScript occupano il thread principale e possono causare jank (scatti).
Regola 2: usa transform e opacity
Le proprietà transform e opacity sono le uniche che il browser puà animare senza ricalcolare il layout. Animare width, height, margin o top causa ricalcoli costosi.
Regola 3: evita JavaScript per animazioni scroll-driven
Usa animation-timeline: view() per animazioni legate allo scroll. È supportato da Chrome, Edge e Opera. Per Safari e Firefox, usa un polyfill JS leggero.
Regola 4: imposta content-visibility: auto
La proprietà content-visibility: auto dice al browser di non renderizzare gli elementi fuori dallo schermo, migliorando l”LCP e la velocità di rendering. Applicala alle sezioni della pagina che sono sotto la piega.
.sezione-sotto-la-piega {
content-visibility: auto;
contain-intrinsic-size: 500px;
}Regola 5: specifica width e height su immagini e video
Se non specifichi le dimensioni di immagini e video, il browser deve aspettare che siano caricati per conoscere le dimensioni, causando layout shift (CLS). Specifica sempre width e height.
Regola 6: non bloccare il rendering con gli script
Usa defer o async per tutti gli script non critici. Le librerie di animazioni non sono critiche per il rendering iniziale, quindi dovrebbero essere caricate in modo asincrono.
Regola 7: testa con Lighthouse e PageSpeed Insights
Prima di lanciare un sito, testalo con Google Lighthouse (integrato in Chrome DevTools) e PageSpeed Insights. Verifica che le animazioni non peggiorino i punteggi.
Regola 8: usa un polyfill progressivo per compatibilità
ClassyBlocks Pro implementa esattamente questa strategia: su Chrome, Edge e Opera usa animazioni CSS native con zero JS (100/100 Lighthouse). Su Safari e Firefox, il polyfill JS si attiva automaticamente. Il risultato? Performance massime senza compromettere la compatibilità.
Risultati reali con ClassyBlocks Pro
Test eseguiti su un sito WordPress con Blocksy theme, 151 animazioni attive:
- Lighthouse Performance: 100/100
- LCP: 1.2s
- TBT: 0ms
- CLS: 0.02
- Peso JS aggiuntivo: 0KB (su browser moderni)
