Pagine a caricamento istantaneo con le Speculation Rules

Scopri come migliorare i Core Web Vitals rendendo il caricamento delle pagine istantaneo con la nuova Speculation Rules API

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

Migliora istantaneamente i Core Web Vitals con la 'Speculation Rules API'

Ti sei mai chiesto perché alcune pagine sembrano caricarsi istantaneamente? Probabilmente è perché quella pagina ha implementato le Speculation Rules!

La Speculation Rules API migliora la velocità di caricamento delle pagine future nelle applicazioni multi-pagina (MPA) tramite il prefetching o addirittura il prerendering. Gli sviluppatori possono configurare le speculation rules per suggerire al browser di eseguire il prefetch o il prerender dei documenti per caricamenti più rapidi (o istantanei). Le speculation rules sostituiscono tecniche precedenti come `<link rel="prefetch">` per il prefetching delle risorse o la funzionalità deprecata esclusiva di Chrome `<link rel="prerender">`.

Le speculation rules operano a livello di documento, rendendole adatte alle MPA che prevedono navigazioni a pagina intera. Le single-page application (SPA) che utilizzano principalmente chiamate API o aggiornamenti parziali del contenuto non trarrebbero altrettanto beneficio da questa API per i loro cambi di rotta interni. Tuttavia, le Speculation Rules possono comunque beneficiare le SPA eseguendo il prerendering dello stato iniziale dell'applicazione da una landing page, potenzialmente compensando il tempo di caricamento iniziale.

Speculation Rules - Guida rapida

