Skip to content

Quando si apre una pagina web, il browser richiede il documento HTML da un server, ne analizza il contenuto e invia richieste separate per qualsiasi risorsa di riferimento. In qualità di sviluppatore, conosci già tutte le risorse di cui la tua pagina ha bisogno e quali sono le più importanti. È possibile utilizzare tale conoscenza per richiedere le risorse critiche in anticipo e accelerare il processo di caricamento.

Questo post spiega come ottenerlo con <link rel=”preload”>.

Come funziona il preload

Il preload è più adatto per le risorse normalmente scoperte in ritardo dal browser, come ad esempio un font definito via @font-face in un file CSS. In questo caso il browser scarica il font solo dopo aver finito di scaricare e leggere il foglio di stile.

Precaricando una certa risorsa, stai dicendo al browser che vorresti recuperarla prima di quanto altrimenti il browser la scoprirebbe perché sei certo che sia importante per la pagina corrente.

La “critical request chain” (catena di richieste critiche) rappresenta l’ordine delle risorse a cui viene assegnata la priorità e recuperate dal browser. Lighthouse identifica le risorse che si trovano al terzo livello di questa catena come scoperte tardivamente. È possibile utilizzare il controllo delle richieste critiche di Lighthouse per identificare le risorse da precaricare con preload.

Puoi precaricare le risorse aggiungendo un tag <link> con rel=”preload” all’inizio del documento HTML:

<link rel="preload" as="script" href="critical.js">

Il browser memorizza nella cache le risorse precaricate in modo che siano immediatamente disponibili quando necessario, ma non esegue gli script né applica i fogli di stile.

I suggerimenti sulle risorse, ad esempio preconnect e prefetch, vengono eseguiti come il browser ritiene opportuno. Il preload, invece, è obbligatorio per il browser. I browser moderni sono già abbastanza bravi a dare la priorità alle risorse, ecco perché è importante utilizzare il preload con parsimonia e precaricare solo le risorse più critiche.

I preload inutilizzati attivano un avviso della console in Chrome, circa 3 secondi dopo l’evento di caricamento.

Il preload è simile al prefetch, le sostanziali differenze sono che:

  • Preload è un recupero dichiarativo, che ti consente di forzare il browser a effettuare una richiesta per una risorsa senza bloccare l’evento di caricamento del documento.
  • Prefetch è un suggerimento per il browser che potrebbe essere necessaria una risorsa, ma delega al browser la decisione se e quando caricarla è una buona idea o meno.

Casi pratici di utilizzo

Preload dei file CSS

Se stai usando l’approccio con critical CSS, dividi il tuo CSS in due parti. Il CSS critico richiesto per il rendering del contenuto above the fold è inline nella sezione <head> del documento HTML, e il CSS non critico è solitamente caricato in modo lazy con JavaScript. Attendere l’esecuzione di JavaScript prima di caricare CSS non critici può causare ritardi nel rendering quando gli utenti scorrono, quindi è una buona idea utilizzare <link rel=”preload”> per avviare il download prima.

Preload dei file JavaScript

Poiché i browser non eseguono file precaricati, il preload è utile per separare il recupero dall’esecuzione, il che può migliorare metriche come Time to Interactive. Il preload funziona meglio se dividi i tuoi bundle JavaScript e precarichi solo i blocchi critici.

Indicazione per attivare il Server Push

Nginx oggi supporta il Server Push, funzionalità introdotta dal protocollo HTTP/2 e che può essere attivata se nell’intestazione HTTP appare il link a risorse in preload. Il discorso sul Server Push è abbastanza lungo quindi ti consiglio di leggere la pagina appena linkata se vuoi approfondire.

Come implementare rel=preload

Il modo più semplice per implementare il preload è aggiungere un tag <link> alla sezione <head> del documento HTML:

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

Fornire l’attributo as aiuta il browser a impostare la priorità della risorsa precaricata in base al suo tipo, impostare le intestazioni corrette e determinare se la risorsa esiste già nella cache. I valori accettati per questo attributo includono: script, style, font, image e altri.

Attenzione: omettere l’attributo as o inserire un valore non valido equivale a una richiesta XHR, in cui il browser non sa cosa sta recuperando e quindi non può determinare la priorità corretta. Può anche causare un doppio recupero di alcune risorse, come gli script.

Alcuni tipi di risorse, come i caratteri, vengono caricati in modalità anonima. Per quelli devi impostare l’attributo crossorigin con preload:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

Attenzione: i caratteri precaricati senza l’attributo crossorigin verranno recuperati due volte!

Gli elementi <link> accettano anche un attributo type, che contiene il tipo MIME della risorsa collegata. I browser utilizzano il valore dell’attributo type per assicurarsi che le risorse vengano precaricate solo se il loro tipo di file è supportato. Se un browser non supporta il tipo di risorsa specificato, ignorerà il <link rel=”preload”>.

