Cos'è lo Speculative Loading? Così WordPress carica le pagine prima del clic

Clicchi su un link e la pagina successiva è semplicemente lì. Nessuna schermata bianca, nessuna attesa. Spesso dietro non c'è un server più veloce, ma un browser che ha giocato d'anticipo. È proprio questo lo Speculative Loading: il browser prova a indovinare quale pagina aprirai dopo e intanto comincia a caricarla. Se ci azzecca, il cambio di pagina sembra istantaneo. Se sbaglia, ha scaricato qualche kilobyte per niente. Da WordPress 6.8 questa tecnica è integrata direttamente in WordPress, e molti gestori di siti non sanno nemmeno che il loro sito la usa già. Qui scopri come funziona, cosa imposta WordPress di default e quando vale la pena intervenire.

Cos'è lo Speculative Loading? Una spiegazione semplice

Speculative Loading, letteralmente caricamento speculativo, è il termine generico per le tecniche con cui un browser richiede delle pagine prima che qualcuno le apra effettivamente. Speculativo perché nessuno sa con certezza se il visitatore cliccherà davvero sul link. Il browser fa una scommessa.

Immagina il barista del bar sotto casa, quello dove passi ogni mattina. Ti vede entrare e comincia a prepararti il cappuccino prima ancora che tu abbia ordinato. Quasi sempre ci prende, e tu hai il tuo cappuccino senza aspettare. Se per una volta ordini un tè, quel cappuccino è andato sprecato. Lo Speculative Loading funziona più o meno allo stesso modo.

L'idea non è nuova. Con <link rel="prefetch"> e <link rel="prerender"> esistevano già anni fa dei suggerimenti con cui i siti potevano consigliare al browser delle pagine da caricare in anticipo, e librerie come instant.page o Quicklink aggiungevano la stessa funzione tramite JavaScript. Niente di tutto questo era davvero affidabile. Chrome ha persino sostituito da tempo il vecchio rel="prerender" con una variante ridotta che non esegue più alcun rendering. Per questo, quando oggi si parla di Speculative Loading, si intende quasi sempre la Speculation Rules API introdotta da Google in Chrome.

E perché tanto impegno? Perché il tempo di caricamento incide direttamente sui Core Web Vitals. Se una pagina viene preparata completamente in background, il Largest Contentful Paint (LCP) per il visitatore è praticamente zero. Più veloce di così non si può.

Come funziona la Speculation Rules API?

Il sito fornisce al browser alcune regole. Queste sono scritte in JSON all'interno di un blocco di tipo speculationrules. Ecco come appare una regola semplice:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Tradotto: tutti i link di questo sito possono essere renderizzati in anticipo non appena il visitatore mostra interesse, per esempio soffermandosi un attimo con il mouse sul link. Le regole di questo tipo, che si riferiscono ai link presenti nel documento, si chiamano Document Rules. Esistono poi le List Rules, con cui fornisci al browser un elenco fisso di URL, per esempio la pagina successiva di una serie di articoli.

Due aspetti rendono l'API piacevolmente semplice. Primo: l'ultima parola spetta al browser, che decide se seguire la regola. Se la batteria è quasi scarica o la memoria scarseggia, lascia perdere. Secondo: i browser che non conoscono l'API ignorano semplicemente questo blocco. Quindi non si può rompere nulla. Tra l'altro, invece che nell'HTML, le regole si possono inviare anche tramite un header nella risposta del server (Speculation-Rules), cosa che sfruttano soprattutto le CDN.

Prefetch o Prerender: qual è la differenza?

La Speculation Rules API prevede due modalità, e la differenza è più grande di quanto facciano pensare i nomi.

Con il Prefetch il browser scarica solo l'HTML puro della pagina di destinazione e lo mette da parte per un po'. Immagini, fogli di stile e script restano esclusi, e non viene eseguito nulla. Quando poi il visitatore clicca, si risparmia l'attesa del server, cioè in sostanza il Time to First Byte. Il resto il browser lo carica come al solito. Il Prefetch costa poco e non ha quasi effetti collaterali.

Con il Prerender il browser va fino in fondo. Carica la pagina completa, con immagini, CSS e JavaScript, in una scheda invisibile e la costruisce del tutto. Al clic sostituisce semplicemente la pagina visibile. Per il visitatore è come se la pagina fosse sempre stata lì. Il prezzo: più traffico dati, più potenza di calcolo, e JavaScript viene eseguito anche se il visitatore forse quella pagina non la vedrà mai. Per motivi di sicurezza, il Prerender funziona di default solo per le pagine dello stesso dominio.

Come regola pratica vale questo: il Prefetch è l'impostazione di base sicura, il Prerender è il turbo per le pagine che con ogni probabilità verranno aperte subito dopo.

Non confondere nessuno dei due con preload e preconnect. Questi suggerimenti accelerano i file della pagina corrente, come i font o l'immagine più grande. Come usarli nel modo giusto lo spieghiamo nel nostro articolo Usare preload e preconnect per font e asset in WordPress.

Quando il browser carica in anticipo? I quattro livelli di eagerness