Sai già cosa sono le speculation rules? Perfetto! Ecco alcuni snippet pronti all'uso per iniziare subito. Scegli lo snippet più adatto a te e inseriscilo nell'<head> della tua pagina (sentiti libero di cambiare preload con prefetch e/o l'eagerness)! 

<!-- 
   WordPress speculation rules by corewebvitals.io 
   prefetches all internal links
   skips links that match wp-login, wp-admin, wp content 
   skips links that have the nofollow attribute
   skips links that have a questy string for example: /search->
<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>
<!-- Data-preload triggered speculation rules by corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Suggerimento: se hai bisogno di creare rapidamente le tue speculation rules, perché non provare il generatore di speculation rules

Vantaggi delle Speculation Rules


Migliore user Experience (UX): Prevedendo e precaricando i contenuti, le Speculation Rules garantiscono caricamenti di pagina quasi istantanei, rendendo la navigazione fluida per gli utenti. Questo eguaglia le prestazioni delle single-page application anche per i siti web multi-pagina tradizionali, senza la complessità e la dipendenza da JavaScript. Tempi di caricamento più rapidi significano una migliore esperienza di navigazione, con maggiore probabilità di aumentare il coinvolgimento degli utenti e ridurre la frequenza di rimbalzo.

Vantaggi SEO: Poiché la velocità della pagina migliorata è un fattore di ranking diretto e un migliore Time to First Byte si tradurrà in un migliore Largest Contentful Paint, implementare le speculation rules migliorerà sicuramente i Core Web Vitals e ti darà quel bonus di pagespeed.

Complessità ridotta: I caricamenti quasi istantanei delle pagine erano possibili utilizzando una SPA o scrivendo logiche personalizzate di prefetch per le MPA.
Per molti casi d'uso, lo svantaggio di una SPA è il tempo di avvio iniziale, che può essere considerevole poiché dipendono fortemente da JavaScript, e la maggiore complessità rispetto a una MPA. Le speculation rules non hanno questi problemi. Questo rende i caricamenti rapidi raggiungibili per una gamma più ampia di siti web, specialmente quelli incentrati sui contenuti.
L'API semplifica anche il processo di decisione su quali pagine eseguire il prerender, delegando gran parte della logica al browser. Questo è un enorme miglioramento rispetto ai metodi precedenti che si affidavano a JavaScript per effettuare questi controlli e iniettare le pagine da precaricare. I browser possono considerare nativamente il contesto dell'utente, come la memoria limitata sui dispositivi mobili o la modalità risparmio energetico, quando decidono se eseguire il prerender. Questo adattamento dinamico aiuta a conservare le risorse dell'utente e garantisce un'esperienza più fluida anche in condizioni di vincoli.

Altri vantaggi: L'header HTTP Speculation-Rules consente un deployment più semplice tramite Content Delivery Network (CDN), eliminando la necessità di modificare direttamente il contenuto del documento. Il controllo granulare con le Document Rules permette agli sviluppatori di definire condizioni precise per il prefetching o il prerendering basate su pattern URL o selettori CSS. Questo riduce la specifica manuale degli URL e consente set di speculation rules a livello di sito. L'impostazione "eagerness" fornisce un controllo dettagliato su quando la speculation avviene, bilanciando la velocità di precaricamento con il consumo di risorse. Questo aiuta a ridurre il precaricamento non necessario e previene lo spreco di risorse.

Meccaniche delle Speculation Rules

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

  • Script Inline: Includere il JSON all'interno di un tag `<script type="speculationrules">` nell'`<head>` o nel `<body>` del documento HTML principale.
  • Header HTTP: Distribuire le regole utilizzando l'header HTTP `Speculation-Rules` nella risposta del documento. Questo header punta a un file JSON contenente le regole, facilitando i deployment CDN senza modificare direttamente il contenuto HTML.

La struttura JSON utilizza array "prefetch" e "prerender" per contenere le regole per ogni tipo di caricamento speculativo. Ogni regola può utilizzare diverse sorgenti: una lista di URL o document rules

  • urls (una lista di URL) Un array di URL da prefetchare o prerenderizzare.
  • where (document rules) Un oggetto che utilizza condizioni per determinare quali link sulla pagina devono essere prefetchati o prerenderizzati.

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

  • requires Un array di stringhe per impostare restrizioni sulle speculazioni. Attualmente, l'unica stringa valida è "anonymous-client-ip-when-cross-origin", che 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, permettendo allo user agent di ottimizzare il processo di caricamento. Non ha implicazioni normative oltre ad essere un suggerimento.
  • referrer_policy Una referrer policy da applicare agli URL prefetchati o prerenderizzati.
  • 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 quanto aggressivamente il browser deve eseguire il prefetch o il prerender. Le impostazioni disponibili sono "immediate", "eager", "moderate" e "conservative", ciascuna con trigger diversi.
  • expects_no_vary_search Una stringa utilizzata per fornire un suggerimento sulla variazione della ricerca URL, permettendo agli sviluppatori di segnalare se l'URL speculato dovrebbe avere una risposta diversa in base ai parametri di ricerca.

Infine, ogni regola ha un'impostazione di eagerness che consente di definire quando le speculazioni devono essere eseguite, separando quando speculare da quali URL su cui eseguire le speculazioni. L'impostazione eagerness è disponibile sia per le regole list che document e ha quattro impostazioni: immediate, eager, moderate e conservative.

  • immediate: Viene utilizzato per speculare il prima possibile, non appena le speculation rules vengono rilevate.
  • eager: Attualmente si comporta in modo identico all'impostazione immediate, ma in futuro sarà posizionato tra immediate e moderate.
  • moderate: Esegue le speculazioni se passi il mouse sopra un link per 200 millisecondi (o sull'evento pointerdown se avviene prima, e sui dispositivi mobili dove non c'è l'evento hover).
  • conservative: Specula al pointer o touch down.

Prefetch o Prerender

La Speculation Rules API supporta due forme principali di caricamento speculativo: prefetching e prerendering. Sebbene entrambe le tecniche possano risultare in caricamenti di pagina più rapidi, differiscono per complessità e consumo di risorse.

  • Prefetching, è la forma 'più leggera' di caricamento speculativo. Scarica e memorizza nella cache l'HTML dell'URL di destinazione senza renderizzare la pagina o le sue sottorisorse. Questo approccio migliora principalmente il Time To First Byte. Un Time to First Byte migliorato porterà a metriche di rendering migliori come il Largest Contentful Paint e il First Contentful Paint.
  • Prerendering fa molto di più del solo download dell'HTML. Scarica l'HTML, tutte le sottorisorse e renderizza l'intera pagina in una scheda nascosta e invisibile. Alla navigazione verso questa pagina, il risultato è una visualizzazione quasi istantanea. Questa tecnica migliora il Largest Contentful Paint in più modi rispetto al solo miglioramento del Time to First Byte. Scarica e renderizza anche l'elemento LCP. Il prerendering può anche eliminare il Cumulative Layout Shift perché le dimensioni delle risorse sono già note dopo il prerendering.

Quindi cosa è meglio? Prerendering o Prefetching? Dipende dalla pagina e dal 'visitatore medio'. Sebbene il prerendering possa essere più veloce per design, utilizza anche molte più risorse, sia lato client che lato server. La scelta tra prerendering o prefetching dipende da:

  • Capacità del dispositivo dell'utente: Il prerendering potrebbe non essere la scelta migliore se un'alta percentuale di visitatori naviga su dispositivi con memoria limitata
  • Specificità delle regole di prerender o prefetch. 'Alcuni link hanno più probabilità di essere cliccati e alcune pagine hanno più probabilità di convertire'. Quelle pagine sono candidati perfetti per una regola di prerender. Altre pagine potrebbero essere più adatte al prefetch.

CoreWebVitals.io vuole mettere in guardia contro un uso eccessivo del prerendering a causa delle sue richieste di risorse, in particolare sui dispositivi mobili o con connessioni più lente. I potenziali benefici del prerendering devono essere bilanciati con il rischio di degradazione delle prestazioni e spreco di risorse.

Impostare la giusta 'Eagerness' - l'atto di bilanciamento

Quale impostazione di eagerness utilizzare dipende dal tuo sito. Per un sito statico molto semplice, speculare in modo più aggressivo può avere un costo minimo ed essere vantaggioso per gli utenti. I siti con architetture più complesse e payload di pagina più pesanti potrebbero preferire ridurre gli sprechi speculando meno frequentemente fino a ottenere un segnale più positivo di intento da parte degli utenti per limitare gli sprechi.

L'impostazione eagerness nella Speculation Rules API influenza quando un browser deve eseguire il prefetch o il prerender dei contenuti in base alla navigazione prevista dell'utente. Questa impostazione offre un compromesso tra massimizzare i benefici del precaricamento e minimizzare lo spreco di risorse.

L'eagerness predefinita per le regole list è immediate. Le opzioni moderate e conservative possono essere utilizzate per limitare le regole list agli URL con cui un utente interagisce in una lista specifica. In molti casi, le document rules con una condizione where appropriata possono essere più adatte.

L'eagerness predefinita per le document rules è conservative. Dato che un documento può contenere molti URL, l'uso di immediate o eager per le document rules deve essere fatto con cautela.

La scelta dell'eagerness dipende dalla struttura del sito web, dai pattern di comportamento degli utenti e dalla valutazione dello sviluppatore sul potenziale consumo di risorse rispetto ai benefici per l'user experience. Ad esempio, un sito statico semplice potrebbe beneficiare di un'impostazione "eager", portando a tempi di caricamento più rapidi. Al contrario, siti web con architetture complesse e payload di pagina impegnativi possono optare per un approccio meno aggressivo "moderate" o "conservative" per limitare l'uso delle risorse fino a quando non viene rilevato un intento più chiaro dell'utente.

Quando si configura l'eagerness, gli sviluppatori dovrebbero considerare l'user experience, i costi delle risorse e le limitazioni del browser. Una speculazione eccessiva può gravare sulla larghezza di banda, la memoria e la CPU dell'utente, potenzialmente degradando le prestazioni, specialmente su reti o dispositivi con vincoli. Chrome impone limiti alle pagine prefetchate e prerenderizzate contemporaneamente per mitigare l'uso eccessivo. Inoltre, fattori come le modalità Data Saver configurate dall'utente, condizioni di batteria scarica o estensioni del browser possono sovrascrivere le speculation rules, dando priorità alla conservazione delle risorse.

Verificare e debuggare le speculation rules 

Per verificare eventuali speculation rules su una pagina, apri Chrome DevTools, vai al pannello Application e naviga su Background Services > Speculative Loads > Speculations. (apri il pannello Speculations prima di caricare la pagina che vuoi debuggare) Questo pannello fornisce informazioni su:

  • Il numero di speculazioni riuscite.
  • I singoli URL in fase di prerendering o prefetching.
  • Lo stato di ogni speculazione.

La traccia Network nel pannello Performance mostra l'attività di rete relativa alle risorse prerenderizzate senza necessità di cambiare il contesto di DevTools. Inoltre, puoi cambiare il contesto di DevTools a una pagina prerenderizzata per ispezionarla come una pagina normale.

speculative loads inspector devtools

Monitoraggio e analisi delle Speculation Rules 

  • Real User Monitoring (RUM): Utilizza strumenti RUM per misurare l'esperienza reale dell'utente. Osserva metriche come il Largest Contentful Paint (LCP) per valutare l'impatto delle speculation rules sui tempi di caricamento della pagina. Cerca miglioramenti nel LCP per le pagine prerenderizzate rispetto a quelle non prerenderizzate.
  • A/B Testing: Conduci test A/B per confrontare diverse configurazioni di speculation rules e identificare la configurazione più ottimale per il tuo sito web specifico e la tua base utenti.

speculation rules rum tracking table coredash

Considerazioni - gli aspetti negativi

Consumo di risorse: Un uso eccessivo della speculazione può avere un impatto negativo sulla larghezza di banda, la memoria e l'utilizzo della CPU.

Compatibilità browser: Non tutti i browser supportano completamente la Speculation Rules API, quindi verifica la compatibilità del browser prima dell'implementazione.

Privacy: Gli sviluppatori dovrebbero essere consapevoli di come le speculation rules potrebbero rivelare i pattern di navigazione degli utenti e implementare misure di privacy appropriate.

La Speculation Rules API offre un approccio potente per migliorare le prestazioni e l'user experience delle applicazioni web. Comprendendo le sue meccaniche, i vantaggi e le considerazioni, gli sviluppatori possono sfruttare questa API per costruire siti web più veloci e coinvolgenti.

Speculation Rules - Codice WordPress

Il team WordPress Core Performance ha creato un plugin Speculation Rules che rende l'aggiunta del supporto document rules a qualsiasi sito WordPress un'operazione con un solo click. Il plugin offre due gruppi di impostazioni:

  • Modalità di speculazione: Scegli tra prefetch e prerender. Il prerendering risulterà in tempi di caricamento più rapidi rispetto al prefetching. Tuttavia, il prefetching potrebbe essere una scelta più sicura per contenuti interattivi.
  • Eagerness: Scegli tra conservative (tipicamente al click), moderate (tipicamente all'hover) o eager (al minimo suggerimento). L'impostazione eagerness determina quanto rapidamente vengono attivati i caricamenti speculativi.
Pagine a caricamento istantaneo con le Speculation RulesCore Web Vitals Pagine a caricamento istantaneo con le Speculation Rules