Speculation Rules API: Guida Completa (2026)

Cos'è la Speculation Rules API e Perché Dovresti Interessartene

Ti è mai capitato di navigare su un sito dove ogni click porta a un caricamento istantaneo? Nessuna attesa, nessuna barra di progresso, nessuno schermo bianco. Ecco, quella sensazione di fluidità è esattamente ciò che la Speculation Rules API rende possibile.

In pratica, si tratta di uno standard web sviluppato dal team di Chrome che permette agli sviluppatori di dire al browser: "Ehi, precarica o pre-renderizza queste pagine in background, prima che l'utente le chieda davvero". È un salto in avanti rispetto al vecchio <link rel="prefetch"> — qui parliamo di controllo granulare, sintassi JSON dichiarativa e prerendering completo delle pagine. Un livello di ottimizzazione che prima era semplicemente impossibile.

E perché parlarne proprio ora? Perché nel 2026, con Google che continua ad alzare l'asticella sui segnali di page experience nel ranking e con il 43% dei siti che ancora non supera la soglia INP di 200ms, questa API è diventata una delle armi più efficaci per migliorare i Core Web Vitals. Onestamente, se lavori sulle performance web, non puoi più ignorarla.

Prefetch vs Prerender: Quale Strategia Scegliere

La Speculation Rules API offre due strategie principali, e capire la differenza tra le due è fondamentale per non sprecare risorse (o peggio, peggiorare le cose).

Prefetching: Leggero e Scalabile

Il prefetching scarica il documento HTML della pagina di destinazione e le sue risorse critiche, ma non lo renderizza. Quando l'utente naviga verso quella pagina, il browser ha già l'HTML in cache e deve solo renderizzarlo. Risultato: tempi di caricamento ridotti senza stressare memoria o CPU.

È la scelta giusta quando:

Vuoi coprire un ampio numero di pagine potenzialmente visitabili
Le risorse sono limitate — pensa agli utenti su mobile con connessione ballerina
Non hai idea di quale pagina l'utente visiterà dopo

Prerendering: Istantaneo ma Costoso

Il prerendering va molto oltre. Scarica tutte le risorse, esegue il JavaScript, renderizza i CSS e costruisce l'intera pagina in un tab invisibile in background. Quando l'utente naviga verso quella pagina, il browser semplicemente "attiva" quel tab nascosto. Il risultato?

Un Time to First Byte percepito pari a zero. Sì, hai letto bene.

È la scelta giusta quando:

Hai un'alta fiducia sulla destinazione successiva dell'utente (tipicamente un flusso di checkout)
La pagina di destinazione è il punto focale della conversione
Puoi permetterti il costo aggiuntivo in termini di risorse server

Confronto Rapido

Caratteristica	Prefetch	Prerender
Risorse scaricate	Solo HTML e risorse critiche	Tutte le risorse + JavaScript eseguito
Consumo memoria	Basso	Alto
Velocità di navigazione	Più veloce del normale	Quasi istantanea
Utilizzo consigliato	Ampio (molte pagine)	Mirato (pagine ad alta probabilità)

Implementazione Passo-Passo con Esempi di Codice

Bene, passiamo alla parte pratica. Vediamo come implementare concretamente la Speculation Rules API nel tuo sito. Ci sono due metodi principali: tramite tag <script> inline oppure tramite header HTTP.

Metodo 1: Script Inline nel Documento HTML

Il modo più diretto è inserire un blocco <script type="speculationrules"> nel tuo HTML. Puoi metterlo sia nel <head> che nel <body> — non fa differenza:

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

In questo esempio, il browser effettuerà il prefetch di tutti i link interni quando l'utente ci passa sopra col cursore (eagerness "moderate"), e il prerender solo dei link con la classe CSS .prerender-link. Semplice ed efficace.

Metodo 2: URL List Rules (Lista Esplicita di URL)

Se preferisci avere il controllo totale su quali pagine pre-caricare, puoi specificare una lista esplicita di URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/prodotti", "/chi-siamo", "/contatti"],
      "eagerness": "immediate"
    }
  ]
}
</script>

Questa configurazione pre-renderizza immediatamente le tre pagine specificate. Ideale per i link di navigazione principale — quelli che sai che verranno cliccati quasi sicuramente.

Metodo 3: Header HTTP (Approccio Server-Side)

Per chi preferisce mantenere l'HTML pulito e centralizzare le regole lato server, c'è l'opzione dell'header HTTP Speculation-Rules:

Speculation-Rules: "/speculation-rules.json"