Con eagerness (letteralmente zelo) stabilisci quanto presto il browser può entrare in azione. Più presto parte, maggiore è il tempo guadagnato, ma più spesso il browser sbaglia.

• immediate: subito, non appena il browser legge la regola. Ha senso solo per una manciata di URL di cui sei molto sicuro.
• eager: quasi altrettanto presto. Nelle ultime versioni Chrome ha affinato il comportamento, così questo livello si colloca tra immediate e moderate.
• moderate: su desktop la speculazione parte quando il puntatore del mouse resta su un link per circa 200 millisecondi, oppure prima, se viene premuto il tasto del mouse. Sugli smartphone, dove l'hover non esiste, Chrome usa altri segnali come il tocco.
• conservative: solo quando il visitatore clicca davvero, o più precisamente nel momento in cui il tasto del mouse o il dito si abbassano. Prima che il clic sia completato passa solo una frazione di secondo. Il vantaggio è piccolo, ma in compenso quasi nessuna speculazione va a vuoto.

Inoltre Chrome stesso fa in modo che nessuno esageri. Con moderate e conservative il browser tiene pronte al massimo due speculazioni alla volta e scarta la più vecchia non appena ne arriva una nuova. Con immediate ed eager sono consentiti fino a 50 Prefetch e 10 Prerender. In modalità risparmio energetico, con il risparmio dati attivo, con poca memoria disponibile o se l'utente ha disattivato nelle impostazioni il precaricamento delle pagine, Chrome non specula affatto. I dettagli li descrive Google nella documentazione per Chrome.

Speculative Loading in WordPress: cosa succede automaticamente dalla versione 6.8

Il Performance Team di WordPress ha testato la funzione dapprima come plugin autonomo chiamato Speculative Loading. Era attivo su oltre 50.000 siti e, secondo i dati di HTTP Archive e del Chrome UX Report, su questi siti il tasso di superamento del Largest Contentful Paint è migliorato in mediana di circa l'1,9 percento. Sembra poco, ma per una funzione che non richiede alcun lavoro è un bel guadagno. Con WordPress 6.8, nell'aprile 2025, il tutto è passato nel core. L'impostazione predefinita è volutamente prudente:

• Modalità prefetch, eagerness conservative. Viene quindi caricato solo l'HTML, e solo quando un clic è già iniziato.
• Solo per i visitatori non loggati. Chi ha effettuato l'accesso vede la barra degli strumenti e spesso contenuti personali. Pagine del genere non finiscono in nessuna cache e sarebbero costose da caricare in anticipo.
• Solo con i Pretty Permalinks. Se in Impostazioni › Permalink è ancora selezionata l'opzione Semplice, la funzione resta spenta.
• Niente URL con parametri. Tutto ciò che ha un punto interrogativo nell'indirizzo viene escluso, per esempio la ricerca o un link come ?add-to-cart=123 in un negozio online. Anche l'area di amministrazione, la pagina di login e i link con rel="nofollow" sono tabù.
• Eccezioni tramite classe. I link con la classe no-prefetch, o i link all'interno di un blocco con questa classe, non vengono mai caricati in anticipo. La classe no-prerender esclude soltanto il prerendering.

Perché tanta cautela? Il plugin usava ancora come predefinito il Prerender con moderate e otteneva così più velocità. Ma con milioni di siti e innumerevoli combinazioni di temi e plugin, per il team il rischio che JavaScript venisse eseguito su pagine che nessuno visita mai era troppo alto. È così che il team lo motiva anche nell'annuncio ufficiale. Se vuoi di più, puoi continuare a installare il plugin Speculative Loading. Aggiunge in Impostazioni › Lettura un'interfaccia in cui cambi modalità ed eagerness senza codice e, volendo, attivi la funzione anche per gli utenti loggati.

Come personalizzare o disattivare lo Speculative Loading in WordPress

Senza plugin si passa dai filtri. I seguenti frammenti di codice vanno nel functions.php del tuo Child Theme o, meglio ancora, in un piccolo plugin tuo, così sopravvivono a un cambio di tema.

Usare il Prerender invece del Prefetch:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

Il controllo con is_array() è importante. Per gli utenti loggati e per i siti senza Pretty Permalinks WordPress passa qui null, e grazie al controllo in questi casi la funzione resta disattivata.

Escludere determinate sezioni:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
	$paths[] = '/go/*';
	if ( 'prerender' === $mode ) {
		$paths[] = '/carrello/*';
	}
	return $paths;
}, 10, 2 );

Candidati tipici sono i reindirizzamenti dei link di affiliazione che contano un clic quando vengono aperti, un carrello o le pagine il cui contenuto cambia di continuo. I percorsi si indicano in modo relativo alla homepage, un'eventuale sottodirectory la aggiunge WordPress da solo. Con il secondo parametro puoi escludere dei percorsi solo per una modalità, nell'esempio il carrello solo per il prerendering.

Escludere singoli link: Assegna al link o al blocco che lo contiene la classe no-prefetch. Nell'editor a blocchi lo fai in Avanzate, nel campo per le classi CSS aggiuntive, senza scrivere codice.

