Indice dei contenuti dell'articolo:
Quando si parla di ottimizzazione delle performance di un sito web, l’attenzione viene spesso concentrata sul peso delle immagini, sulla compressione delle risorse, sulla cache, sul JavaScript o sui tempi di risposta del server. Tutti elementi fondamentali, ma che rappresentano soltanto una parte del problema.
Una pagina moderna può infatti contenere migliaia di nodi DOM, immagini, tabelle, widget, blocchi editoriali, prodotti, recensioni e componenti che il browser deve analizzare, impaginare e potenzialmente disegnare anche quando una parte consistente di questi contenuti si trova molto al di sotto della porzione visibile dello schermo.
È qui che entra in gioco content-visibility, una proprietà CSS pensata per permettere al browser di evitare parte del lavoro di rendering dei contenuti che, in quel momento, non sono rilevanti per l’utente.
Utilizzata correttamente, può diventare uno strumento molto interessante per pagine particolarmente lunghe, e-commerce con molti prodotti, archivi, documentazione tecnica, blog complessi e applicazioni web con numerose sezioni indipendenti.
Non bisogna però considerarla una sorta di interruttore magico per ottenere punteggi PageSpeed più elevati. content-visibility deve essere applicata in modo selettivo, perché un utilizzo errato può produrre l’effetto opposto, introducendo instabilità nel layout o ritardando il rendering di contenuti importanti.
Che cosa fa realmente content-visibility
Prima di capire il suo rapporto con i Core Web Vitals è necessario comprendere cosa accade durante il rendering di una pagina.
Dopo aver ricevuto HTML e CSS, il browser deve costruire le strutture necessarie alla visualizzazione della pagina, calcolare gli stili, determinare posizione e dimensioni degli elementi e infine eseguire il painting. Su documenti molto complessi queste operazioni possono diventare costose, soprattutto su smartphone o dispositivi con CPU meno performanti.
La proprietà content-visibility permette di indicare al browser che il contenuto di determinati elementi può essere trattato in maniera differente.
I suoi valori principali sono:
- visible: comportamento normale e valore predefinito;
- auto: permette al browser di evitare il rendering dei contenuti non rilevanti o sufficientemente lontani dall’area visibile;
- hidden: mantiene nascosto il contenuto indipendentemente dalla sua posizione sullo schermo.
Ai fini dell’ottimizzazione delle normali pagine web, il valore più interessante è generalmente content-visibility: auto.
.sezione {
content-visibility: auto;
}
Con questa semplice dichiarazione CSS il browser può applicare automaticamente diverse forme di CSS Containment e, quando una sezione si trova fuori dall’area rilevante per l’utente, può evitare una parte consistente delle operazioni necessarie a elaborarne i discendenti.
In termini pratici, invece di effettuare immediatamente layout e painting di ogni singolo elemento presente in una pagina molto lunga, il browser può concentrarsi innanzitutto sulle sezioni effettivamente necessarie.
CSS Containment: il principio alla base dell’ottimizzazione
content-visibility è strettamente collegata al concetto di CSS Containment.
Normalmente il browser deve considerare che la modifica di un elemento potrebbe avere conseguenze su altri elementi della pagina. Il layout di un componente può influenzare quello circostante e questo rende più difficile escludere porzioni del documento dai calcoli.
Il containment consente invece di delimitare maggiormente gli effetti di un sottoalbero DOM. Con content-visibility: auto vengono applicate forme di contenimento relative a layout, stile e painting; quando il contenuto viene effettivamente saltato entra in gioco anche il contenimento delle dimensioni.
Questo isolamento permette al motore di rendering di prendere decisioni che sarebbero difficili da effettuare in sicurezza in una normale struttura DOM.
Il vantaggio diventa tanto più evidente quanto più il documento contiene sezioni autonome e complesse. Una landing page di poche centinaia di righe potrebbe ottenere benefici marginali; un catalogo con decine di blocchi, una pagina editoriale molto lunga o una pagina di documentazione possono invece offrire opportunità di ottimizzazione decisamente maggiori.
content-visibility e Core Web Vitals: cosa può migliorare davvero?
I Core Web Vitals attualmente utilizzati per valutare aspetti fondamentali dell’esperienza utente sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS).
Come riferimento, una buona esperienza richiede generalmente un LCP entro 2,5 secondi, un INP non superiore a 200 millisecondi e un CLS non superiore a 0,1, valutando il comportamento reale degli utenti al 75° percentile.
È però importante distinguere tra correlazione e causalità: content-visibility non migliora automaticamente tutte e tre le metriche. Il suo contributo dipende dalla struttura della pagina e dal tipo di collo di bottiglia presente.
Effetti sul Largest Contentful Paint
Il Largest Contentful Paint misura quanto rapidamente viene visualizzato il principale contenuto presente nell’area iniziale della pagina.
Se un documento è molto esteso, evitare una parte del lavoro di rendering relativo alle sezioni lontane dal viewport può ridurre il carico iniziale sul main thread e lasciare maggiori risorse a disposizione del contenuto realmente importante.
Questo può contribuire indirettamente a un caricamento iniziale più efficiente.
Esiste però una regola fondamentale: non applicare indiscriminatamente content-visibility al contenuto above-the-fold.
L’hero, il titolo principale, l’immagine principale, il contenuto iniziale e in generale gli elementi potenzialmente candidati a diventare LCP devono essere renderizzati immediatamente. Cercare di posticiparli significa rischiare di compromettere proprio la metrica che si voleva migliorare.
Una strategia molto più sensata consiste nell’applicare la proprietà alle sezioni successive.
<main>
<section class="hero">
...
</section>
```
<section class="sezione-differita">
...
</section>
<section class="sezione-differita">
...
</section>
```
</main>
.sezione-differita {
content-visibility: auto;
}
In questo modo la parte iniziale resta immediatamente disponibile, mentre il browser può ottimizzare il lavoro relativo ai blocchi più lontani.
Effetti su Interaction to Next Paint
Il rapporto con INP è particolarmente interessante.
INP misura la reattività percepita durante le interazioni dell’utente. Un main thread impegnato in lunghi calcoli di JavaScript, style recalculation, layout o rendering può ritardare la visualizzazione del risultato di un click, di un tap o della pressione di un tasto.
Riducendo il lavoro necessario per le sezioni fuori schermo, content-visibility può diminuire in alcuni scenari la pressione sul main thread e lasciare più capacità disponibile per rispondere alle interazioni.
Il beneficio è particolarmente plausibile nelle pagine con DOM estesi e numerosi componenti indipendenti.
Non sostituisce però l’ottimizzazione del JavaScript. Se il problema è costituito da task da centinaia di millisecondi, script di terze parti invasivi o event handler inefficienti, aggiungere una proprietà CSS non sarà sufficiente.
L’ottimizzazione efficace dell’INP deve considerare insieme JavaScript, DOM, layout e rendering.
Attenzione però al Cumulative Layout Shift
È sul CLS che occorre prestare particolare attenzione.
Quando il browser salta il contenuto di una sezione deve comunque essere in grado di stimare lo spazio che questa occuperà nella pagina. Se la dimensione prevista è molto differente da quella reale, l’arrivo del contenuto nel viewport può produrre spostamenti visibili.
Per questo motivo content-visibility viene spesso utilizzata insieme a contain-intrinsic-size.
contain-intrinsic-size: il complemento fondamentale
contain-intrinsic-size permette di fornire al browser una dimensione utilizzabile come riferimento quando il contenuto interno non viene renderizzato.
Un esempio semplice può essere:
.sezione-differita {
content-visibility: auto;
contain-intrinsic-size: auto 800px;
}
Gli 800 pixel rappresentano una stima iniziale dello spazio necessario. La parola chiave auto rende la soluzione ancora più interessante: dopo che la sezione è stata effettivamente renderizzata, il browser può ricordarne le dimensioni reali e utilizzarle quando quella stessa sezione tornerà a essere saltata.
Naturalmente 800px non è un valore universale. Copiare una misura arbitraria da un tutorial può introdurre più problemi di quanti ne risolva.
Se le sezioni interessate hanno mediamente un’altezza di circa 500 pixel, utilizzare una previsione di 1500 pixel può provocare variazioni importanti durante lo scrolling. Allo stesso modo, sottostimare drasticamente le dimensioni può far espandere improvvisamente il documento quando il contenuto viene elaborato.
La dimensione intrinseca dovrebbe quindi essere scelta analizzando il layout reale, eventualmente differenziandola per tipologia di componente.
.card-prodotto {
content-visibility: auto;
contain-intrinsic-size: auto 420px;
}
.blocco-editoriale {
content-visibility: auto;
contain-intrinsic-size: auto 900px;
}
.sezione-recensioni {
content-visibility: auto;
contain-intrinsic-size: auto 700px;
}
Questa soluzione è generalmente più affidabile rispetto all’applicazione di un unico valore a elementi con caratteristiche completamente differenti.
Dove utilizzare content-visibility
Le situazioni più interessanti sono quelle in cui una pagina contiene una grande quantità di contenuto inizialmente fuori viewport.
Un esempio tipico è un articolo molto lungo. La prima parte deve essere disponibile immediatamente, mentre sezioni che si trovano migliaia di pixel più in basso non hanno necessariamente bisogno di essere elaborate con la stessa priorità.
Lo stesso concetto può essere applicato a cataloghi e-commerce, liste di risultati, pagine categoria, FAQ molto estese, documentazione tecnica, pagine con numerosi commenti o recensioni e dashboard ricche di componenti.
In WordPress, per esempio, potrebbe essere sensato assegnare una classe specifica a grandi blocchi editoriali successivi alla parte iniziale:
<article class="contenuto-articolo">
```
<section>
<!-- Contenuto iniziale: rendering normale -->
</section>
<section class="cv-auto">
<!-- Sezione molto lunga -->
</section>
<section class="cv-auto">
<!-- Altra sezione fuori viewport -->
</section>
```
</article>
.cv-auto {
content-visibility: auto;
contain-intrinsic-size: auto 750px;
}
È preferibile lavorare su blocchi semanticamente indipendenti invece di applicare la proprietà a una grande quantità di piccoli elementi. Aggiungerla a ogni paragrafo o a ogni singolo nodo non significa necessariamente ottenere prestazioni migliori e aumenta inutilmente la complessità del layout.
Dove invece è meglio non utilizzarla
L’errore più comune consiste nell’aggiungere content-visibility: auto a selettori troppo generici, magari a tutti gli elementi section, article o ai principali wrapper del sito senza aver prima analizzato il risultato.
È opportuno evitare in particolare l’applicazione indiscriminata agli elementi presenti nella prima schermata, ai possibili candidati LCP, a componenti la cui geometria influenza fortemente il resto della pagina e a strutture nelle quali il containment produce comportamenti differenti da quelli previsti dal layout originale.
Occorre inoltre prestare attenzione alle applicazioni JavaScript che interrogano continuamente dimensioni e coordinate del DOM. Alcune API possono richiedere al browser informazioni di layout relative anche a contenuti che si stava cercando di saltare, riducendo o annullando parte del vantaggio ottenuto.
In altre parole, content-visibility funziona meglio quando l’architettura della pagina consente realmente al browser di lasciare tranquille le sezioni fuori schermo.
Accessibilità, ricerca nella pagina e content-visibility
Un aspetto importante riguarda la differenza tra auto e hidden.
Con content-visibility: auto, i contenuti fuori schermo continuano a far parte del DOM e restano semanticamente rilevanti. Il browser può renderli disponibili a funzioni come la ricerca nella pagina, alla navigazione da tastiera e alle tecnologie assistive pur evitando temporaneamente parte del lavoro grafico.
content-visibility: hidden ha invece un comportamento diverso e non dovrebbe essere utilizzato come semplice sostituto universale di display: none.
Quando si lavora sull’accessibilità è quindi essenziale verificare il comportamento reale con navigazione da tastiera e screen reader, soprattutto nel caso di interfacce complesse, accordion, modali, tab e componenti dinamici.
L’ottimizzazione delle performance non deve mai compromettere la fruibilità del contenuto.
Progressive enhancement e compatibilità browser
Oggi content-visibility dispone di un supporto molto più ampio rispetto ai primi anni della sua introduzione e può essere utilizzata nei principali browser moderni. In presenza di progetti che devono supportare client particolarmente datati è comunque buona pratica considerarla come un miglioramento progressivo.
Un browser che non applica la proprietà deve poter visualizzare normalmente la pagina.
Se si vuole essere espliciti, è possibile utilizzare una feature query CSS:
@supports (content-visibility: auto) {
.cv-auto {
content-visibility: auto;
contain-intrinsic-size: auto 750px;
}
}
La pagina rimane così perfettamente utilizzabile anche quando l’ottimizzazione non è disponibile.
Come verificare se content-visibility sta realmente migliorando le performance
Ogni intervento di performance optimization deve essere misurato. Non è sufficiente aggiungere una proprietà CSS e osservare un incremento occasionale del punteggio Lighthouse.
Prima dell’intervento è consigliabile creare una baseline e verificare almeno il comportamento su mobile e desktop, il rendering iniziale, le attività del main thread, eventuali layout shift e i Core Web Vitals disponibili.
Dopo aver applicato content-visibility, bisogna ripetere i test nelle stesse condizioni e confrontare i risultati.
Chrome DevTools permette inoltre di utilizzare il pannello Performance per osservare le fasi di style recalculation, layout e rendering. In una pagina realmente adatta a questa tecnica dovrebbe essere possibile rilevare una diminuzione del lavoro associato ai contenuti offscreen.
PageSpeed Insights e Lighthouse rimangono strumenti molto utili, ma i risultati di laboratorio devono essere affiancati ai dati reali degli utenti. Search Console e Chrome UX Report possono mostrare una situazione diversa da quella di una singola simulazione eseguita dal proprio computer.
Bisogna inoltre lasciare trascorrere il tempo necessario affinché i dati sul campo riflettano il comportamento degli utenti successivo alla modifica.
content-visibility non sostituisce una corretta ottimizzazione dello stack
Una pagina web veloce nasce dalla combinazione di molti livelli differenti.
Se il server impiega diversi secondi per generare il documento HTML, se il database è sovraccarico, se la cache è configurata male o se vengono trasferiti diversi megabyte di JavaScript bloccante, content-visibility non può risolvere il problema alla radice.
Allo stesso modo, non sostituisce l’ottimizzazione delle immagini, il lazy loading ragionato, la riduzione del JavaScript, il Critical CSS, una corretta politica di caching, HTTP/2 o HTTP/3, Brotli, una CDN dove necessaria e soprattutto un’infrastruttura server dimensionata correttamente.
Le Web Performance sono il risultato dell’intera catena che va dal server al browser.
Il browser può essere perfettamente ottimizzato, ma se riceve tardi il documento iniziale partirà comunque in ritardo. Viceversa, un server estremamente veloce non elimina il costo di rendering di una pagina con un DOM enorme e decine di componenti complessi.
È proprio per questo che content-visibility è interessante: interviene su un livello spesso trascurato, quello del costo computazionale necessario al browser per visualizzare il documento.
Una strategia pratica per introdurre content-visibility in produzione
La soluzione migliore non consiste nell’applicare questa proprietà globalmente, ma nell’introdurla dopo aver individuato le pagine che presentano una complessità di rendering significativa.
Il processo dovrebbe partire dall’analisi delle pagine più importanti e dei template più utilizzati. Una volta individuati i blocchi particolarmente estesi che si trovano normalmente sotto la prima schermata, è possibile sperimentare content-visibility: auto e definire una dimensione intrinseca coerente con il layout.
Occorre poi controllare attentamente scrolling, ancore interne, ricerca nel documento, navigazione da tastiera, componenti JavaScript e comportamento responsive.
Solo dopo questi controlli ha senso confrontare i dati di performance e valutare l’estensione della modifica ad altri template.
Questo approccio consente di ottenere un vantaggio misurabile senza trasformare un’ottimizzazione CSS in una nuova fonte di regressioni.
Conclusioni: meno rendering inutile, ma solo dove serve
content-visibility rappresenta una delle tecniche CSS più interessanti per l’ottimizzazione delle pagine particolarmente lunghe o complesse. Permette al browser di evitare temporaneamente parte del lavoro necessario per sezioni che l’utente non sta ancora visualizzando, riducendo il costo iniziale di layout e painting.
Il vantaggio può riflettersi sul caricamento e sulla reattività della pagina e, in determinate condizioni, contribuire al miglioramento di metriche come LCP e INP.
Allo stesso tempo, un uso scorretto può compromettere il risultato, soprattutto quando la proprietà viene applicata ai contenuti iniziali oppure quando contain-intrinsic-size viene configurata con valori molto lontani dalle dimensioni reali, generando instabilità nel layout.
La regola rimane quindi la stessa che dovrebbe guidare ogni intervento sulle Web Performance: misurare prima, ottimizzare in modo selettivo e misurare nuovamente dopo la modifica.
Per siti WordPress, WooCommerce, portali editoriali e applicazioni ad alto traffico, l’ottimizzazione frontend deve inoltre essere accompagnata da un’infrastruttura adeguata. Una configurazione server corretta, cache efficienti, PHP e database ottimizzati, insieme al controllo del rendering lato browser, permettono di intervenire sull’intera catena delle performance anziché limitarsi a inseguire il singolo punteggio di un benchmark.
È questo approccio complessivo, dal server fino al rendering finale nel browser, che consente di ottenere siti realmente veloci, stabili e reattivi per gli utenti reali.