Il file JSON esterno deve essere servito con il MIME type corretto (e qui si sbaglia spesso, fidati):

Content-Type: application/speculationrules+json

Contenuto del file speculation-rules.json:

{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/admin/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": {
        "selector_matches": "nav a, .cta-button"
      },
      "eagerness": "conservative"
    }
  ]
}

Questo approccio è particolarmente utile per siti dinamici dove le regole devono variare in base al contesto utente o alla sezione del sito. Personalmente, è il metodo che preferisco per i progetti più strutturati.

Il Parametro Eagerness: Controllare Quando il Browser Agisce

Il parametro eagerness è probabilmente la parte più importante di tutta la configurazione. Controlla quando il browser deve iniziare il prefetch o il prerender, e trovare il giusto equilibrio tra prestazioni e consumo di risorse fa tutta la differenza.

I Quattro Livelli di Eagerness

immediate: il browser avvia la speculazione non appena incontra la regola. Da usare con parsimonia, solo per pagine con pochi link ad alta priorità
eager: simile a immediate, ma con potenziale ottimizzazione futura da parte del browser. In pratica, oggi si comporta quasi allo stesso modo
moderate: la speculazione si attiva quando l'utente passa il cursore su un link per almeno 200 millisecondi. È il miglior compromesso nella maggior parte dei casi
conservative: la speculazione si attiva solo al mousedown o al tocco del link. Consumo di risorse minimo, ma con un guadagno di velocità comunque percepibile

Strategia Consigliata: Approccio Progressivo

Dopo aver testato diverse configurazioni su vari progetti, la strategia che funziona meglio nel 2026 è l'approccio progressivo: prefetch a livello "moderate" per tutti i link interni, prerender con eagerness "conservative" solo per navigazione principale e CTA.

