Pagine a caricamento istantaneo con le Speculation Rules

Scopri come migliorare i Core Web Vitals caricando le pagine all'istante con la Speculation Rules API

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-26

Migliora istantaneamente i Core Web Vitals con la Speculation Rules API

Ti sei mai chiesto perché alcune pagine sembrano caricarsi all'istante? Probabilmente perché quella pagina ha implementato le Speculation Rules.

La Speculation Rules API migliora la velocità dei futuri caricamenti di pagina nelle applicazioni multi-pagina (MPA) effettuando il prefetch o il prerender delle stesse. Puoi configurare le speculation rules per suggerire al browser di fare il prefetch o il prerender dei documenti, ottenendo caricamenti più rapidi o istantanei. Le speculation rules sostituiscono tecniche più vecchie come <link rel="prefetch"> per il prefetch delle risorse o il deprecato <link rel="prerender"> esclusivo di Chrome.

Le speculation rules operano a livello di documento. Sono adatte per le MPA che richiedono navigazioni di pagina complete. Le single-page application (SPA) che usano principalmente chiamate API o aggiornamenti parziali dei contenuti non traggono molto vantaggio da questa API per i loro cambi di rotta interni. Tuttavia, le Speculation Rules possono comunque favorire le SPA effettuando il prerender dello stato iniziale dell'applicazione da una landing page. Questo compensa il tempo di caricamento iniziale.

Ultima revisione di Arjen Karel a febbraio 2026

QuickStart delle Speculation Rules

Sai già cosa sono le speculation rules? Ottimo! Ecco alcuni snippet pronti all'uso per iniziare subito. Scegli lo snippet giusto per te e inseriscilo nell'<head> della tua pagina (puoi cambiare prerender in prefetch o l'eagerness).

<!--
   Speculation rules per WordPress di corewebvitals.io
   esegue il prefetch di tutti i link interni
   ignora i link che corrispondono a wp-login, wp-admin, wp content
   ignora i link con l'attributo nofollow
   ignora i link con query string, ad esempio: /search?q=welcome
-->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [
                { "href_matches": "\\/*" },
                { "not": {
                    "href_matches": [
                        "\\/wp-login.php",
                        "\\/wp-admin\\/*",
                        "\\/*\\\\?*",
                        "\\/wp-content\\/*"
                    ]
                }},
                { "not": {
                    "selector_matches": "a[rel~=\\"nofollow\\"]"
                }}
            ]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Speculation rules attivate da data-preload di corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Suggerimento: se devi creare rapidamente le tue speculation rules, prova lo <b>speculation rules generator</b>

Impatto nel mondo reale

Le speculation rules non sono teoriche. I grandi nomi del web le usano già con risultati misurabili.

Ray-Ban ha implementato regole di prerender sulle pagine di catalogo prodotti con eagerness moderata. Il LCP è sceso da 4,69 a 2,66 secondi su mobile (43% più veloce). I tassi di conversione mobile sono aumentati del 101% e quelli desktop del 156%.

Shopify ha lanciato un prefetch conservativo su tutta la piattaforma a giugno 2025. I loro test A/B hanno mostrato un miglioramento medio di 130 ms su desktop e 180 ms su mobile in tutte le metriche di paint.

Cloudflare Speed Brain, lanciato a settembre 2024, aggiunge di default le speculation rules a tutti i piani Cloudflare. I siti con prefetch riusciti hanno visto una riduzione del LCP del 45%.

Anche Google Search usa le speculation rules: i risultati di ricerca subiscono il prefetch con eagerness eager. Questo fa risparmiare 67 ms sul LCP Android per clic.

Sui siti monitorati da CoreDash, le navigazioni in prerender hanno un LCP p75 di 320 ms rispetto a 1.800 ms delle navigazioni standard sugli stessi siti. È un miglioramento dell'82% da una singola API. I siti che usano le speculation rules con eagerness moderata vedono circa il 28% delle navigazioni completate con prefetch o prerender. Le navigazioni con prefetch mostrano un TTFB p75 di soli 45 ms, perché l'HTML è già nella cache in memoria del browser.

Vantaggi delle Speculation Rules

User Experience (UX) migliorata: prevedendo e precaricando il contenuto, le Speculation Rules garantiscono caricamenti di pagina quasi istantanei, rendendo la navigazione fluida. Questo eguaglia le prestazioni delle single-page application anche per i siti web tradizionali multi-pagina, senza la complessità e la dipendenza da JavaScript. Tempi di caricamento più rapidi significano un'esperienza di navigazione migliore. Aumentano l'engagement dell'utente e riducono la frequenza di rimbalzo.

Vantaggi SEO: una velocità di pagina migliore è un fattore di ranking diretto. Un miglior Time to First Byte porta a un miglior Largest Contentful Paint. L'implementazione delle speculation rules migliora i Core Web Vitals e ti garantisce il bonus di PageSpeed.

Complessità ridotta: in passato, i caricamenti di pagina quasi istantanei erano possibili solo usando una SPA o scrivendo logiche di prefetch custom per le MPA. Il problema di una SPA è il tempo di avvio iniziale, che può essere notevole data la dipendenza da JavaScript, oltre alla maggiore complessità rispetto a una MPA. Le speculation rules non hanno questi problemi. Rendono il caricamento rapido accessibile a più siti web, specialmente quelli incentrati sui contenuti.

L'API semplifica il processo decisionale su quali pagine sottoporre a prerender delegando gran parte della logica al browser. È un netto miglioramento rispetto ai metodi precedenti basati su JavaScript per eseguire i controlli e iniettare le pagine da precaricare. I browser valutano nativamente il contesto dell'utente nel decidere se eseguire il prerender. Ad esempio, memoria ridotta sui dispositivi mobili o modalità di risparmio energetico. Questo adattamento dinamico preserva le risorse dell'utente e assicura un'esperienza più fluida anche con limitazioni.

Altri vantaggi: l'header HTTP Speculation-Rules facilita il deployment tramite Content Delivery Network (CDN), eliminando la necessità di modificare direttamente il contenuto del documento. Il controllo granulare con le document rules ti consente di definire condizioni precise per il prefetch o prerender in base a pattern di URL o selettori CSS. Riduci la specifica manuale degli URL e usi ruleset validi per tutto il sito. L'impostazione "eagerness" fornisce un controllo preciso su quando avviene la speculation. Bilanci la velocità di precaricamento con il consumo di risorse. Questo riduce i precaricamenti inutili e previene gli sprechi.

Supporto dei browser

Le speculation rules sono supportate in Chrome 109+, Edge 109+ e tutti i browser Chromium. Coprono circa il 79% del traffico globale dei browser secondo Can I Use. Firefox ha dichiarato una posizione favorevole agli standard per la parte di prefetch, ma non ha ancora rilasciato il supporto. Safari 26.2 ha un'implementazione funzionante dietro flag, ma non è abilitata di default.

Per i browser che non supportano le speculation rules, puoi usare la feature detection per il fallback su <link rel="prefetch">:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  // il browser supporta le speculation rules
} else {
  // fallback: inietta <link rel="prefetch">
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page.html';
  document.head.append(link);
}

