Il video è diventato un elemento abituale di molti siti: il filmato di presentazione in apertura della home, il tutorial incorporato da YouTube in un articolo, la demo del prodotto nella scheda di un e-commerce, lo sfondo animato di una landing page. È un contenuto efficace, che trattiene l’attenzione e comunica in pochi secondi ciò che richiederebbe paragrafi di testo. Ma è anche, per peso e complessità, uno degli elementi che più facilmente compromettono le prestazioni di una pagina.
I problemi cambiano a seconda di come il video viene inserito. Un video incorporato da una piattaforma porta con sé il lettore e tutto il suo JavaScript; un video ospitato sul proprio server pesa per i dati da trasferire; un video in apertura può diventare l’elemento LCP; un riquadro senza dimensioni può causare spostamenti del layout. Vediamo i casi principali e le soluzioni per ciascuno.
I video incorporati da YouTube e Vimeo
Incorporare un video di YouTube o Vimeo è semplicissimo: si incolla l’indirizzo nell’editor e WordPress genera un iframe con il lettore. Quello che non si vede è il costo. L’iframe carica la pagina del lettore, che a sua volta scarica fogli di stile, font, script, immagini e dati di configurazione: spesso decine di richieste e un volume di dati nell’ordine del megabyte, di cui una parte consistente è JavaScript da eseguire. E tutto questo avviene per ogni visitatore, anche per chi non avvierà mai il video.
L’effetto si vede soprattutto sul main thread: il JavaScript del lettore compete con quello della pagina durante il caricamento e può peggiorare l’INP delle prime interazioni, oltre ad allungare il tempo di caricamento complessivo. Se il video si trova sopra la piega, può anche ritardare l’LCP sottraendo banda alle risorse importanti.
La facciata
La soluzione più efficace è la facciata: al posto dell’iframe si mostra un’immagine di anteprima del video con un pulsante di riproduzione, visivamente identica al lettore. Solo quando l’utente fa clic, la facciata viene sostituita dall’iframe vero, con l’avvio automatico del video. Il costo iniziale scende da un megabyte a poche decine di kilobyte, e chi non guarda il video non paga nulla.
Esistono componenti pronti, come i vari «lite embed» per YouTube e Vimeo, e plugin per WordPress che applicano automaticamente la facciata agli incorporamenti esistenti. Chi preferisce una soluzione propria può realizzarla con poche righe:
<button class="video-facciata" data-id="ID_VIDEO" aria-label="Riproduci il video">
<img src="anteprima.webp" width="1280" height="720" loading="lazy" alt="">
</button>
<script>
document.addEventListener( 'click', ( e ) => {
const f = e.target.closest( '.video-facciata' );
if ( ! f ) return;
const iframe = document.createElement( 'iframe' );
iframe.src = `https://www.youtube-nocookie.com/embed/${ f.dataset.id }?autoplay=1`;
iframe.allow = 'autoplay; encrypted-media; picture-in-picture';
iframe.allowFullscreen = true;
iframe.title = 'Video';
f.replaceWith( iframe );
} );
</script>Il dominio youtube-nocookie.com riduce anche i cookie impostati prima della riproduzione, un vantaggio per la gestione del consenso. Se non si vuole usare una facciata, l’attributo loading="lazy" sull’iframe è il minimo indispensabile per i video sotto la piega: il browser caricherà il lettore solo quando l’utente si avvicina, come spiegato nell’articolo sul lazy loading. È meno efficace della facciata, perché chi scorre la pagina carica comunque il lettore, ma è molto meglio di niente.
Riservare lo spazio: video e CLS
Un iframe o un elemento video senza dimensioni note occupa inizialmente uno spazio arbitrario e poi si ridimensiona, spingendo in basso il contenuto sottostante. Con i layout fluidi, dove il video occupa tutta la larghezza della colonna, gli attributi width e height da soli non bastano se il CSS modifica la larghezza: serve la proprietà aspect-ratio, che mantiene le proporzioni e permette al browser di riservare lo spazio corretto fin dall’inizio.
.video-facciata,
.contenuto iframe[src*="youtube"],
.contenuto video {
width: 100%;
height: auto;
aspect-ratio: 16 / 9;
}I blocchi di incorporamento dell’editor di WordPress applicano già un contenitore con proporzioni fisse per i servizi più noti; il problema si presenta soprattutto con codice incorporato a mano, con costruttori di pagine e con lettori personalizzati che si inizializzano via JavaScript. Il CLS prodotto da un video è spesso piccolo in valore assoluto, ma avviene proprio mentre l’utente inizia a leggere, ed è tra i più fastidiosi.
Il video in apertura e l’LCP
Un video che occupa la parte alta della pagina è quasi sempre l’elemento più grande visibile, e quindi decide l’LCP. Per un elemento video, il browser considera l’immagine poster e, nelle versioni più recenti di Chrome, anche il primo fotogramma mostrato. Senza un poster, la pagina deve attendere che il browser scarichi e decodifichi abbastanza dati del video da mostrarne un fotogramma: su una connessione mobile, questo può richiedere secondi.
La soluzione è trattare il poster come si tratta un’immagine hero: leggero, in formato moderno, di dimensioni adeguate e con priorità alta. Poiché il poster è un attributo del video e non un elemento immagine, il browser lo scopre un po’ più tardi; un preload con priorità alta lo porta subito in cima alla coda:
<link rel="preload" as="image" href="/media/hero-poster.webp" fetchpriority="high">
<video autoplay muted loop playsinline preload="metadata"
poster="/media/hero-poster.webp" width="1600" height="900">
<source src="/media/hero.webm" type="video/webm">
<source src="/media/hero.mp4" type="video/mp4">
</video>Vale anche la pena chiedersi se il video in apertura sia davvero necessario su mobile. Su uno schermo piccolo, un video di sfondo aggiunge spesso poco rispetto a un’immagine ben scelta, mentre consuma dati e batteria. Una soluzione frequente è mostrare solo il poster sotto una certa larghezza, oppure servire una versione più leggera del video, e rispettare la preferenza di movimento ridotto dell’utente con la media query prefers-reduced-motion.
Video ospitati sul proprio server
Ospitare i video in proprio evita il costo del lettore esterno, ma sposta l’attenzione sul peso dei file. Alcune regole pratiche fanno una grande differenza.
- Compressione adeguata. Un video di sfondo di dieci secondi non ha bisogno della qualità di un film: risoluzione adeguata allo spazio in cui viene mostrato, bitrate contenuto, nessuna traccia audio se è muto.
- Formati moderni. WebM con VP9 o AV1 è in genere molto più leggero di MP4 con H.264 a parità di qualità; offrire entrambi con più elementi
sourcelascia scegliere al browser. - L’attributo preload. Per i video che l’utente avvia manualmente,
preload="none"opreload="metadata"evita di scaricare dati prima del clic. - Video invece di GIF. Un’animazione in formato GIF può pesare dieci volte più dello stesso contenuto in un video con
autoplay muted loop playsinline. Convertire le GIF animate è uno degli interventi con il miglior rapporto tra sforzo e risultato. - Streaming per i video lunghi. Per filmati di minuti, lo streaming adattivo, come HLS, invia al browser segmenti di qualità adatta alla connessione, invece di un unico file pesante.
Infine, i video vanno serviti con una buona cache HTTP e, se il traffico è consistente, tramite una CDN. Un file video servito dal server che genera anche le pagine compete con PHP e database per le stesse risorse, e su un piano di hosting condiviso può rallentare tutto il sito.
Lettori personalizzati e JavaScript
Molti siti usano lettori video personalizzati, con controlli grafici, statistiche di visione, capitoli e sottotitoli. Sono utili, ma aggiungono JavaScript che, se caricato in modo sincrono in apertura di pagina, blocca il rendering e occupa il main thread. Anche in questo caso vale il principio della facciata: mostrare subito un’immagine con il pulsante di riproduzione e caricare il lettore completo solo quando serve, o almeno dopo che la pagina è diventata interattiva.
Video e consenso ai cookie
C’è un ulteriore motivo per preferire le facciate: il consenso. Il lettore di molte piattaforme imposta cookie e contatta servizi di terze parti già al caricamento, e in molti siti gli incorporamenti vengono bloccati finché l’utente non accetta i cookie relativi. Il risultato, se gestito male, è un riquadro vuoto o un messaggio generico al posto del video, che poi viene sostituito dall’iframe dopo il consenso, spesso con uno spostamento del layout. Una facciata con anteprima risolve entrambi i problemi: occupa lo spazio corretto fin dall’inizio, non contatta il servizio finché l’utente non avvia il video, e il clic di riproduzione può essere il momento naturale in cui chiedere il consenso per quel contenuto.
I video nelle schede prodotto
Negli e-commerce il video è sempre più spesso parte della galleria del prodotto: una rotazione a 360 gradi, una dimostrazione d’uso, un dettaglio del materiale. Il caso tipico è una galleria in cui il video è una delle diapositive, e il lettore viene inizializzato al caricamento anche se l’utente vede per prima l’immagine principale. Anche qui la regola è caricare il video solo quando la sua diapositiva viene mostrata, usando la miniatura come anteprima, e assicurarsi che l’immagine principale del prodotto resti l’elemento LCP, con la priorità più alta. Un video che si avvia automaticamente in una galleria compete per la banda proprio con le immagini che l’utente sta guardando, nel momento in cui decide se il prodotto gli interessa.
Un esempio tipico
Consideriamo la home di un’azienda con un video di sfondo in apertura, un file MP4 di 12 megabyte in qualità alta, senza poster, e due video di YouTube incorporati più in basso. Da mobile l’LCP supera i quattro secondi, perché il primo fotogramma arriva solo dopo diversi megabyte di dati, e il JavaScript dei due lettori, caricato per tutti, pesa sul main thread durante il caricamento. Gli interventi sono semplici: un poster WebP da 80 kilobyte con preload a priorità alta, il video ricompresso in WebM e MP4 a una risoluzione adatta, che scende sotto i 3 megabyte, solo il poster sugli schermi più piccoli, e due facciate al posto degli iframe. L’LCP da mobile scende sotto i due secondi, il peso della pagina si riduce di oltre il 70% e l’aspetto della home, per chi la visita, resta praticamente identico.
Come verificare
Lighthouse segnala esplicitamente gli incorporamenti di terze parti che potrebbero essere sostituiti da una facciata, e indica il peso delle risorse caricate dai lettori. Nel pannello Network dei DevTools, filtrando per il dominio del servizio video, si vede quante richieste partono prima di qualsiasi interazione. Per l’LCP, PageSpeed Insights mostra quale elemento è stato scelto: se è un video, conviene controllare che abbia un poster e che questo venga scaricato presto. Per il CLS, il pannello Performance evidenzia gli spostamenti del layout e l’elemento responsabile.
Sui dati di campo, l’effetto di questi interventi si vede in modo diverso a seconda della posizione del video. Un video in apertura migliora direttamente l’LCP delle pagine coinvolte; le facciate sugli incorporamenti più in basso si riflettono soprattutto sull’INP e sul peso complessivo delle pagine, e quindi su chi naviga da mobile con connessioni lente. Seguire le metriche per modello di pagina, per esempio con il Real User Monitoring, permette di attribuire correttamente ogni miglioramento.
In sintesi
I video possono pesare sulle Core Web Vitals in tre modi: il JavaScript e i dati dei lettori incorporati, che rallentano caricamento e interazioni; il video in apertura, che senza un poster ottimizzato ritarda l’LCP; i riquadri senza dimensioni, che generano spostamenti del layout. Le soluzioni sono altrettanto chiare: facciate che caricano il lettore solo al clic, poster leggeri con priorità alta, proporzioni riservate con aspect-ratio.
Per i video ospitati in proprio contano compressione, formati moderni, attributo preload e distribuzione tramite CDN, e le GIF animate vanno sostituite con video. Con queste accortezze il video resta uno strumento di comunicazione efficace senza diventare il motivo per cui la pagina che lo contiene si carica lentamente.