Ecco come appare in pratica:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/*.pdf" } },
          { "not": { "selector_matches": "[data-no-prefetch]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prerender": [
    {
      "where": {
        "selector_matches": "nav a, .hero-cta, .product-link"
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Nota come vengono esclusi il link di logout, i file PDF e qualsiasi elemento con l'attributo data-no-prefetch. Sono dettagli che fanno la differenza tra un'implementazione che funziona e una che crea problemi.

Impatto sui Core Web Vitals: Dati Reali nel 2026

Ok, la teoria è bella, ma parliamo di numeri concreti. L'impatto della Speculation Rules API sui Core Web Vitals è documentato da dati reali — e i risultati sono piuttosto impressionanti.

Miglioramenti Misurabili su LCP

I benefici più evidenti riguardano il Largest Contentful Paint (LCP). Secondo i dati raccolti dal team di Chrome:

Il 95° percentile di LCP è risultato circa 500ms più veloce con il prerendering attivo
Il 75° percentile ha mostrato un miglioramento di circa 170ms
Il 59% delle navigazioni ha attivato con successo il prerendering
Le pagine pre-renderizzate hanno raggiunto un LCP al P75 di 537ms contro i 714ms delle pagine standard

170ms potrebbero sembrare pochi sulla carta. Ma per chi lavora con le web performance, sappiamo bene che ogni millisecondo conta — soprattutto quando si è vicini alle soglie dei Core Web Vitals.

Effetto su CLS e INP

Il prerendering ha un impatto positivo anche sugli altri Core Web Vitals:

CLS (Cumulative Layout Shift): gli spostamenti di layout avvengono durante il prerendering in background, prima che l'utente veda la pagina. Il CLS percepito? Praticamente zero
INP (Interaction to Next Paint): la pagina è già completamente caricata quando l'utente inizia a interagire, quindi le prime interazioni risultano molto più reattive

Case Study: L'Esempio di Ray-Ban

Uno dei case study più interessanti è quello di Ray-Ban. Utilizzando il prerendering speculativo hanno registrato un aumento delle conversioni desktop del 156%.

Non è un errore di battitura. 156%. Questo dimostra che l'impatto non è solo tecnico ma ha conseguenze dirette e misurabili sul business.

Compatibilità Browser e Progressive Enhancement

La domanda che tutti si pongono: "Sì, ok, ma quanti utenti possono effettivamente beneficiarne?" Vediamo la situazione aggiornata al 2026.

Stato del Supporto

Chrome 109+: supporto completo (prefetch e prerender)
Edge 109+: supporto completo (stesso motore Chromium)
Opera 95+: supporto completo (sempre Chromium)
Firefox: posizione recentemente cambiata a "positiva" per il prefetch, con interesse concreto nell'implementazione
Safari: non ancora supportato, ma il team WebKit ha mostrato interesse

I browser basati su Chromium coprono circa il 70% del mercato browser globale. Non è il 100%, certo, ma è una copertura più che sufficiente per giustificare l'implementazione.

Implementare il Fallback per Browser Non Supportati

La buona notizia? La Speculation Rules API è progettata come progressive enhancement. I browser che non la supportano semplicemente ignorano il tag <script type="speculationrules"> senza generare errori. Nessun crash, nessun problema.

Per offrire un'esperienza migliore anche sugli altri browser, puoi comunque implementare un fallback:

<script>
if (!HTMLScriptElement.supports ||
    !HTMLScriptElement.supports('speculationrules')) {
  // Fallback: usa link prefetch tradizionale
  const links = document.querySelectorAll('nav a');
  links.forEach(link => {
    const prefetchLink = document.createElement('link');
    prefetchLink.rel = 'prefetch';
    prefetchLink.href = link.href;
    document.head.appendChild(prefetchLink);
  });
}
</script>

Poche righe di codice per coprire anche Safari e Firefox. Ne vale la pena.

Debug e Monitoraggio con Chrome DevTools

Implementare le Speculation Rules è solo metà del lavoro. Verificare che funzionino davvero (e bene) è l'altra metà.

Pannello Speculative Loads

Per ispezionare le speculazioni attive, apri Chrome DevTools e naviga in: Application > Background Services > Speculative Loads > Speculations.

Attenzione: devi aprire questo pannello prima di caricare la pagina che contiene le Speculation Rules. Se lo apri dopo, alcune speculazioni potrebbero non essere catturate. È un dettaglio che fa perdere tempo a chiunque la prima volta.

Rilevamento Server-Side con Sec-Purpose

Le richieste di prefetch e prerender includono l'header Sec-Purpose, che puoi sfruttare lato server per diversi scopi:

Tracciare il volume di richieste speculative nei log
Restituire contenuto diverso (ad esempio omettere gli script di analytics nelle pagine pre-renderizzate)
Bloccare il prerendering per pagine specifiche

// Esempio in Node.js / Express
app.use((req, res, next) => {
  const secPurpose = req.headers['sec-purpose'];

  if (secPurpose && secPurpose.includes('prefetch')) {
    // Richiesta speculativa: salta il tracking analytics
    res.locals.isSpeculative = true;
  }

  next();
});

Verifica Client-Side con document.prerendering

Nel JavaScript della pagina puoi anche verificare se una pagina è attualmente in fase di prerendering:

if (document.prerendering) {
  // La pagina è in pre-rendering: rinvia l'invio di analytics
  document.addEventListener('prerenderingchange', () => {
    // Ora la pagina è visibile: invia analytics
    sendPageView();
  });
} else {
  sendPageView();
}

Questo pattern è essenziale per evitare di gonfiare artificialmente i dati di analytics. Se non lo implementi, ogni prerender conta come un page view — e i tuoi report diventano inaffidabili.

Best Practice e Errori Comuni da Evitare

Best Practice

Inizia con il prefetch: applica il prefetch in modo ampio e il prerender in modo mirato. Non pre-renderizzare tutte le pagine del sito (il tuo server ti ringrazierà)
Escludi le pagine sensibili: logout, endpoint API, download di file e pagine con side-effect come l'invio di email non devono mai essere pre-renderizzate
Monitora i costi server: ogni prerender genera un caricamento completo lato server. Se ogni pagina innesca 2-3 prerender, i costi infrastrutturali possono salire rapidamente
Usa l'approccio progressivo: inizia con eagerness "conservative" o "moderate", misura i risultati, poi aumenta gradualmente
Gestisci gli analytics correttamente: assicurati che le pagine pre-renderizzate non inviino falsi page view. Usa document.prerendering per rinviare il tracking

Errori Comuni

Pre-renderizzare troppe pagine contemporaneamente: Chrome limita il numero di prerender simultanei. Concentrati sulle pagine ad alta probabilità di visita, non sparare nel mucchio
Dimenticare il MIME type per le regole esterne: il file JSON deve essere servito con application/speculationrules+json. Senza il MIME type corretto, il browser ignora tutto silenziosamente — e tu passi ore a chiederti perché non funziona
Non testare su dispositivi mobile: Chrome può disattivare le speculazioni su dispositivi con batteria bassa o connessione lenta. Testa sempre su condizioni realistiche
Ignorare le limitazioni cross-origin: per ragioni di privacy, i prefetch cross-site funzionano solo se l'utente non ha cookie impostati per il sito di destinazione

Quando NON Usare la Speculation Rules API

Lo so, dopo aver letto tutto questo viene voglia di metterla ovunque. Ma ci sono scenari in cui la Speculation Rules API non è la scelta giusta:

Single Page Application (SPA): l'API è progettata per navigazioni complete del browser (MPA). Per le SPA, usa il meccanismo di prefetching del tuo framework — React Router, Vue Router e compagnia bella hanno già le loro soluzioni
Pagine con side-effect: qualsiasi pagina che esegue azioni al caricamento (invio email, elaborazione pagamenti, aggiornamento database) non deve mai essere pre-renderizzata. Mai.
Siti con traffico elevato e server limitati: il prerendering moltiplica le richieste al server. Valuta attentamente se la tua infrastruttura può reggere il carico aggiuntivo
Contenuti dietro autenticazione: le pagine che richiedono login non sono candidate ideali per il prerendering cross-site

Configurazione Avanzata: Document Rules con Selettori CSS

Per chi vuole spingersi oltre, le Document Rules permettono di usare selettori CSS e pattern di URL per creare regole sofisticate senza elencare ogni singolo URL. È qui che la cosa si fa davvero interessante.

Combinare Condizioni con Operatori Logici

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/prodotti/*" },
          { "not": { "href_matches": "/prodotti/*/recensioni" } },
          {
            "or": [
              { "selector_matches": ".prodotto-in-evidenza" },
              { "selector_matches": ".prodotto-consigliato" }
            ]
          }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Questo esempio pre-renderizza solo i link ai prodotti (escludendo le pagine di recensioni) che hanno una delle classi CSS specificate. Perfetto per un e-commerce che vuole ottimizzare la navigazione del catalogo senza sprecare risorse su pagine secondarie.

