Speculation Rules: prerender e prefetch per navigazioni istantanee

Ottimizzare una singola pagina ha un limite fisico: rete, server e dispositivo richiedono comunque un certo tempo. Esiste però un modo per far apparire istantanea la pagina successiva: prepararla prima che l'utente faccia clic. È l'idea alla base delle Speculation Rules, un'API dei browser basati su Chromium che permette di dichiarare quali pagine precaricare (prefetch) o addirittura prerenderizzare (prerender) in background.

Prefetch e prerender: la differenza

Le due modalità hanno costi e benefici molto diversi.

• Prefetch: il browser scarica in anticipo solo il documento HTML della pagina di destinazione. Al clic risparmia il tempo di rete del documento, ma deve ancora scaricare le sottorisorse, analizzare e disegnare.
• Prerender: il browser carica e rende l'intera pagina in una scheda invisibile, eseguendo anche JavaScript. Al clic la pagina viene semplicemente mostrata, spesso senza attesa percepibile.

Il prerender dà il risultato più impressionante, ma consuma banda, memoria e CPU, e se l'utente non visita la pagina quel lavoro è sprecato. Il prefetch è più leggero e si presta a un uso più ampio.

La sintassi

Le regole si scrivono in JSON dentro un elemento script con un tipo dedicato:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/logout" } },
        { "not": { "selector_matches": ".no-prerender" } }
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Ci sono due modi di indicare le destinazioni:

1. regole a elenco, con un array urls di indirizzi precisi, utili quando sai già quale sarà la prossima pagina, per esempio il secondo passo di una procedura;
2. regole basate sul documento, con la condizione where, che si applicano ai link presenti nella pagina che soddisfano criteri su URL o selettori CSS.

Le regole possono anche essere inviate dal server con l'intestazione HTTP Speculation-Rules, che punta a un file JSON: comodo quando non si vuole toccare l'HTML dei template.

Scegliere il livello di anticipo

Il campo eagerness stabilisce quando il browser deve agire:

Per regole generiche su tutto il sito, moderate è un buon punto di partenza: l'intenzione dell'utente è abbastanza chiara e il tempo guadagnato tra passaggio del mouse e clic è spesso sufficiente. Su dispositivi touch, dove il passaggio del mouse non esiste, il comportamento si adatta a segnali diversi.

Il browser applica comunque dei limiti propri al numero di speculazioni simultanee e può rinunciare in condizioni sfavorevoli, per esempio con risparmio dati attivo o memoria scarsa.

Effetti collaterali da prevedere

Il prerender esegue la pagina come se fosse stata visitata, e questo ha conseguenze.

Analytics e contatori

Se lo script di analytics registra una visualizzazione al caricamento, una pagina prerenderizzata ma mai aperta verrebbe conteggiata. Il codice deve attendere che la pagina diventi davvero visibile:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', avviaAnalytics, { once: true });
} else {
  avviaAnalytics();
}

Molti strumenti di analytics diffusi gestiscono già questo caso, ma conviene verificarlo con il proprio.

Azioni con effetti sul server

Non vanno mai speculati link che modificano qualcosa: disconnessione, aggiunta al carrello tramite URL, conferme, cancellazioni. Escludili esplicitamente con condizioni not, come nell'esempio sopra. Più in generale, una richiesta GET non dovrebbe mai cambiare lo stato, e le Speculation Rules sono un buon motivo per sistemare i casi in cui succede.

Carico del server

Ogni speculazione è una richiesta in più. Il server la riconosce dall'intestazione Sec-Purpose, che contiene prefetch ed eventualmente prerender. Si può usare per registrare queste richieste separatamente o, in caso di sovraccarico, rifiutarle senza danni: il browser farà semplicemente una navigazione normale.

Compatibilità e strategia

Le Speculation Rules sono supportate dai browser basati su Chromium; gli altri ignorano l'elemento script senza errori. È quindi un miglioramento progressivo: chi ha il supporto guadagna velocità, gli altri non perdono nulla.

Una strategia prudente procede per gradi:

1. inizia con prefetch e moderate su tutti i link interni, escludendo le azioni;
2. osserva nei log il volume di richieste speculative e nei dati reali l'effetto su LCP e TTFB delle navigazioni;
3. passa a prerender sulle sezioni dove i benefici sono maggiori, come elenchi e schede prodotto.

In Chrome DevTools, nel pannello Application, la sezione dedicata al caricamento speculativo mostra le regole rilevate, le pagine speculate e l'esito di ciascun tentativo.

In sintesi

• Il prefetch scarica in anticipo il documento; il prerender prepara l'intera pagina.
• Le regole si dichiarano in JSON nell'HTML o con l'intestazione Speculation-Rules.
• moderate è un buon compromesso per regole ampie su tutto il sito.
• Escludi le azioni con effetti sul server e adatta gli analytics a document.prerendering.
• È un miglioramento progressivo: i browser senza supporto lo ignorano.