Meccaniche delle Speculation Rules

Le speculation rules sono definite con una struttura JSON e possono essere implementate in due modi:

  • Script inline: includi il JSON dentro un tag <script type="speculationrules"> nell'<head> o nel <body> del documento HTML principale.
  • Header HTTP: distribuisci le regole con l'header HTTP Speculation-Rules nella risposta del documento. L'header punta a un file JSON contenente le regole. Semplifica il deployment su CDN senza dover modificare il contenuto HTML.

La struttura JSON usa gli array "prefetch" e "prerender" per contenere le regole di ciascun tipo di speculative loading. Ogni regola può usare sorgenti diverse: una lista di URL o document rules.

  • urls (una lista di URL): un array di URL di cui fare prefetch o prerender.
  • where (document rules): un oggetto che usa condizioni per determinare quali link sulla pagina devono subire il prefetch o prerender.

Ogni regola è definita come un oggetto che include proprietà come:

  • requires: un array di stringhe per impostare restrizioni sulle speculation. Attualmente, l'unica stringa valida è "anonymous-client-ip-when-cross-origin". Indica che un prefetch cross-origin deve anonimizzare l'indirizzo IP del client.
  • target_hint: una stringa che fornisce un suggerimento sul nome del target navigabile ("_self" o "_blank"). Consente allo user agent di ottimizzare il processo di caricamento.
  • referrer_policy: una referrer policy da applicare agli URL in prefetch o prerender.
  • relative_to (solo per sorgente "list"): specifica se gli URL forniti nell'array "urls" sono relativi all'URL base del documento ("document") o alla posizione del file JSON delle speculation rules ("ruleset").
  • eagerness: controlla l'aggressività con cui il browser esegue il prefetch o prerender. Le impostazioni disponibili sono "immediate", "eager", "moderate" e "conservative", ognuna con trigger differenti.
  • expects_no_vary_search: un suggerimento per indicare al browser se la risposta all'URL speculato varia in base ai parametri di ricerca. Utile per le pagine con parametri UTM o altre query string di tracciamento che non modificano il contenuto.

