Elimina le risorse di blocco della visualizzazione – 9 strategie di ottimizzazione

eliminare risorse blocco visualizzazione

Le risorse di blocco della visualizzazione sono file statici, come caratteri, file HTML, CSS e JavaScript, vitali per il processo di rendering di una pagina Web. Quando il browser rileva una risorsa che blocca della visualizzazione, interrompe il download del resto delle risorse finché questi file critici non vengono elaborati. Nel frattempo, l’intero processo di rendering viene sospeso.

D’altra parte, le risorse che non bloccano la visualizzazione non ritardano il rendering della pagina. Il browser può scaricarli in sicurezza in background dopo il rendering della pagina iniziale.

Tuttavia, non tutte le risorse che il browser ritiene che blocchino il rendering sono essenziali per il first paint; tutto dipende dalle caratteristiche individuali della pagina. Esistono best practice che puoi utilizzare per trasformare queste risorse di blocco della visualizzazione (rendering) non critiche in risorse che non bloccano il rendering.

eliminare risorse di blocco visualizzazione Illustrazione che mostra un automobile che sfonda un blocco della polizia

Inoltre, puoi anche ridurre il numero e/o la dimensione delle risorse che bloccano il rendering che sono ancora critiche e non possono essere eliminate.

In questo articolo esamineremo nove suggerimenti e trucchi per eliminare le risorse che bloccano il rendering. Sono:

  1. Identifica le risorse che bloccano il rendering
  2. Non aggiungere CSS con la regola @import
  3. Utilizza l’attributo media per i CSS condizionali
  4. Rinviare CSS non critici
  5. Utilizza gli attributi defer e async per eliminare JavaScript che blocca il rendering
  6. Trova e rimuovi CSS e JavaScript non utilizzati
  7. Suddividi il codice in bundle più piccoli
  8. Minimizza i file CSS e JavaScript
  9. Carica i caratteri personalizzati localmente

Perché eliminare le risorse che bloccano il rendering?

Se riduci il numero di risorse di blocco della visualizzazione, puoi abbreviare il percorso di rendering critico e ridurre i tempi di caricamento della pagina, migliorando così l’esperienza utente e l’ottimizzazione dei motori di ricerca.

Esistono tre modi per ridurre il numero e l’impatto delle risorse che bloccano la visualizzazione:

  1. Rendile risorse che non blocchino il rendering rinviandone il download
  2. Diminuisci il numero totale di risorse di blocco della visualizzazione utilizzando tecniche, come il raggruppamento (questo significa anche meno richieste HTTP).
  3. Riduci la dimensione di una risorsa tramite la minimizzazione in modo che la pagina abbia meno byte da caricare

Rendering di risorse di blocco e Core Web Vitals

Anche se l’eliminazione delle risorse che bloccano la visualizzazione è sempre stata un’importante tecnica di ottimizzazione delle prestazioni, l’introduzione di Core Web Vitals, le nuove metriche prestazionali di Google, l’ha resa ancora più importante.

Dato che i Core Web Vitals sono inclusi nell’algoritmo di ricerca di Google, semplicemente non puoi ignorarli se vuoi che il tuo sito si posizioni in alto su Google. Le risorse che bloccano il rendering possono avere un impatto negativo su uno dei tre Core Web Vitals: il Largest Contentful Paint (LCP).

largest contentful paint web dev soglie Google web dev cumulative layout shif web dev soglie Google web dev

LCP misura il tempo di rendering dell’immagine o del blocco di testo più grande visibile nel viewport dell’utente. Se il percorso di rendering critico è troppo lungo (disponi di troppe risorse che bloccano il rendering o i file sono troppo grandi), il caricamento dell’elemento di contenuto più grande richiederà più tempo. Pertanto, per un punteggio LCP migliore, è consigliabile tenere sotto controllo il numero e il peso delle risorse che bloccano il rendering.

Tipi di risorse che bloccano il rendering

Come regola generale, il browser tratta tutto ciò che trova nella sezione <head> di una pagina HTML come blocco del rendering. Ciò comprende:

  • Fogli di stile CSS
  • File JavaScript aggiunti nella sezione <head>
  • Caratteri aggiunti da CDN o da un server locale
  • Importazioni HTML (anche se le importazioni HTML sono ormai obsolete, potresti ancora riscontrarle su pagine legacy)

Immagini, file multimediali e tag <script> posizionati nella parte inferiore della sezione <body> vengono trattati come risorse che non bloccano il rendering.

Ora concentriamoci su nove strategie per eliminare o ridurre il numero e l’impatto delle risorse che bloccano la visualizzazione.

