Gran parte del lavoro sulle Web Performance consiste nel rendere più rapido ciò che accade dopo il clic: server più veloce, risorse più leggere, rendering più efficiente. C’è però un modo per fare di più: iniziare a caricare la pagina successiva prima che l’utente la apra. Se il browser ha già scaricato e perfino disegnato la pagina quando l’utente tocca il link, la navigazione diventa di fatto istantanea. È ciò che permette l’API Speculation Rules, con i suoi due strumenti principali, il prefetch e il prerender.
In questo articolo vediamo come funziona, quali risultati può dare sulle Core Web Vitals, come configurarla con prudenza e quali effetti collaterali tenere sotto controllo, dall’analytics al carico sul server.
Prefetch e prerender: la differenza
Con il prefetch il browser scarica in anticipo il documento HTML della pagina successiva e lo tiene da parte. Quando l’utente clicca, il documento è già disponibile: si risparmia il tempo della richiesta al server, cioè il TTFB, ma restano da scaricare immagini, fogli di stile e script e da costruire la pagina.
Con il prerender il browser va molto oltre: carica l’intera pagina in una scheda invisibile, scarica le risorse, esegue il JavaScript e la disegna. Al clic, la pagina già pronta viene semplicemente mostrata. È il caso in cui la navigazione diventa istantanea, ma anche quello che consuma più risorse, sia sul dispositivo sia sul server.
C’è un dettaglio importante per le metriche. Per una pagina prerenderizzata, LCP e le altre metriche di caricamento vengono misurate a partire dal momento in cui l’utente la apre davvero, non da quando il browser ha iniziato a caricarla in background. Una pagina attivata da un prerender riuscito mostra quindi un LCP vicinissimo allo zero, e queste visite rientrano nei dati reali del Chrome UX Report.
Come si scrivono le regole
Le regole si dichiarano con un blocco JSON in un elemento <script type="speculationrules">. Possono indicare un elenco di URL precise oppure, più comodamente, descrivere quali link della pagina sono candidati, con condizioni sugli indirizzi e sui selettori CSS:
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/carrello/*" } },
{ "not": { "href_matches": "/checkout/*" } },
{ "not": { "href_matches": "/*\\?*add-to-cart=*" } },
{ "not": { "href_matches": "/wp-login.php" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}]
}
</script>In questo esempio tutti i link interni sono candidati al prerender, tranne carrello, checkout, link che aggiungono prodotti al carrello, login e qualsiasi link marcato con una classe dedicata. Le regole possono essere inserite nell’HTML oppure inviate con l’intestazione HTTP Speculation-Rules, che punta a un file JSON: utile quando si vuole gestire la configurazione a livello di server o di CDN.
Eagerness: quanto anticipare
La proprietà eagerness stabilisce quando il browser deve iniziare. È la scelta più importante, perché bilancia due esigenze opposte: più si anticipa, più la pagina sarà pronta al clic; più si anticipa, più si caricano pagine che l’utente non aprirà mai.
- immediate: appena le regole vengono lette.
- eager: molto presto, con segnali deboli di interesse.
- moderate: quando il puntatore resta per circa 200 millisecondi su un link.
- conservative: quando l’utente preme il dito o il tasto del mouse sul link, un istante prima del clic vero e proprio.
Per la maggior parte dei siti, moderate per il prerender e conservative per il prefetch rappresentano un buon equilibrio. immediate ed eager vanno riservati a pochi link molto probabili, per esempio il passaggio successivo di un percorso guidato o il primo risultato di una ricerca. Va ricordato che sugli smartphone non esiste il passaggio del mouse: le modalità moderate e conservative partono di fatto al tocco, e il margine di anticipo è minore. Anche un vantaggio di un centinaio di millisecondi, però, si somma a tutte le altre ottimizzazioni.
Supporto e WordPress
Le Speculation Rules sono supportate dai browser basati su Chromium, come Chrome ed Edge. Gli altri browser ignorano semplicemente il blocco, senza errori: per i loro utenti la navigazione resta quella normale. È quindi un miglioramento progressivo, che non richiede alternative.
Dalla versione 6.8, WordPress include il caricamento speculativo in modo nativo: per i visitatori non collegati inserisce regole di prefetch con eagerness conservative, escludendo le aree amministrative. È un punto di partenza prudente, che si può rendere più incisivo passando al prerender o a un’eagerness diversa tramite i filtri previsti dal core, dopo aver verificato gli effetti su analytics e server.
La configurazione si modifica con il filtro wp_speculation_rules_configuration, che accetta la modalità (prefetch o prerender) e l’eagerness. Un secondo filtro, wp_speculation_rules_href_exclude_paths, permette di aggiungere percorsi da escludere, con la stessa sintassi a caratteri jolly usata nelle regole:
// Prerender con eagerness moderate per i visitatori non collegati
add_filter(
'wp_speculation_rules_configuration',
function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
}
);
// Percorsi da non anticipare mai
add_filter(
'wp_speculation_rules_href_exclude_paths',
function ( $paths ) {
$paths[] = '/carrello/*';
$paths[] = '/checkout/*';
$paths[] = '/mio-account/*';
return $paths;
}
);Il core esclude già in automatico l’area amministrativa, i file di login e gli indirizzi con parametri di query, e non genera regole per gli utenti collegati, per i quali le pagine sono spesso personalizzate e non in cache. Anche i singoli link possono essere esclusi aggiungendo la classe no-prerender, che il core riconosce, o no-prefetch per escluderli anche dal semplice prefetch. Chi usa plugin di ottimizzazione che inseriscono proprie regole deve controllare di non trovarsi con due configurazioni sovrapposte: il browser le legge entrambe, e il risultato può essere più aggressivo di quanto previsto.
Gli effetti collaterali da governare
Caricare pagine che l’utente potrebbe non aprire ha conseguenze che vanno previste prima di attivare il prerender su larga scala.
- Link che cambiano lo stato. Un prerender esegue una richiesta GET e, nel caso del prerender, anche il JavaScript della pagina. Link che aggiungono al carrello, disconnettono l’utente, confermano un’iscrizione o registrano un voto non devono mai essere candidati: vanno esclusi esplicitamente, e idealmente non dovrebbero essere semplici link.
- Analytics e pubblicità. Una pagina prerenderizzata ma mai aperta non deve contare come visualizzazione. I principali strumenti di analisi gestiscono già il caso, ma codice personalizzato, pixel e annunci vanno verificati: il browser espone la proprietà
document.prerenderinge l’eventoprerenderingchange, con cui rinviare le azioni al momento dell’attivazione reale. - Carico sul server. Ogni prerender inutile è una richiesta in più. Su un sito con cache di pagina efficiente il costo è minimo; su pagine generate dinamicamente e senza cache può diventare rilevante. Il browser invia l’intestazione
Sec-Purposesulle richieste speculative, così il server può riconoscerle e, se necessario, rifiutarle nei momenti di picco. - Contenuti personalizzati. Pagine che dipendono da dati che cambiano tra il prerender e l’attivazione, come prezzi dinamici o disponibilità, vanno escluse o aggiornate al momento dell’apertura.
// Rinviare un’azione finché la pagina non viene davvero mostrata
function quandoVisibile( azione ) {
if ( document.prerendering ) {
document.addEventListener( 'prerenderingchange', azione, { once: true } );
} else {
azione();
}
}
quandoVisibile( () => inviaVisualizzazione() );Il browser, dal canto suo, mette dei limiti: il numero di prerender contemporanei è ridotto, e sui dispositivi con poca memoria, con la modalità di risparmio dati o di risparmio energetico, le speculazioni possono essere sospese. È un’ulteriore ragione per non considerarle una garanzia, ma un acceleratore opportunistico.
Quali pagine ne beneficiano di più
Il caricamento speculativo dà il meglio dove il percorso dell’utente è prevedibile: dalla pagina di categoria alla scheda prodotto, dall’elenco degli articoli all’articolo, dalla ricerca al primo risultato, dal carrello al checkout, ammesso che quest’ultimo sia gestito con le dovute cautele. Nei siti editoriali e negli e-commerce, dove una parte importante delle visite prosegue su una seconda pagina, l’effetto sull’esperienza è immediato: la sensazione è quella di un’applicazione che risponde istantaneamente.
Non sostituisce però le altre ottimizzazioni. La prima pagina di una visita, quella che arriva da Google o da un social, non può essere prerenderizzata dal sito stesso; e, come abbiamo visto parlando di Critical CSS, per molte visite la prima pagina è anche l’ultima. Le Speculation Rules accelerano la navigazione interna; il caricamento della pagina d’ingresso resta affidato a server, cache e front-end ben ottimizzati.
Il rapporto con la back/forward cache
Il prerender accelera la navigazione in avanti, verso pagine non ancora visitate. Per la navigazione all’indietro esiste un meccanismo complementare, la back/forward cache, che conserva in memoria le pagine appena lasciate e le ripristina istantaneamente quando l’utente preme il tasto Indietro. Insieme coprono una parte molto ampia delle navigazioni interne: quelle in avanti sono anticipate dalle Speculation Rules, quelle all’indietro sono servite dalla memoria del browser.
Le due tecniche condividono anche alcune regole di buona convivenza. Il codice che presume che una pagina venga caricata una sola volta, e che l’utente la veda subito, va rivisto in entrambi i casi: con il prerender la pagina esiste prima di essere vista, con la back/forward cache torna visibile senza essere ricaricata. Gli eventi prerenderingchange e pageshow sono i punti in cui aggiornare analytics, contenuti dinamici e stato dell’interfaccia. Della back/forward cache e dei motivi per cui spesso non funziona parleremo in dettaglio nel prossimo articolo.
Come verificare che funzioni
Nel pannello Application dei DevTools di Chrome, la sezione dedicata al caricamento speculativo mostra le regole lette dalla pagina, le URL candidate, lo stato di ciascuna speculazione e, quando non va a buon fine, il motivo. È lo strumento principale per verificare esclusioni ed eagerness. Nel pannello Network le richieste speculative sono riconoscibili, e sul server l’intestazione Sec-Purpose permette di misurarne il volume nei log.
Sul campo, il Chrome UX Report distingue i tipi di navigazione e indica la quota di visite arrivate tramite prerender: seguirla nel tempo, insieme all’LCP al 75° percentile, mostra l’effetto reale della configurazione. Il monitoraggio degli utenti reali può fare lo stesso a livello di singola pagina, distinguendo le visite prerenderizzate da quelle normali.
Un’adozione graduale
Il percorso consigliato è progressivo. Si parte dal prefetch conservativo, già attivo su WordPress recente, e si verifica che non ci siano effetti indesiderati. Si passa poi al prerender con eagerness moderate sulle sezioni più prevedibili, come dall’elenco degli articoli al singolo articolo o dalla categoria alla scheda prodotto, con esclusioni esplicite per tutto ciò che modifica lo stato. Si controllano analytics, log e carico del server, e solo allora si estende la configurazione al resto del sito. Ogni passo si misura: tipi di navigazione e LCP nei dati reali, richieste speculative sul server, eventuali differenze nei report di marketing.
In sintesi
Le Speculation Rules permettono al browser di scaricare o addirittura disegnare in anticipo la pagina che l’utente sta per aprire. Il prefetch elimina l’attesa del server, il prerender rende la navigazione praticamente istantanea, con un LCP vicino allo zero per le pagine attivate. L’eagerness regola il compromesso tra anticipo e sprechi, e WordPress ne include già una versione prudente.
Come ogni strumento potente, va configurato con attenzione: esclusioni per i link che cambiano lo stato, gestione corretta di analytics e pubblicità, controllo del carico sul server e adozione graduale. Fatto bene, trasforma la navigazione interna del sito in un’esperienza che l’utente percepisce come immediata, ed è uno dei pochi interventi che migliorano la velocità senza rendere più leggero nulla: semplicemente, arrivano prima.