Infine ogni regola ha un'impostazione eagerness per definire quando eseguire le speculation. Separa il momento dell'esecuzione dagli URL bersaglio. L'impostazione eagerness è disponibile sia per le list rules che per le document rules. Ha quattro valori: immediate, eager, moderate e conservative.

  • immediate: esegue la speculation il prima possibile, non appena il browser legge le speculation rules.
  • eager: su desktop si attiva dopo un hover di 10 millisecondi su un link. Su mobile (da gennaio 2026) si attiva 50 ms dopo che un link entra nel viewport.
  • moderate: esegue la speculation se fai hover su un link per 200 millisecondi. Oppure all'evento pointerdown se questo avviene prima (e su mobile dove non c'è l'evento hover).
  • conservative: esegue la speculation al pointer down o touch down.

Limiti di Chrome

Chrome impone limiti alle speculation concorrenti per prevenire abusi e proteggere le risorse del dispositivo:

  • immediate / eager: fino a 50 prefetch e 10 prerender.
  • moderate / conservative: fino a 2 prefetch e 2 prerender (FIFO: le nuove speculation sostituiscono le più vecchie).

Chrome disabilita completamente le speculation se la modalità Save Data è attiva, il dispositivo è in Energy Saver con batteria scarica o l'utente ha disabilitato l'impostazione "Preload pages".

Prefetch o Prerender

La Speculation Rules API supporta due forme principali di speculative loading: prefetching e prerendering. Entrambe le tecniche accelerano i caricamenti di pagina. Differiscono per complessità e consumo di risorse.

  • Prefetching è la forma più leggera di speculative loading. Scarica e memorizza in cache l'HTML dell'URL di destinazione senza renderizzare la pagina o le sottorisorse. Questo approccio migliora principalmente il Time to First Byte. Un Time to First Byte migliore porta a metriche di paint migliori come il Largest Contentful Paint e il First Contentful Paint.
  • Prerendering fa molto di più che scaricare l'HTML. Scarica l'HTML, tutte le sottorisorse e renderizza l'intera pagina in una scheda nascosta e invisibile. Alla navigazione, la pagina viene visualizzata in modo quasi istantaneo. Questa tecnica migliora il Largest Contentful Paint non solo riducendo il Time to First Byte. Scarica e renderizza anche l'elemento LCP. Il prerendering può eliminare il Cumulative Layout Shift perché le dimensioni delle risorse sono già note dopo il prerendering.

C'è anche una terza opzione: prerender until script. Questa nuova funzionalità (Chrome 144, gennaio 2026) recupera l'HTML e avvia il rendering e il caricamento delle sottorisorse, ma mette in pausa l'esecuzione JavaScript al primo tag script bloccante. Elimina gli effetti collaterali degli script (come l'avvio degli analytics) e continua a precaricare CSS, immagini e font.

Quindi cosa è meglio? Prerendering o Prefetching? Dipende dalla pagina e dal visitatore medio. Il prerendering è intrinsecamente più veloce ma consuma molte più risorse. Sia lato client che server. La scelta tra prerendering e prefetching dipende da:

  • Capacità del dispositivo dell'utente: il prerendering potrebbe non essere l'opzione migliore se molti visitatori usano dispositivi con memoria limitata.
  • Specificità della regola di prerender o prefetch. Alcuni link ricevono più clic e alcune pagine convertono di più. Quelle pagine sono candidati perfetti per una regola di prerender. Altre pagine sono più adatte al prefetch.

Sconsiglio un prerendering eccessivo a causa delle sue richieste in termini di risorse. Questo vale specialmente sui dispositivi mobili o su connessioni lente. Pesa i potenziali vantaggi del prerendering contro il rischio di degrado delle prestazioni e spreco di risorse.

Impostare l'eagerness corretta

L'eagerness da usare dipende dal tuo sito. Per un sito statico molto semplice, una speculation più spinta ha costi bassi e avvantaggia gli utenti. I siti con architetture complesse e payload pesanti dovrebbero fare speculation meno spesso. Aspetta un segnale di intento più chiaro dagli utenti per limitare gli sprechi.

L'impostazione eagerness nella Speculation Rules API determina quando il browser esegue il prefetch o prerender in base alla navigazione prevista. Offre un compromesso tra i massimi vantaggi di precaricamento e il minimo spreco di risorse.

L'eagerness di default per le list rules è immediate. Usa le opzioni moderate e conservative per limitare le list rules a specifici URL con cui l'utente interagisce. Spesso le document rules con una condizione where adeguata sono più adatte.