1. Identifica le risorse che bloccano il rendering

Che tu abbia un sito web esistente o che sia ancora in fase di sviluppo, la prima cosa da fare è trovare le risorse di blocco della visualizzazione in modo da poter decidere come gestirle. Fortunatamente, al giorno d’oggi ci sono molti strumenti gratuiti per la misurazione delle prestazioni che puoi utilizzare per questo scopo.

I più importanti sono:

Sia PageSpeed Insights che GTmetrix sono app Web gratuite che utilizzano la libreria Lighthouse per misurare la velocità della pagina, Core Web Vitals e altri parametri di prestazione.

Tuttavia quando testi una pagina, in Lighthouse, vedrai il flag Elimina risorse di blocco della visualizzazione nella sezione “Opportunità” del rapporto sulle prestazioni solo se le risorse di blocco della visualizzazione causano problemi di prestazioni sul tuo sito.

Ad esempio, ecco l’avvertimento di Lighthouse per la home page di Repubblica.it:

repubblica it analisi lighthouse integrata nel browser

Se desideri comunque ricevere feedback sulle risorse di blocco della visualizzazione, utilizza una delle app Web sopra menzionate. Oltre a identificare le risorse che bloccano la visualizzazione, forniscono anche suggerimenti utili su come eliminarle.

Ad esempio, ecco la parte rilevante del rapporto di GTmetrix per la pagina del blog di Wp-assistenza.

gtmetrix lighthouse test wp-assitenza

Puoi vedere che la raccomandazione Elimina le risorse di blocco della visualizzazione ha una priorità bassa, ma i file che “potrebbero contribuire al blocco della visualizzazione” non sono elencati:
Il modo in cui andrai avanti da qui dipende dai tuoi obiettivi. Se hai ricevuto un avviso

riguardo alle risorse che bloccano il rendering, dovresti provare ad eliminarle. In caso contrario, puoi comunque applicare alcune delle seguenti tecniche, poiché possono comunque migliorare i tempi di caricamento della pagina e i punteggi Core Web Vitals.

2. Non aggiungere CSS con la regola @import

Puoi aggiungere CSS a una pagina utilizzando:

Il tag <link rel="stylesheet"> che devi aggiungere al tuo file HTML
La regola @import che devi aggiungere al tuo file CSS
Anche se la regola @import mantiene il tuo file HTML più pulito e ti consente di mantenere tutte le dipendenze CSS nello stesso posto, non è la scelta migliore in termini di prestazioni. La regola @import ti consente di importare CSS da altri fogli di stile, ma ciò fa sì che il browser elabori il tuo file CSS più lentamente perché deve scaricare anche i file importati. Fino a quando ciò non avverrà, il processo di rendering sarà bloccato.

Se desideri aggiungere più di un file CSS alla tua pagina, puoi utilizzare il tag <link> o concatenare i file utilizzando uno strumento di minimizzazione e/o raggruppamento.
È necessario aggiungere l’elemento <link> alla sezione <head> della pagina HTML nel modo seguente:

<head>
<link href="style.css" rel="stylesheet">
</head>

3. Utilizza l’attributo media per i CSS condizionali

Per impostazione predefinita, il browser tratta tutti i file CSS come risorse di blocco del rendering. Tuttavia, se aggiungi l’attributo media al tag <link>, puoi indicare al browser la presenza di un file CSS condizionale.

Il CSS condizionale si applica solo in determinate condizioni, ad esempio al di sotto o al di sopra di una determinata dimensione del viewport o su una pagina di stampa. Con l’attributo media, puoi definire una condizione multimediale specifica per un file CSS. Puoi utilizzare qualsiasi valore che utilizzeresti per una query multimediale in un file CSS. Per esempio:

<link href="print.css" rel="stylesheet" media="print">
<link href="large.css" rel="stylesheet" media="screen and (min-width: 1500px)">
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">

Anche se questi file vengono comunque scaricati su tutti i dispositivi, diventano risorse che non bloccano il rendering se la condizione viene valutata come falsa. Tuttavia, continueranno a bloccare il rendering se la condizione risulta vera.

Ad esempio, il foglio di stile mobile.css nell’esempio precedente bloccherà il rendering sui dispositivi mobili con una larghezza massima del viewport di 600 px e non bloccherà il rendering sui viewport più grandi di 600 px.

Se disponi di un file CSS esistente con una o più query multimediali, puoi estrarre tutte le regole @media e salvarle come file separati utilizzando questo plug-in PostCSS.

4. Rinviare CSS non critici