Puoi anche precaricare qualsiasi tipo di risorsa tramite l’intestazione HTTP Link:

Link: </css/style.css>; rel="preload"; as="style"

Un vantaggio di specificare il precaricamento nell’intestazione HTTP è che il browser non ha bisogno di analizzare il documento per scoprirlo, il che può offrire piccoli miglioramenti in alcuni casi.

Precaricamento dei moduli JavaScript con webpack

Se stai utilizzando un bundler di moduli che crea file di build della tua applicazione, devi controllare se supporta l’iniezione di tag di preload. Con la versione webpack 4.6.0 o successiva, il preload è supportato tramite l’uso di magic comments all’interno di import():

import(_/* webpackPreload: true */_ "CriticalChunk")

Se stai usando una versione precedente di webpack, usa un plugin di terze parti come preload-webpack-plugin.

Differenze tra Preload e Preconnect, dns-prefetch, prefetch e prerender

In questo blog ho descritto diverse tecniche utili per anticipare il caricamento delle risorse critiche nel browser tramite l’intestazione HTTP o meta tag:

  • Il Preload richiede di scaricare dipendenze, come JS, CSS e font. Il preload è più adatto per le risorse normalmente scoperte in ritardo dal browser, ad esempio nelle critical chain requests. Precaricando una certa risorsa, stai dicendo al browser che vorresti recuperarla prima di quanto altrimenti il browser la scoprirebbe perché sei certo che sia importante per la pagina corrente.
  • Il Preconnect e dns-prefetch richiedono di iniziare a stabilire una connessione con il server remoto. È possibile accelerare il tempo di caricamento di 100–500 ms stabilendo connessioni anticipate a importanti origini di terze parti. Questi numeri possono sembrare piccoli, ma fanno la differenza nel modo in cui gli utenti percepiscono le prestazioni della pagina web.
  • Il Prefetch indica al browser una risorsa da scaricare non appena sarà finito il caricamento della pagina attiva. Quando il browser incontra il tag inizierà a richiedere la o le risorse come ad esempio un’immagine o una pagina HTML. Il Prefetch permette di scaricare singole risorse come immagini, pagine HTML, fogli di stile, etc. L’impatto del Prefetch sulla velocità di caricamento della pagina dipende quindi da quale risorsa si pre-carica.
  • Il Prerender è l’unica opzione che non può essere trasmessa via intestazione HTTP. Il prerender chiede al browser di iniziare a renderizzare una nuova pagina. La funzione di prerendering è la più potente delle tecnologie presentate qui, ma comporta anche i maggiori rischi. In sostanza, garantisce che un URL con tutte le risorse statiche necessarie sia completamente caricato e impostato in background.
  • HTTP/2 Server Push è una funzionalità che consente a un server di inviare preventivamente le risorse al client (senza una richiesta corrispondente).
Differenze tra browser resources hints
Differenze tra browser resources hints

Conclusione

Per migliorare la velocità della pagina, precarica le risorse importanti che vengono scoperte in ritardo dal browser. Precaricare tutto sarebbe controproducente, quindi usa il preload con parsimonia e misura l’impatto nell’utilizzo reale.

Articoli correlati

Autore

Commenti |1

Lascia un commento Lascia un commento
  1. Daikin Climatic 2 commenti

    Molto utile l’immagine di comparazione “Differenze tra browser resources hints”. Effettivamente la cosa migliore è sempre quella di misurare l’impatto, con o senza la soluzione, valutando sempre il caso specifico.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ultimi articoli aggiornati

Richiedi un preventivo SEO e Google Ads

Porta il tuo sito web al livello successivo con l’expertise di EVE Milano. La nostra agenzia di Search Marketing ha ricevuto oltre 1123 richieste di preventivo, un segnale chiaro della fiducia che imprenditori e manager, come te, ripongono nella nostra specializzazione tecnica e verticale nella SEO e PPC. Se la tua organizzazione cerca competenze specifiche per emergere nei risultati di Google, noi siamo pronti a fornire quel valore aggiunto. Affidati alla nostra esperienza per fare la differenza.
Richiedi un preventivo

Non perderti altre guide, iscriviti per ricevere un avviso mensile con gli aggiornamenti del blog!

Iscriviti alla newsletter!

Informativa sui cookies

Noi e terze parti selezionate utilizziamo cookie o tecnologie simili per finalità tecniche e, con il tuo consenso, anche per le finalità di esperienza e misurazione come specificato nella cookie policy. Puoi liberamente prestare, rifiutare o revocare il tuo consenso, in qualsiasi momento, accedendo al pannello delle preferenze. Il rifiuto del consenso può rendere non disponibili le relative funzioni. Usa il pulsante “Accetta” per acconsentire. Usa il pulsante “Rifiuta” per continuare senza accettare.