L'eagerness di default per le document rules è conservative. Un documento può contenere molti URL. Usa immediate o eager per le document rules con cautela.

Quando configuri l'eagerness, tieni conto della user experience, dei costi delle risorse e dei limiti del browser. L'over-speculation affatica la larghezza di banda, la memoria e la CPU. Può degradare le prestazioni, specialmente su reti o dispositivi limitati. Inoltre, le modalità Save Data, la batteria scarica o le estensioni del browser possono sovrascrivere le speculation rules per preservare le risorse.

Verifica e debug delle speculation rules

Per verificare le speculation rules su una pagina, apri i Chrome DevTools. Vai al pannello Application e naviga in Background Services > Speculative Loads > Speculations (apri il riquadro Speculations prima di caricare la pagina da debuggare). Questo pannello fornisce informazioni su:

  • Il numero di speculation riuscite.
  • I singoli URL sottoposti a prerender o prefetch.
  • Lo stato di ogni speculation.

La traccia Network nel pannello Performance mostra l'attività di rete delle risorse in prerender. Non devi cambiare il contesto dei DevTools. Inoltre, puoi spostare il contesto dei DevTools su una pagina in prerender per ispezionarla come una pagina normale.

speculative loads inspector devtools

Monitoraggio e analisi delle Speculation Rules

  • Real User Monitoring (RUM): usa strumenti RUM per misurare l'esperienza reale degli utenti. Osserva metriche come il Largest Contentful Paint (LCP) per valutare l'impatto delle speculation rules sui tempi di caricamento. Cerca miglioramenti del LCP nelle pagine con prerender rispetto a quelle senza.
  • A/B Testing: conduci test A/B per confrontare le configurazioni delle speculation rules. Identifica il setup ottimale per il tuo sito e la tua base di utenti.

speculation rules rum tracking table coredash

Considerazioni

Consumo di risorse: l'abuso della speculation impatta su larghezza di banda, memoria e CPU. Inizia con una eagerness conservative o moderate. Monitora i risultati prima di aumentarla.

Compatibilità dei browser: non tutti i browser supportano la Speculation Rules API. Usa il codice di feature detection visto sopra come fallback per i browser non Chromium.

Privacy: fai attenzione a come le speculation rules rivelano i pattern di navigazione. Implementa misure di privacy adeguate. Per il prefetch cross-origin, usa il requisito "anonymous-client-ip-when-cross-origin" per mascherare l'IP del client tramite il private prefetch proxy di Chrome.

Analytics: le pagine in prerender eseguono JavaScript. Gli script di analytics partono prima dell'effettiva navigazione dell'utente. Google Analytics e Google Publisher Tag gestiscono questo evento in automatico. Per altri tool di analytics, ritarda l'inizializzazione finché la pagina non viene attivata:

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

La Speculation Rules API offre un approccio potente per migliorare prestazioni e user experience delle web app. Comprendendone meccaniche, vantaggi e limiti, puoi usare questa API per creare siti più veloci e coinvolgenti.

Speculation Rules e WordPress

A partire da WordPress 6.8 (aprile 2025), le speculation rules sono integrate in WordPress Core. La configurazione di default usa il prefetch con eagerness conservative. Si applica a tutte le pagine frontend quando il visitatore non è loggato e i permalink sono attivi.

Il team WordPress Core Performance mantiene anche un plugin Speculative Loading indipendente (oltre 40.000 installazioni attive). Offre maggiore controllo. Il plugin fornisce due gruppi di impostazioni:

  • Modalità Speculation: scegli tra prefetch e prerender. Il prerendering garantisce tempi di caricamento più veloci del prefetching. Tuttavia, il prefetching è una scelta più sicura per i contenuti interattivi.
  • Eagerness: scegli tra conservative (di solito al clic), moderate (di solito all'hover) o eager (al minimo suggerimento). L'impostazione eagerness determina la velocità di attivazione degli speculative load.

Puoi escludere percorsi specifici dalle speculation con un filtro PHP:

add_filter(
  'plsr_speculation_rules_href_exclude_paths',
  function($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    return $paths;
  }
);

Per altri metodi per differire gli script e ottimizzare il caricamento, consulta la nostra guida completa.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Porto i siti a passare i Core Web Vitals.

Oltre 500K pagine per grandi editori e piattaforme e-commerce in Europa. Scrivo io il fix e lo verifico con dati reali dal campo.

Come lavoro
Pagine a caricamento istantaneo con le Speculation Rules Core Web Vitals Pagine a caricamento istantaneo con le Speculation Rules