Tutti i file CSS che inserisci nella sezione<head> della tua pagina HTML vengono automaticamente trattati come risorse di blocco della visualizzazione. Tuttavia, non hai bisogno di tutto questo codice per eseguire il rendering della parte critica della tua pagina: il contenuto sopra la piega. La suddivisione dei CSS in parti critiche e non critiche è una tecnica di ottimizzazione delle prestazioni che ha guadagnato molta popolarità dall’introduzione di Core Web Vitals, poiché migliora anche i punteggi LCP (ovvero il tempo di rendering dell’elemento di contenuto più grande sopra la piega).
Fortunatamente, non è necessario trovare manualmente il CSS del percorso critico, anche se è possibile farlo. Puoi utilizzare strumenti online, come il Critical Path CSS Generator o la libreria Critical di Addy Osmani, per estrarre le regole CSS correlate ai tuoi contenuti sopra la piega.

Critical Path CSS Generator, ad esempio, genera due file CSS scaricabili: uno “critico” e uno “combinato”. Puoi aggiungere il file CSS critico come risorsa esterna alla sezione <head> oppure incorporarlo utilizzando il tag <style> per ridurre anche il numero di richieste HTTP.

Il file CSS combinato include tutte le tue regole CSS e devi spostarlo verso il basso prima del tag <body> di chiusura in modo che diventi una risorsa che non blocca il rendering. Puoi leggere le istruzioni in dettaglio sotto il generatore, ma ecco come dovrebbe apparire il tuo codice ottimizzato:

percorso critico css

Facoltativamente, puoi anche utilizzare JavaScript per caricare dinamicamente i CSS lower-the-fold dopo che il browser ha terminato di scaricare la pagina. Tuttavia, non contribuirà all’eliminazione delle risorse che bloccano la visualizzazione poiché i CSS non critici sono già stati spostati dalla sezione <head>. Per saperne di più sul percorso critico Css leggi questo articolo di Web Dev Google

5. Utilizza gli attributi defer e async per eliminare il JavaScript che blocca il rendering

Similmente ai CSS, anche i file JavaScript aggiunti alla sezione <head> del documento vengono trattati come risorse di blocco del rendering per impostazione predefinita.

Puoi rimuoverli dal percorso di rendering critico posizionando i tag <script> subito prima del tag di chiusura </body> invece della sezione <head>. In questo caso, il download inizia solo dopo che è stato scaricato l’intero codice HTML. Tuttavia, poiché il download di questi script inizia più tardi, gli elementi da essi caricati, come annunci, animazioni o funzionalità dinamiche, potrebbero caricarsi più tardi rispetto al resto del frontend, soprattutto se si tratta di uno script più lungo. Ciò può comportare ritardi notevoli e rallentamenti dell’interfaccia utente su connessioni più lente, il che è negativo per l’esperienza dell’utente.

Gli attributi defer e async del tag <script> offrono una soluzione a questo problema. Entrambi sono attributi booleani, il che significa che se li aggiungi, si attiveranno senza alcuna ulteriore configurazione. Realizzano anche script aggiunti alla sezione <head> di un documento HTML che non bloccano il rendering, ma in un modo diverso; gli script differiti rispettano l’ordine dei documenti mentre gli script asincroni sono indipendenti dal DOM.

L’attributo defer indica al browser di scaricare lo script in background in modo da non bloccare il rendering della pagina. Lo script differito viene eseguito una volta che il DOM è pronto ma prima che venga attivato l’evento DOMContentLoaded.

<script src="script01.js" defer></script>
<script src="script02.js" defer></script>

Gli script differiti seguono l’ordine dei documenti, proprio come gli script predefiniti non differiti. Ad esempio, nell’esempio precedente, script01.js verrà eseguito per primo, indipendentemente da quale script venga caricato per primo. Non puoi aggiungere il rinvio agli script in linea; funziona solo con script esterni che specificano la posizione dello script utilizzando l’attributo src.
D’altra parte, l’attributo async informa il browser che uno script è completamente indipendente dalla pagina. Verrà scaricato in background come risorsa che non blocca il rendering, proprio come gli script differiti. Tuttavia, a differenza degli script differiti, gli script asincroni non seguono l’ordine dei documenti, quindi verranno eseguiti al termine del download, cosa che può accadere in qualsiasi momento.

Ad esempio, nell’esempio seguente, non possiamo essere sicuri di quale script verrà eseguito per primo; dipende esclusivamente da quale verrà scaricato più velocemente (di solito quello più piccolo). Ricorda, gli script asincroni sono indipendenti sia dal documento che l’uno dall’altro, quindi l’ordine dei documenti non li influenzerà in alcun modo.

