Quando il preloading dei fogli di stile ha (non ha) senso

Quando il preloading dei fogli di stile ha (non ha) senso

Incontro regolarmente fogli di stile precaricati e molta disinformazione che li circonda. Il preloading di una risorsa (di solito) cambia la sua priorità e il momento in cui viene pianificato il download. Tuttavia, come molte strategie di ottimizzazione che incontro quotidianamente, il preloading dei fogli di stile non ha molto senso nella maggior parte dei casi. In questo articolo, esplorerò quando il preloading dei fogli di stile ha senso e quando potrebbe non essere la scelta migliore.

L'idea del preloading dei fogli di stile:

Prima di addentrarci nelle considerazioni, rivediamo brevemente il concetto di preloading dei fogli di stile. I fogli di stile sono render blocking. Ciò significa che mentre i fogli di stile vengono scaricati la pagina non verrà renderizzata dal browser e tutto ciò che il visitatore vedrà è uno schermo bianco. 

Per minimizzare il tempo necessario a scaricare un foglio di stile, gli sviluppatori a volte ricorrono al preloading dei fogli di stile. Il preloading comporta il recupero anticipato delle risorse critiche, minimizzando la latenza associata al loro caricamento quando sono effettivamente necessarie. Questo si ottiene tipicamente usando il tag <link> con l'attributo rel="preload".

Caso 1: preloading del foglio di stile subito prima della sua dichiarazione.

A volte gli sviluppatori, con tutto il loro entusiasmo, cercano di minimizzare l'impatto del CSS ricaricandolo nell'HTML subito prima della dichiarazione CSS effettiva. Questo apparirà come:

<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">

Ora questo non ha senso per niente e nel migliore dei casi non rallenterai la pagina! Un browser leggerà l'HTML e inizierà a caricare tutte le risorse critiche della pagina, principalmente nell'ordine in cui le trova. Ciò significa che se rimuovessi la riga di preload il browser avrebbe trovato comunque il foglio di stile e avrebbe iniziato a scaricarlo in ogni caso. Hai solo aggiunto una riga in più, tutto qui! Ma la situazione peggiora. I fogli di stile precaricati ricevono una priorità inferiore rispetto ai fogli di stile normali. Quindi nel peggiore dei casi potresti effettivamente rallentare la tua pagina!

3 fogli di stile precaricati

3 fogli di stile normali

Caso 2: preloading del foglio di stile con un link header.

Questa idea è interessante. Possiamo usare il [url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link]server link header[/url] per precaricare un foglio di stile. Questo apparirà così:

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

L'idea qui è far sì che il browser metta in coda il foglio di stile prima di iniziare a parsare l'HTML. Questa è un'idea piuttosto buona e mi piace come ragiona lo sviluppatore che l'ha pensata! Ma sfortunatamente nella vita reale otterrai pochissimi benefici da questo. Stiamo parlando di pochi microsecondi. Sono risultati piuttosto deludenti ma non preoccuparti. Possiamo usare questo passaggio per ottenere dei veri miglioramenti!

Caso 3: 103 early hints per i fogli di stile

Questa è l'unica idea che ti darà effettivamente dei risultati sui Core Web Vitals! Inviare early hints per i fogli di stile migliorerà metriche come il First Contentful Paint e il Largest Contentful Paint.

Gli header 103 early hint vengono inviati prima della risposta HTML effettiva. Ciò significa che mentre stai scaricando l'HTML, il browser può anche iniziare a scaricare i fogli di stile in parallelo.  Lo scenario migliore è che quando l'HTML ha terminato il download, anche i fogli di stile potrebbero essere già stati scaricati. Ciò significa che il tempo di render blocking da quei fogli di stile è pari a zero. E questo può e succede sulle reti più lente! Sulle reti più veloci l'effetto è meno evidente ma usare i 103 early resource hints è comunque più veloce in quasi tutti i casi!

Una risposta 103 early hint appare molto simile a un preload link header. Per usare i 103 early hints dovrai configurare il tuo webserver o il tuo CDN.  

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style

Alcuni CDN come CloudFlare ti permetteranno di attivare un 103 early hint semplicemente impostando un link preload header (come descritto nell'idea 2)

Caso 4: preload dei fogli di stile per ottenere CSS asincrono

Un trucco ben noto per rendere il CSS non render-blocking è precaricare il foglio di stile e una volta caricato aggiungerlo alla pagina. L'idea è semplice e appare così:

<link 
   rel="preload" 
   href="style.css" 
   as="style"
   onload="this.onload=null;this.rel='stylesheet'"
>

Si basa sul normale codice di preload <link rel="preload" as="style" href="style.css"> e aggiunge un event listener onload onload="this.onload=null;this.rel='stylesheet'" che trasforma il link nella sua forma finale <link rel="stylesheet" href="style.css">

Questa è un'altra idea che ha semplicemente senso. Se un foglio di stile non è render blocking il browser può continuare a parsare e renderizzare la pagina senza bisogno di fermarsi e attendere il foglio di stile. Tuttavia, fai attenzione!

• Non rendere asincrono il CSS nel viewport visibile. Questo probabilmente causerà un Cumulative Layout Shift e porterà a una scarsa User Experience
• Considera il compromesso. Il CSS asincrono probabilmente causerà un re-render di diverse parti della pagina. Questo influenzerà metriche come l'Interaction to Next Paint. 

Caso 5: pre-cache dei fogli di stile

In rare occasioni vedo soluzioni ingegnose che cercano di pre-riscaldare i file di cache per le visualizzazioni successive della pagina. E sebbene applauda l'entusiasmo con cui quelle soluzioni sono state create. Per favore NON farlo!

L'idea è semplice: sulla homepage potresti, se volessi, già pre-cacheare gli stili per un'altra pagina. Diciamo la pagina prodotto. A un certo punto dopo il caricamento della pagina, precaricheresti i fogli di stile per aggiungerli alla cache del browser.

function preloadStylesheet(url) {
    var link = document.createElement('link');
    link.rel = 'preload';
    link.href = url;
    link.as = 'style';
    document.head.appendChild(link);
}

window.addEventListener('load', function () {
    preloadStylesheet('cart.css');
    preloadStylesheet('shop.css');
});

A prima vista questo non sembra così male. Su qualsiasi pagina prodotto cart.css e shop.css sono ora disponibili e non bloccheranno più il rendering. Ci sono alcuni motivi per non farlo!

1.  Ci sono modi migliori, per esempio il [url=https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API]speculative prerendering[/url] o l'utilizzo di un service worker.
2. Probabilmente sprecherai risorse e il compromesso non varrà la pena! Ammettiamolo: se il preloading delle risorse fosse facile i browser sarebbero stati migliori in questo. 
3. Soluzioni come questa sono difficili da mantenere e probabilmente causeranno problemi a un certo punto in futuro
4. Dovrai precaricare tutti i fogli di stile, non solo alcuni. Perché tutti i fogli di stile sono render blocking e scaricati in parallelo, anche solo 1 foglio di stile può avere lo stesso effetto di molteplici fogli di stile.