Disattivare completamente lo Speculative Loading:

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

Spegni del tutto la funzione solo se hai un motivo concreto per farlo. Con l'impostazione predefinita non costa praticamente nulla.

Quali svantaggi ha lo Speculative Loading?

Il guadagno di velocità non è del tutto gratuito. Questi sono i punti che dovresti conoscere:

Più carico sul server. Ogni speculazione è una richiesta vera e propria. Se una Page Cache consegna la pagina già pronta, il server quasi non se ne accorge. Senza cache, ogni Prefetch avvia PHP e query al database come se fosse arrivato un visitatore reale. Su uno Shared Hosting dalle risorse risicate, un'impostazione aggressiva come immediate o eager può quindi farsi sentire. Lo stesso vale, in piccolo, per i visitatori con un piano dati limitato.

Link che fanno scattare qualcosa. In teoria un semplice link non dovrebbe mai modificare nulla. In pratica alcuni lo fanno lo stesso: link di logout, contatori per i link di affiliazione, valutazioni con un clic o un rapido “Aggiungi al carrello”. Escludendo tutti gli URL con parametri, WordPress intercetta molti di questi casi, ma non gli indirizzi puliti come /go/partner/. Questi dovresti escluderli in modo mirato.

Statistiche falsate. Il Prefetch non esegue JavaScript, quindi strumenti di analisi come Matomo o Google Analytics non se ne accorgono. Le statistiche ricavate dai file di log del server, come quelle nel pannello cliente di molti provider di hosting, potrebbero invece contare le richieste come visualizzazioni. Con il Prerender, JavaScript viene eseguito davvero. Google Analytics e Google Publisher Tag aspettano da soli che la pagina venga effettivamente mostrata. Gli strumenti che non lo fanno contano visite mai avvenute. Per i tuoi script c'è un semplice controllo:

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

Sul server riconosci le richieste speculative dall'header Sec-Purpose, che ha il valore prefetch oppure prefetch;prerender.

I contenuti possono essere un po' datati. Chrome conserva le pagine caricate in anticipo per alcuni minuti. Con conservative non ha importanza, perché il clic arriva subito. Con i livelli più anticipati, una pagina con contenuti che cambiano rapidamente, come una diretta testuale, al momento dell'apertura può essere già vecchia di qualche minuto.

Quali browser supportano lo Speculative Loading?

Chrome supporta completamente la Speculation Rules API, così come Edge, Opera e gli altri browser basati su Chromium. Safari sta lavorando a una propria implementazione, che però nelle versioni più recenti è ancora nascosta dietro un'opzione per sviluppatori. Firefox finora non supporta l'API.

Sembra una lacuna, ma in pratica non è un problema. Dato che i browser ignorano le regole che non capiscono, chi usa Chrome ne trae vantaggio e per tutti gli altri semplicemente non cambia nulla. Del resto, per la maggior parte dei siti Chrome è di gran lunga la fetta più grande. Già all'inizio del 2025, quindi ancora prima del debutto in WordPress, secondo il WordPress Performance Team oltre l'8 percento di tutte le visualizzazioni di pagina in Chrome sfruttava le Speculation Rules.

Come verifico se lo Speculative Loading è attivo sul mio sito?

Tre modi rapidi:

1. Guarda il codice sorgente. Apri il tuo sito in una finestra privata, così non hai effettuato l'accesso, e cerca speculationrules nel codice sorgente. WordPress inserisce le regole nel footer.
2. Usa i Chrome DevTools. Nella scheda Application trovi, sotto Background services, la sezione Speculative loads. Lì vedi le regole attive, quali URL sono stati caricati in anticipo e perché una speculazione non è andata a buon fine.
3. Controlla gli header. Se una CDN aggiunge regole proprie, per esempio Cloudflare con la funzione Speed Brain, queste non si trovano nell'HTML ma nell'header Speculation-Rules della risposta. In quel caso possono funzionare due set di regole in parallelo. Non fa danni, ma è meglio saperlo prima di cambiare qualcosa da una parte e chiederti perché non succede niente.

Come InspectWP ti aiuta a tenere d'occhio il tempo di caricamento e i Resource Hints

Il report di InspectWP ti mostra innanzitutto quale versione di WordPress gira sul tuo sito. Dalla 6.8 in poi sai quindi che lo Speculative Loading è attivo di default per i visitatori non loggati, purché i Pretty Permalinks siano abilitati. Nella sezione HTML il report elenca inoltre i classici Resource Hints, cioè Prefetch, DNS Prefetch, Preconnect e Prerender, e segnala le voci che compaiono più volte nel codice sorgente. Spesso è il segno di plugin che si intralciano a vicenda. Se lì compare ancora un vecchio rel="prerender", è una buona occasione per passare alla Speculation Rules API. Dato che le pagine caricate in anticipo costano molto meno con una cache, vale la pena dare un'occhiata anche ai plugin di Caching rilevati e agli header della risposta del server. Un report gratuito ti mostra in poco tempo a che punto è il tuo sito.