<script src="script03.js" async></script>
<script src="script04.js" async></script>

L’attributo defer è consigliato per gli script che necessitano del DOM, ma vuoi iniziare a scaricarli prima che il documento venga caricato, senza renderli una risorsa di blocco del rendering. Dovresti anche utilizzare il differimento anziché l’asincrono se l’ordine dei documenti è importante, ad esempio quando gli script consecutivi dipendono l’uno dall’altro.

async attribute è consigliato per script indipendenti di terze parti, come annunci, tracker e script di analisi. Ad esempio, Google Analytics consiglia di aggiungere l’attributo async per supportare il caricamento asincrono nei browser moderni.

6. Trova e rimuovi CSS e JavaScript non utilizzati

Oltre a rinviare CSS e JavaScript non critici, ti consigliamo anche di verificare se sul tuo sito sono presenti CSS o JavaScript non utilizzati. Puoi farlo con l’aiuto di strumenti di analisi del codice come PurgeCSS( strumento di WP-rocket) che controlla il tuo codice CSS e rimuove da esso eventuali selettori inutilizzati, compresi quelli aggiunti da librerie o framework di terze parti come Bootstrap.

Trovare e rimuovere JavaScript inutilizzato è un po’ più complicato poiché dovrai analizzare il codice manualmente. Puoi eseguire un’analisi del codice utilizzando la scheda Copertura di Chrome DevTools (vedi le istruzioni dettagliate) che evidenzierà in rosso il codice non utilizzato. Anche se consigliamo questa tecnica solo se sei bravo con JavaScript e sai cosa stai rimuovendo, può anche essere un ottimo modo per individuare librerie di terze parti che usi a malapena. Se trovi una risorsa del genere, puoi prendere in considerazione la possibilità di rimuoverla completamente dal tuo sito.

I sistemi di gestione dei contenuti più diffusi come WordPress dispongono anche di plug-in di pulizia che ti consentono di rimuovere automaticamente CSS e JavaScript inutilizzati.

7. Suddividi il codice in pacchetti più piccoli

Puoi utilizzare bundler di moduli come Webpack, Rollup e Parcel per suddividere il codice in bundle più piccoli e caricare ciascun bundle su richiesta e anche in parallelo. Molti di questi pacchetti più piccoli sono risorse non essenziali che possono essere caricate in lazy-loading dopo il rendering della pagina web. Potresti anche avere del codice che devi caricare solo se l’utente desidera utilizzare una parte o una funzionalità specifica della tua pagina.

Anche se è possibile eseguire manualmente la suddivisione del codice e creare pacchetti più piccoli, l’automazione rende il processo semplice, sicuro e veloce. Al giorno d’oggi, la maggior parte degli strumenti di raggruppamento sono dotati di funzionalità di suddivisione del codice senza configurazione che funziona immediatamente, ma ti consentono anche di modificare manualmente la configurazione, se lo desideri.

8. Minimizza CSS e JavaScript

Oltre alla suddivisione del codice, puoi anche ridurre al minimo le risorse che bloccano e non bloccano il rendering. Poiché i file minimizzati sono più leggeri, il rendering della pagina iniziale terminerà prima. Inoltre, ci vorrà meno tempo per scaricare in background le risorse che non bloccano il rendering.

Sono disponibili numerosi strumenti per aiutarti a eseguire la minimizzazione secondo le migliori pratiche, tra cui Minify, CSS Minifier, Minify Code e PostCSS. Nell’articolo sotto trovi i dettagli.

Minimizzare i Javascript

Gli strumenti di creazione, come Webpack, Parcel e Rollup, sono inoltre dotati di funzionalità di minimizzazione integrate che consentono di ridurre rapidamente il peso delle risorse che bloccano il rendering.

9. Carica i caratteri personalizzati localmente

Poiché i font personalizzati vengono richiamati dalla sezione <head> del documento, sono anche risorse che bloccano il rendering. Ad esempio:

<link href="https://fonts.googleapis.com/css2?family=Lato&display=swap" rel="stylesheet">

Puoi ridurre l’impatto dei caratteri personalizzati sul rendering della pagina iniziale aggiungendoli localmente anziché estrarli da una rete di distribuzione dei contenuti come Google CDN. I fornitori di caratteri tendono ad aggiungere più regole @font-face, molte delle quali non ti serviranno.