Escludere Elementi con data-attributes

Un pattern che uso spesso è quello dei data-attributes per escludere specifici link dalla speculazione:

<!-- Questo link NON verrà pre-renderizzato -->
<a href="/logout" data-no-prerender>Esci</a>

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

Elegante, leggibile e facile da mantenere. Basta aggiungere data-no-prerender a qualsiasi link che vuoi escludere, senza toccare la configurazione delle regole.

Domande Frequenti (FAQ)

La Speculation Rules API funziona su Safari e Firefox?

Al momento (febbraio 2026), è supportata solo nei browser basati su Chromium — Chrome, Edge e Opera — che coprono circa il 70% del mercato. Firefox ha recentemente espresso una posizione "positiva" verso l'implementazione del prefetch, mentre Safari non ha ancora annunciato supporto ufficiale. La buona notizia è che l'API funziona come progressive enhancement: i browser non supportati semplicemente ignorano le regole senza generare alcun errore.

Il prerendering aumenta i costi del server?

Sì, potenzialmente in modo significativo. Ogni pagina pre-renderizzata genera un caricamento completo lato server. Con una configurazione aggressiva (eagerness "immediate" su molti link), le richieste possono facilmente raddoppiare o triplicare. La strategia consigliata? Prefetch ampio, prerender mirato, e un occhio costante sui dati del tuo APM.

Posso usare la Speculation Rules API con React, Vue o Next.js?

Dipende dall'architettura. Se il tuo sito usa navigazione client-side (SPA pura), l'API non fa al caso tuo — meglio affidarsi al prefetching del framework. Se invece usi un framework con rendering lato server e navigazioni complete (come Next.js con output statico o Astro), allora sì, l'API può portare benefici significativi. Next.js, tra l'altro, ha integrato il supporto sperimentale per le Speculation Rules nelle versioni più recenti.

Come verifico se le Speculation Rules stanno funzionando?

Chrome DevTools è il tuo migliore amico: vai su Application > Background Services > Speculative Loads > Speculations. Ricorda di aprire il pannello prima di caricare la pagina. In alternativa, controlla il pannello Network filtrando le richieste con header Sec-Purpose: prefetch o Sec-Purpose: prefetch;prerender.

Il prerendering influisce sul tracciamento degli analytics?

Assolutamente sì, ed è un punto che molti sottovalutano. Le pagine pre-renderizzate eseguono JavaScript, inclusi gli script di analytics. Se non gestisci la cosa, ogni prerender conta come un page view reale — e i tuoi report diventano inutilizzabili. La soluzione: usa document.prerendering per verificare lo stato della pagina e rinvia l'invio delle metriche fino all'evento prerenderingchange, che si attiva quando la pagina diventa effettivamente visibile all'utente.