Ad esempio, Google Fonts aggiunge le regole @font-face per tutti i set di caratteri con cui viene fornito un carattere tipografico, come latino, cirillico, cinese, vietnamita e altri. Supponiamo, ad esempio, che il file CSS online che aggiungi con il tag <link> includa le regole @font-face per sette diversi set di caratteri, ma desideri utilizzarne solo uno (ad esempio, latino). Tuttavia, Google Fonts non scarica i file dei caratteri per tutti i set di caratteri; aggiungono semplicemente molte regole @font-face ridondanti al file CSS.

Se aggiungi caratteri localmente, puoi anche minimizzare il tuo font-re

lated CSS e raggruppalo insieme al resto del tuo CSS. Puoi utilizzare Google Web Fonts Helper per generare rapidamente regole @font-face locali per Google Fonts. Ad esempio, questo è ciò che devi aggiungere per includere il carattere Lato Regular:

/* lato-regular - latin */
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'), local('Lato-Regular'),
url('../fonts/lato-v16-latin-regular.woff2') format('woff2'),
url('../fonts/lato-v16-latin-regular.woff') format('woff');
}

Tieni presente che Google Web Fonts Helper non aggiunge la regola font-display: swap; L’ho aggiunto io stesso alla dichiarazione qui sopra. Questo è un descrittore della regola @font-face che ti consente di specificare come il browser dovrebbe visualizzare il carattere sulla pagina.

Utilizzando font-display con il valore swap, indichi al browser di iniziare immediatamente a utilizzare un carattere di sistema e di scambiarlo con il carattere personalizzato una volta scaricato (questa regola viene aggiunta anche quando estrai il carattere dal CDN di Google). Ciò ti consente di evitare testo invisibile sulla pagina mentre il carattere personalizzato è ancora in fase di caricamento.

Quando carichi i caratteri localmente, assicurati di fornire formati di caratteri compressi per i browser moderni, come WOFF e WOFF2. Ricorda che anche i file più leggeri riducono l’impatto delle risorse che bloccano il rendering. Oltre a generare le regole @font-face, Google Web Fonts Helper ti consente anche di scaricare un file zippato che contiene tutti i formati di carattere di cui hai bisogno.

Perché non dovresti caricare i caratteri personalizzati in modo asincrono

Alcuni articoli sulle risorse di blocco della visualizzazione consigliano di utilizzare il caricatore di caratteri Web di TypeKit per caricare caratteri personalizzati in modo asincrono. Un tempo era uno strumento decente, ma non è stato aggiornato dal 2017 e presenta molti problemi irrisolti. Non consiglierei di usarlo.

Sebbene il caricamento dei caratteri in modo asincrono riduca il percorso di rendering critico, dovresti sempre farlo con attenzione. Se i caratteri vengono caricati più tardi rispetto al contenuto della pagina, la pagina può produrre un problema UX comune chiamato Flash of Invisible Text (FOIT).

Esistono vari modi per gestire FOIT, ad esempio utilizzando librerie di terze parti o la suddetta regola font-display: swap (vedere il supporto del browser per font-display e notare che utilizzarlo con il valore swap trasforma semplicemente FOIT in FOUT – flash of testo senza stile, ma non elimina completamente il problema). Tuttavia, ti consigliamo di dedicare del tempo a valutare se vale davvero la pena percorrere il percorso asincrono in termini di prestazioni. Pensa al peso di script aggiuntivi, potenziali problemi, utenti con JavaScript disabilitato (devi comunque aggiungere l’elemento statico <link> all’interno dei tag <noscript> per supportarli), ecc.

Riepilogo

In questo articolo, abbiamo discusso nove strategie per eliminare le risorse che bloccano il rendering. Riassumiamo:

  • Identifica le risorse che bloccano il rendering
  • Non utilizzare le importazioni CSS
  • Carica CSS condizionale con attributi multimediali
  • Rinviare CSS non critici
  • Utilizza gli attributi defer e async per eliminare JavaScript che blocca il rendering
  • Trova e rimuovi CSS e JavaScript non utilizzati
  • Suddividi il codice in bundle più piccoli
  • Minimizza i file CSS e JavaScript
  • Carica i caratteri personalizzati localmente

Per migliorare i tempi di caricamento complessivi della pagina, puoi anche utilizzare i suggerimenti sulle risorse e la direttiva preload. Non eliminano di per sé le risorse di blocco della visualizzazione, ma puoi utilizzarle per migliorare i tempi di caricamento della pagina. Il rendering delle risorse di blocco non interromperà il processo di recupero delle risorse precaricate e puoi anche preconnetterti a Google CDN per velocizzare il caricamento dei caratteri web se non desideri caricarli localmente.