Prerendering delle pagine in Chrome per navigazioni immediate tra le pagine

Barry Pollard

Data di pubblicazione: 2 dicembre 2022, Ultimo aggiornamento: 29 ottobre 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Il team di Chrome ha ripristinato il prerendering completo delle pagine future che un utente potrebbe visitare.

Breve storia del prerendering

In passato, Chrome supportava il suggerimento di risorse <link rel="prerender" href="/next-page">, ma non era ampiamente supportato al di fuori di Chrome e non era un'API molto espressiva.

Questo prerendering legacy che utilizza il suggerimento del link rel=prerender è stato ritirato a favore del precaricamento NoState, che invece recuperava le risorse necessarie per la pagina futura, ma non eseguiva il prerendering completo della pagina né eseguiva JavaScript. Il precaricamento NoState contribuisce a migliorare le prestazioni della pagina migliorando il caricamento delle risorse, ma non offre un caricamento istantaneo della pagina come farebbe un prerendering completo.

Il team di Chrome ha ora reintrodotto il prerendering completo in Chrome. Per evitare complicazioni con l'utilizzo esistente e consentire l'espansione futura del prerendering, questo nuovo meccanismo di prerendering non utilizzerà la sintassi <link rel="prerender"...>, che rimane attiva per il precaricamento NoState, con l'intenzione di ritirarla in futuro.

Come viene eseguito il prerendering di una pagina?

Una pagina può essere prerenderizzata in uno dei quattro modi seguenti, tutti volti a velocizzare la navigazione:

  1. Quando digiti un URL nella barra degli indirizzi di Chrome (nota anche come "omnibox"), Chrome potrebbe eseguire automaticamente il prerendering della pagina, se ritiene con un elevato livello di confidenza che visiterai quella pagina, in base alla tua cronologia di navigazione precedente.
  2. Quando utilizzi la barra dei preferiti, Chrome potrebbe eseguire automaticamente il prerendering della pagina quando tieni il puntatore su uno dei pulsanti dei preferiti.
  3. Quando digiti un termine di ricerca nella barra degli indirizzi di Chrome, Chrome potrebbe eseguire automaticamente il prerendering della pagina dei risultati di ricerca, se richiesto dal motore di ricerca.
  4. I siti possono utilizzare l'API Speculation Rules per indicare a Chrome in modo programmatico quali pagine prerenderizzare. Questo sostituisce ciò che faceva <link rel="prerender"...> e consente ai siti di eseguire il prerendering proattivo di una pagina in base alle regole di speculazione presenti nella pagina. Questi possono essere presenti in modo statico nelle pagine o essere inseriti dinamicamente da JavaScript, a seconda di come il proprietario della pagina ritiene opportuno.

In ognuno di questi casi, un prerendering si comporta come se la pagina fosse stata aperta in una scheda in background invisibile e poi viene "attivato" sostituendo la scheda in primo piano con la pagina prerenderizzata. Se una pagina viene attivata prima che sia stato eseguito il prerendering completo, il suo stato attuale è "in primo piano" e continua a caricarsi, il che significa che puoi comunque ottenere un buon vantaggio.

Poiché la pagina prerenderizzata viene aperta in uno stato nascosto, alcune API che causano comportamenti invasivi (ad esempio, prompt) non vengono attivate in questo stato, ma vengono ritardate fino all'attivazione della pagina. Nel numero limitato di casi in cui ciò non è ancora possibile, il prerendering viene annullato. Il team di Chrome sta lavorando per esporre i motivi dell'annullamento del prerendering come API e per migliorare le funzionalità di DevTools per semplificare l'identificazione di questi casi limite.

Impatto del prerendering

Il prerendering consente un caricamento della pagina quasi istantaneo, come mostrato nel seguente video:

Esempio di impatto del prerendering.

Il sito di esempio è già un sito veloce, ma anche in questo caso puoi vedere come il prerendering migliora l'esperienza utente. Ciò può quindi avere un impatto diretto anche sui Core Web Vitals di un sito, con un LCP quasi pari a zero, un CLS ridotto (poiché qualsiasi CLS di caricamento avviene prima della visualizzazione iniziale) e un INP migliorato (poiché il caricamento dovrebbe essere completato prima che l'utente interagisca).

Anche quando una pagina si attiva prima di essere completamente caricata, l'avvio anticipato del caricamento pagina dovrebbe migliorare l'esperienza di caricamento. Quando un link viene attivato mentre il prerendering è ancora in corso, la pagina di prerendering si sposta nel frame principale e continua il caricamento.

Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntive. Fai attenzione a non eseguire un prerendering eccessivo, a scapito delle risorse dell'utente. Esegui il prerendering solo quando è molto probabile che la pagina venga visitata.

Per saperne di più su come misurare l'impatto effettivo sulle prestazioni nei tuoi dati di analisi, consulta la sezione Misurazione delle prestazioni.

Visualizza le previsioni della barra degli indirizzi di Chrome

Per il primo caso d'uso, puoi visualizzare le previsioni di Chrome per gli URL nella pagina chrome://predictors:

La pagina Chrome Predictors filtrata per mostrare le previsioni basse (grigio), medie (ambra) e alte (verde) in base al testo inserito.
Pagina Chrome Predictors.

Le linee verdi indicano un livello di confidenza sufficiente per attivare il prerendering. In questo esempio, digitando "s" si ottiene un livello di confidenza ragionevole (giallo), ma una volta digitato "sh", Chrome ha una confidenza sufficiente per stabilire che quasi sempre navighi su https://sheets.google.com.

Questo screenshot è stato acquisito in un'installazione di Chrome relativamente recente e filtrando le previsioni con confidenza pari a zero, ma se visualizzi i tuoi predittori, probabilmente vedrai un numero di voci notevolmente superiore e potenzialmente più caratteri necessari per raggiungere un livello di confidenza sufficientemente elevato.

Questi predittori sono anche alla base delle opzioni suggerite nella barra degli indirizzi che potresti aver notato:

La funzionalità di completamento automatico della barra degli indirizzi di Chrome
Funzionalità di completamento automatico della barra degli indirizzi.

Chrome aggiornerà continuamente i suoi predittori in base a ciò che digiti e selezioni.

  • Per un livello di confidenza superiore al 30% (mostrato in ambra), Chrome si preconnette in modo proattivo al dominio, ma non esegue il prerendering della pagina.
  • Per un livello di confidenza superiore al 50% (mostrato in verde), Chrome prerenderizzerà l'URL.

API Speculation Rules

Per l'opzione di prerendering dell'API Speculation Rules, gli sviluppatori web possono inserire istruzioni JSON nelle loro pagine per informare il browser su quali URL prerenderizzare.

Elenco URL

Le regole di speculazione possono essere basate su elenchi di URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Regole per i documenti

Le regole di speculazione possono anche essere "regole del documento" utilizzando la sintassi where. Questa regola ipotizza i link trovati nel documento in base ai selettori href (basati sull'API pattern URL) o ai selettori CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Entusiasmo

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Un'impostazione eagerness viene utilizzata per indicare quando devono essere attivate le speculazioni, il che è particolarmente utile per le regole del documento:

  • conservative: questa opzione esegue la speculazione quando il puntatore o il tocco vengono premuti.
  • moderate: su computer, questa opzione esegue le speculazioni se tieni il puntatore su un link per 200 millisecondi (o sull'evento pointerdown se si verifica prima e su dispositivi mobili dove non è presente l'evento hover). Su mobile, abbiamo cambiato questo approccio per basarlo su euristiche complesse della visualizzazione a partire da agosto 2025. Le euristiche complesse dell'area visibile vengono attivate 500 ms dopo che l'utente ha interrotto lo scorrimento, per gli ancoraggi entro il 30% della distanza verticale dal precedente evento pointerdown, dove gli ancoraggi sono almeno 0,5 volte più grandi dell'ancoraggio più grande nell'area visibile. Come descritto in questo documento.
  • eager: questa modalità di caricamento si comportava in modo identico a immediate, ma è cambiata a partire da Chrome 143. Su computer, questa opzione esegue le speculazioni se tieni il puntatore su un link per 10 millisecondi. Sui dispositivi mobili, abbiamo cambiato il criterio di base in euristica semplice dell'area visibile a partire da gennaio 2026. Le semplici euristiche dell'area visibile vengono attivate 50 ms dopo l'ingresso dell'ancoraggio nell'area visibile.
  • immediate: viene utilizzato per eseguire la speculazione il prima possibile, ovvero non appena vengono osservate le regole di speculazione.

Il valore predefinito di eagerness per le regole list è immediate. Le opzioni eager, moderate e conservative possono essere utilizzate per limitare le regole list agli URL con cui un utente interagisce a un elenco specifico. Tuttavia, in molti casi, le regole document con una condizione where appropriata potrebbero essere più adatte.

Il valore predefinito di eagerness per le regole document è conservative. Poiché un documento può essere composto da molti URL, l'utilizzo di immediate per le regole document deve essere fatto con cautela (consulta anche la sezione Limiti di Chrome di seguito).

L'impostazione eagerness da utilizzare dipende dal tuo sito. Per un sito statico e leggero, una speculazione più aggressiva potrebbe avere un costo ridotto ed essere vantaggiosa per gli utenti. I siti con architetture più complesse e payload di pagina più pesanti potrebbero preferire ridurre gli sprechi speculando meno spesso, finché non ricevono un segnale di intent più positivo dagli utenti per limitare gli sprechi.

L'opzione moderate è una via di mezzo e molti siti potrebbero trarre vantaggio dalla seguente regola di speculazione che prerenderizza un link quando il puntatore viene tenuto sul link per 200 millisecondi o sull'evento pointerdown come implementazione di base, ma potente, delle regole di speculazione:

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

Precaricamento

Le regole di speculazione possono essere utilizzate anche per precaricare le pagine, senza un pre-rendering completo. Questo può essere spesso un buon primo passo verso il prerendering:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

Il team di Chrome sta anche lavorando all'aggiunta di prerender_until_script all'API Speculation Rules (consulta il bug di implementazione). Questo sarebbe un passaggio tra il precaricamento e il prerendering e verrebbe utilizzato in modo simile:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Analogamente a NoState prefetch, questo precarica sia il documento HTML sia le risorse secondarie disponibili in quel documento HTML. Tuttavia, andrebbe oltre e inizierebbe anche a prerenderizzare la pagina, interrompendosi quando viene rilevato il primo script.

Ciò significa che per le pagine senza JavaScript o con JavaScript solo nel piè di pagina, la pagina potrebbe essere quasi completamente prerenderizzata in anticipo. Le pagine con script in <head> non potrebbero essere prerenderizzate, ma trarrebbero comunque vantaggio dal recupero delle risorse secondarie.

In questo modo si eviterebbero i rischi di effetti collaterali indesiderati derivanti dall'esecuzione di JavaScript, ma si otterrebbe un aumento delle prestazioni molto maggiore rispetto alla sola prefetch.

Limiti di Chrome

Chrome ha dei limiti per impedire un utilizzo eccessivo dell'API Speculation Rules:

entusiasmo Precaricamento Prerender
immediate 50 10
eager/moderate su dispositivo mobile 6 (FIFO) 2 (FIFO)
eager/moderate su computer 2 (FIFO) 2 (FIFO)
conservative 2 (FIFO) 2 (FIFO)
Limiti di speculazione in Chrome.

Le impostazioni eager, moderate e conservative, che dipendono dall'interazione dell'utente, funzionano in modalità FIFO (First In, First Out): una volta raggiunto il limite, una nuova speculazione causerà l'annullamento della speculazione più vecchia e la sua sostituzione con quella più recente per risparmiare memoria.

Una speculazione annullata può essere attivata di nuovo, ad esempio passando di nuovo il mouse sopra il link, il che comporterà una nuova speculazione dell'URL, eliminando la speculazione più vecchia. In questo caso, la speculazione precedente avrà memorizzato nella cache HTTP tutte le risorse memorizzabili nella cache per l'URL, quindi la speculazione successiva dovrebbe avere un costo ridotto. Questo è il motivo per cui il limite è impostato sulla soglia modesta di 2 per impostazione predefinita. Utilizziamo una soglia più alta di 6 per il precaricamento su dispositivi mobili, poiché non esiste l'azione di "passaggio del mouse", le alternative euristiche per l'area visibile mobile sono meno accurate e il precaricamento è meno costoso del prerendering (manteniamo il limite di 2 per il prerendering su dispositivi mobili).

Le regole degli elenchi statici non vengono attivate da un'azione dell'utente e pertanto hanno un limite più elevato, in quanto non è possibile per il browser sapere quali sono necessarie e quando.

Chrome sta anche valutando la possibilità di aumentare il limite a 5 su dispositivi mobili per eager e moderate, almeno per il precaricamento, dato che si tratta di un'euristica meno precisa. Gli sviluppatori che utilizzano eager potrebbero prendere in considerazione l'utilizzo di regole conservative aggiuntive quando sono disponibili più link nell'area visibile, in modo da eseguire comunque la speculazione anche se non sono selezionati come uno dei primi due link.

Anche il limite di immediate è dinamico, quindi la rimozione di un elemento script URL list creerà capacità annullando le speculazioni rimosse.

Chrome impedirà inoltre l'utilizzo delle speculazioni in determinate condizioni, tra cui:

  • Save-Data.
  • Risparmio energetico quando è attivato e la batteria è in esaurimento.
  • Vincoli di memoria.
  • Quando l'impostazione "Precarica le pagine" è disattivata (che viene anche disattivata esplicitamente dalle estensioni di Chrome come uBlock Origin).
  • Pagine aperte in schede in background.

Inoltre, Chrome non esegue il rendering degli iframe multiorigine sulle pagine prerenderizzate fino all'attivazione.

Tutte queste condizioni mirano a ridurre l'impatto della speculazione eccessiva quando potrebbe essere dannosa per gli utenti.

Come includere le regole di speculazione in una pagina

Le regole di speculazione possono essere incluse staticamente nell'HTML della pagina o inserite dinamicamente nella pagina tramite JavaScript:

  • Regole di speculazione incluse staticamente: ad esempio, un sito di notizie o un blog potrebbe prerenderizzare l'articolo più recente, se questo è spesso il passaggio successivo per una grande percentuale di utenti. In alternativa, è possibile utilizzare le regole del documento con un moderate o un conservative per speculare mentre gli utenti interagiscono con i link.
  • Regole di speculazione inserite dinamicamente: potrebbero essere basate sulla logica dell'applicazione, personalizzate per l'utente o basate su altre euristiche.

A chi preferisce l'inserimento dinamico in base ad azioni come il passaggio del mouse o il clic su un link, come hanno fatto molte librerie in passato con <link rel=prefetch>, consigliamo di esaminare le regole del documento, in quanto consentono al browser di gestire molti dei tuoi casi d'uso.

Le regole di speculazione possono essere aggiunte in <head> o <body> nel frame principale. Le regole di speculazione nei frame secondari non vengono applicate, mentre quelle nelle pagine prerenderizzate vengono applicate solo dopo l'attivazione della pagina.

L'intestazione HTTP Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Le regole di speculazione possono anche essere inviate utilizzando un'intestazione HTTP Speculation-Rules, anziché includerle direttamente nel codice HTML del documento. In questo modo, il deployment da parte delle CDN è più semplice, senza la necessità di modificare i contenuti dei documenti stessi.

L'intestazione HTTP Speculation-Rules viene restituita con il documento e rimanda alla posizione di un file JSON contenente le regole di speculazione:

Speculation-Rules: "/speculationrules.json"

Questa risorsa deve utilizzare il tipo MIME corretto e, se si tratta di una risorsa multiorigine, superare un controllo CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Se vuoi utilizzare URL relativi, ti consigliamo di includere la chiave "relative_to": "document" nelle regole di speculazione. In caso contrario, gli URL relativi saranno relativi all'URL del file JSON delle regole di speculazione. Questo può essere particolarmente utile se devi selezionare alcuni o tutti i link della stessa origine.

Campo del tag delle regole di speculazione

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

È anche possibile aggiungere "tag" nella sintassi JSON delle regole di speculazione a livello generale per tutte le regole di speculazione di un set di regole:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Oppure a livello di singola regola:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Questo tag viene poi riflesso nell'intestazione HTTP Sec-Speculation-Tags, che può essere utilizzata per filtrare le regole di speculazione sul server. L'intestazione HTTP Sec-Speculation-Tags può includere più tag se la speculazione è coperta da più regole, come mostrato nell'esempio seguente:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Alcune CDN inseriscono automaticamente le regole di speculazione, ma bloccano le speculazioni per le pagine non memorizzate nella cache perimetrale per evitare che questa funzionalità comporti un aumento dell'utilizzo del server di origine. I tag consentono di identificare le speculazioni avviate dal set di regole predefinito, ma consentono comunque di trasmettere all'origine le regole aggiunte dal sito.

I tag dei set di regole vengono visualizzati anche in Chrome DevTools.

Campo target_hint delle regole di speculazione

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Le regole di speculazione possono anche includere un campo target_hint, che contiene un nome o una parola chiave del contesto di navigazione valido che indica dove la pagina prevede che i contenuti prerenderizzati vengano attivati:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Questo suggerimento consente di gestire le speculazioni di prerendering per i link target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

Al momento, solo "target_hint": "_blank" e "target_hint": "_self" (il valore predefinito se non specificato) sono supportati in Chrome e solo per il prerendering; il precaricamento non è supportato.

target_hint è necessario solo per le regole di speculazione urls, poiché per le regole dei documenti il target è noto dal link stesso.

Regole di speculazione e SPA

Le regole di speculazione sono supportate solo per le navigazioni nelle pagine complete gestite dal browser e non per le app a pagina singola (SPA) o le pagine shell dell'app. Queste architetture non utilizzano i recuperi di documenti, ma eseguono recuperi parziali o tramite API di dati o pagine, che vengono poi elaborati e presentati nella pagina corrente. I dati necessari per queste cosiddette "navigazioni soft" possono essere precaricati dall'app al di fuori delle regole di speculazione, ma non possono essere prerenderizzati.

Le regole di speculazione possono essere utilizzate per eseguire il prerendering dell'applicazione stessa da una pagina precedente. In questo modo, è possibile compensare alcuni dei costi di caricamento iniziale aggiuntivi di alcune SPA. Tuttavia, le modifiche al percorso all'interno dell'app non possono essere prerenderizzate.

Esegui il debug delle regole di speculazione

Consulta il post dedicato al debug delle regole di speculazione per scoprire le nuove funzionalità di Chrome DevTools che ti aiuteranno a visualizzare ed eseguire il debug di questa nuova API.

Più regole di speculazione

È anche possibile aggiungere più regole di speculazione alla stessa pagina, che vengono aggiunte alle regole esistenti. Pertanto, i seguenti modi diversi comportano il prerendering sia di one.html che di two.html:

Elenco di URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Più script speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Più elenchi all'interno di un insieme di speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

Quando esegui il precaricamento o il prerendering di una pagina, alcuni parametri URL (tecnicamente noti come parametri di ricerca) potrebbero non essere importanti per la pagina effettivamente pubblicata dal server e utilizzati solo da JavaScript lato client.

Ad esempio, i parametri UTM vengono utilizzati da Google Analytics per la misurazione della campagna, ma in genere non comportano la pubblicazione di pagine diverse dal server. Ciò significa che page1.html?utm_content=123 e page1.html?utm_content=456 mostreranno la stessa pagina dal server, quindi la stessa pagina può essere riutilizzata dalla cache.

Analogamente, le applicazioni possono utilizzare altri parametri URL che vengono gestiti solo lato client.

La proposta No-Vary-Search consente a un server di specificare parametri che non comportano una differenza nella risorsa pubblicata e, pertanto, consentono a un browser di riutilizzare le versioni precedentemente memorizzate nella cache di un documento che differiscono solo per questi parametri. Questa funzionalità è supportata in Chrome (e nei browser basati su Chromium) per le speculazioni di navigazione sia per il precaricamento che per il prerendering.

Le regole di speculazione supportano l'utilizzo di expects_no_vary_search per indicare dove è prevista la restituzione di un'intestazione HTTP No-Vary-Search. In questo modo, puoi evitare ulteriormente download non necessari prima che le risposte vengano visualizzate.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

In questo esempio, l'HTML della pagina iniziale /products è lo stesso per entrambi gli ID prodotto 123 e 124. Tuttavia, i contenuti della pagina finiscono per differire in base al rendering lato client che utilizza JavaScript per recuperare i dati di prodotto utilizzando il parametro di ricerca id. Pertanto, eseguiamo il precaricamento di questo URL e dovrebbe essere restituita un'intestazione HTTP No-Vary-Search che indica che la pagina può essere utilizzata per qualsiasi parametro di ricerca id.

Tuttavia, se l'utente fa clic su uno dei link prima del completamento del precaricamento, il browser potrebbe non aver ricevuto la pagina /products. In questo caso, il browser non sa se conterrà l'intestazione HTTP No-Vary-Search. Il browser deve quindi scegliere se recuperare nuovamente il link o attendere il completamento del precaricamento per verificare se contiene un'intestazione HTTP No-Vary-Search. L'impostazione expects_no_vary_search consente al browser di sapere che la risposta della pagina dovrebbe contenere un'intestazione HTTP No-Vary-Search e di attendere il completamento del precaricamento.

Puoi anche aggiungere più parametri a expects_no_vary_search separandoli con uno spazio (poiché No-Vary-Search è un'intestazione strutturata HTTP):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Limitazioni delle regole di speculazione e miglioramenti futuri

Le regole di speculazione sono limitate alle pagine aperte nella stessa scheda, ma stiamo lavorando per ridurre questa limitazione.

Per impostazione predefinita, i prerendering sono limitati alle pagine della stessa origine. È possibile attivare il prerendering di pagine multiorigine dello stesso sito (ad esempio, https://a.example.com potrebbe eseguire il prerendering di una pagina su https://b.example.com). Per utilizzare questa funzionalità, la pagina speculativa (https://b.example.com in questo esempio) deve attivare l'opzione includendo un'intestazione HTTP Supports-Loading-Mode: credentialed-prerender, altrimenti Chrome annullerà la speculazione.

Le versioni future potrebbero anche consentire il prerendering per pagine multiorigine non dello stesso sito, a condizione che non esistano cookie per la pagina prerenderizzata e che la pagina prerenderizzata attivi un'intestazione HTTP Supports-Loading-Mode: uncredentialed-prerender simile.

Le regole di speculazione supportano già i precaricamenti multiorigine. Per i precaricamenti multiorigine dello stesso sito non esistono limitazioni. I precaricamenti multiorigine su siti diversi sono supportati solo se non esistono cookie per il dominio multiorigine. Se esistono cookie relativi alla visita precedente dell'utente a quel sito, la speculazione non verrà utilizzata e verrà mostrato un errore in DevTools.

Date queste limitazioni attuali, un pattern che può migliorare l'esperienza degli utenti sia per i link interni che per quelli esterni, ove possibile, è eseguire il prerendering degli URL della stessa origine e tentare di eseguire il precaricamento degli URL multiorigine:

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

La limitazione per impedire le speculazioni multiorigine per i link multiorigine per impostazione predefinita è necessaria per la sicurezza. Si tratta di un miglioramento rispetto a <link rel="prefetch"> per le destinazioni multiorigine che non inviano cookie, ma tentano comunque il precaricamento, il che comporterà un precaricamento inutile che deve essere inviato di nuovo o, peggio ancora, il caricamento della pagina errata.

Rileva il supporto dell'API Speculation Rules

Puoi rilevare le funzionalità del supporto dell'API Speculation Rules con i controlli HTML standard:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Aggiungi regole di speculazione in modo dinamico tramite JavaScript

Ecco un esempio di aggiunta di una regola di speculazione prerender con JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Puoi visualizzare una demo del prerendering dell'API Speculation Rules, utilizzando l'inserimento di JavaScript, in questa pagina demo del prerendering.

L'inserimento di un elemento <script type = "speculationrules"> direttamente nel DOM utilizzando innerHTML non registrerà le regole di speculazione per motivi di sicurezza e deve essere aggiunto come mostrato in precedenza. Tuttavia, i contenuti inseriti dinamicamente utilizzando innerHTML che contengono nuovi link verranno rilevati dalle regole esistenti nella pagina.

Analogamente, la modifica diretta del riquadro Elementi in Chrome DevTools per aggiungere l'elemento <script type = "speculationrules"> non registra le regole di speculazione. Per inserire le regole, è necessario eseguire lo script per aggiungere dinamicamente l'elemento al DOM dalla console.

Aggiungi regole di speculazione tramite un Tag Manager

Per aggiungere regole di speculazione utilizzando un gestore di tag come Google Tag Manager (GTM), è necessario inserirle tramite JavaScript, anziché aggiungere l'elemento <script type = "speculationrules"> direttamente tramite GTM per gli stessi motivi menzionati in precedenza:

Configurazione del tag HTML personalizzato in Google Tag Manager
Aggiunta di regole di speculazione tramite Google Tag Manager.

Tieni presente che questo esempio utilizza var perché GTM non supporta const.

Annulla le regole di speculazione

La rimozione delle regole di speculazione comporterà l'annullamento del prerendering. Tuttavia, quando ciò accade, è probabile che siano già state spese risorse per avviare il prerendering, pertanto è consigliabile non eseguire il prerendering se esiste la probabilità di doverlo annullare. D'altra parte, le risorse memorizzate nella cache possono comunque essere riutilizzate, quindi gli annullamenti potrebbero non essere completamente sprecati e potrebbero comunque essere utili per speculazioni e navigazioni future.

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Le speculazioni possono anche essere annullate utilizzando l'intestazione HTTP Clear-Site-Data con le istruzioni prefetchCache e prerenderCache.

Questo può essere utile quando lo stato viene modificato sul server. Ad esempio, quando chiami un'API "add-to-basket" o un'API di accesso o disconnessione.

Idealmente, questi aggiornamenti di stato dovrebbero essere propagati alle pagine prerenderizzate utilizzando API come l'API Broadcast Channel, ma se ciò non è possibile o finché non viene implementata questa logica, può essere più semplice annullare la speculazione.

Regole di speculazione e Content Security Policy

Poiché le regole di speculazione utilizzano un elemento <script>, anche se contengono solo JSON, devono essere incluse nel script-src Content-Security-Policy se il sito lo utilizza, utilizzando un hash o un nonce.

È possibile aggiungere un nuovo inline-speculation-rules a script-src per consentire il supporto degli elementi <script type="speculationrules"> inseriti da script con hash o nonce. Questa operazione non supporta le regole incluse nell'HTML iniziale, pertanto le regole devono essere inserite tramite JavaScript per i siti che utilizzano un CSP rigoroso.

Rileva e disattiva il prerendering

Il prerendering è in genere un'esperienza positiva per gli utenti, in quanto consente un rendering rapido delle pagine, spesso istantaneo. Ciò va a vantaggio sia dell'utente che del proprietario del sito, poiché le pagine prerenderizzate consentono un'esperienza utente migliore che potrebbe essere difficile da ottenere in altro modo.

Tuttavia, in alcuni casi potresti non voler eseguire il prerendering delle pagine, ad esempio quando le pagine cambiano stato, in base alla richiesta iniziale o all'esecuzione di JavaScript sulla pagina.

Attiva e disattiva il prerendering in Chrome

Il prerendering è attivato solo per gli utenti di Chrome con l'impostazione "Precarica le pagine" in chrome://settings/performance/. Inoltre, il prerendering è disattivato anche sui dispositivi con memoria ridotta o se il sistema operativo è in modalità Risparmio dati o Risparmio energetico. Consulta la sezione Limiti di Chrome.

Rileva e disattiva il prerendering lato server

Le pagine prerenderizzate verranno inviate con l'intestazione HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Per le pagine precaricate utilizzando l'API Speculation Rules, questa intestazione sarà impostata solo su prefetch:

Sec-Purpose: prefetch

I server possono rispondere in base a questa intestazione per registrare le richieste di speculazione, restituire contenuti diversi o impedire un prerendering. Se viene restituito un codice di risposta finale non riuscito, ovvero non compreso nell'intervallo 200-299 dopo i reindirizzamenti, la pagina non verrà prerenderizzata e l'eventuale pagina di precaricamento verrà ignorata. Tieni presente inoltre che le risposte 204 e 205 non sono valide per il prerendering, ma sono valide per il precaricamento.

Se non vuoi che una determinata pagina venga prerenderizzata, il modo migliore per assicurarti che ciò non accada è restituire un codice di risposta diverso da 2XX (ad esempio 503). Tuttavia, per offrire la migliore esperienza, è consigliabile consentire il prerendering, ma ritardare le azioni che dovrebbero verificarsi solo quando la pagina viene effettivamente visualizzata, utilizzando JavaScript.

Rileva il prerendering in JavaScript

L'API document.prerendering restituirà true durante il prerendering della pagina. Questo può essere utilizzato dalle pagine per impedire o ritardare determinate attività durante il prerendering fino all'effettiva attivazione della pagina.

Una volta attivato un documento prerenderizzato, anche activationStart di PerformanceNavigationTiming verrà impostato su un tempo diverso da zero che rappresenta il tempo trascorso tra l'avvio del prerendering e l'attivazione effettiva del documento.

Puoi avere una funzione per verificare la presenza di pagine di prerendering e prerenderizzate come la seguente:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Il modo più semplice per verificare se una pagina è stata prerenderizzata (completamente o parzialmente) è aprire DevTools dopo l'attivazione della pagina e digitare performance.getEntriesByType('navigation')[0].activationStart nella console. Se viene restituito un valore diverso da zero, significa che il prerendering della pagina è stato eseguito:

Console in Chrome DevTools che mostra un activationStart positivo che indica che è stato eseguito il prerendering della pagina
Test del prerendering nella console.

Quando la pagina viene attivata dall'utente che la visualizza, l'evento prerenderingchange viene inviato su document, che può essere utilizzato per attivare attività che in precedenza venivano avviate per impostazione predefinita al caricamento pagina, ma che vuoi ritardare fino a quando la pagina non viene effettivamente visualizzata dall'utente.

Utilizzando queste API, JavaScript frontend può rilevare e agire sulle pagine prerenderizzate in modo appropriato.

Impatto su Analytics

I dati di analisi vengono utilizzati per misurare l'utilizzo del sito web, ad esempio utilizzando Google Analytics per misurare le visualizzazioni di pagina e gli eventi. In alternativa, misurando le metriche sul rendimento delle pagine utilizzando il Real User Monitoring (RUM).

Il prerendering delle pagine deve essere eseguito solo quando esiste un'alta probabilità che la pagina venga caricata dall'utente. Ecco perché le opzioni di prerendering della barra degli indirizzi di Chrome vengono eseguite solo quando la probabilità è molto alta (superiore all'80% delle volte).

Tuttavia, in particolare quando si utilizza l'API Speculation Rules, le pagine prerenderizzate potrebbero avere un impatto sull'analisi e i proprietari dei siti potrebbero dover aggiungere un codice aggiuntivo per attivare l'analisi solo per le pagine prerenderizzate al momento dell'attivazione, poiché non tutti i fornitori di analisi potrebbero farlo per impostazione predefinita.

Questo risultato può essere ottenuto utilizzando un Promise che attende l'evento prerenderingchange se un documento è in fase di prerendering o si risolve immediatamente se è ora:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Un approccio alternativo consiste nel ritardare le attività di analisi fino alla prima visualizzazione della pagina, il che coprirebbe sia il caso di prerendering sia l'apertura delle schede in background (ad esempio, fare clic con il tasto destro del mouse e l'apertura in una nuova scheda):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Sebbene ciò possa avere senso per l'analisi e casi d'uso simili, in altri casi potresti voler caricare più contenuti e quindi utilizzare document.prerendering e prerenderingchange per scegliere come target specifico le pagine di prerendering.

Trattenere altri contenuti durante il prerendering

Le stesse API descritte in precedenza possono essere utilizzate per bloccare altri contenuti durante la fase di prerendering. Può trattarsi di parti specifiche di JavaScript o di interi elementi di script che preferisci non eseguire durante la fase di prerendering.

Ad esempio, dato questo script:

<script src="https://example.com/app/script.js" async></script>

Puoi sostituirlo con un elemento script inserito dinamicamente che viene inserito solo in base alla funzione whenActivated precedente:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Questo può essere utile per bloccare script distinti che includono analisi o per eseguire il rendering dei contenuti in base allo stato o ad altre variabili che possono cambiare nel corso di una visita. Ad esempio, i consigli, lo stato di accesso o le icone del carrello potrebbero essere trattenuti per garantire che vengano presentate le informazioni più aggiornate.

Sebbene ciò possa verificarsi più spesso con l'utilizzo del prerendering, queste condizioni sono valide anche per le pagine caricate nelle schede in background menzionate in precedenza (quindi la funzione whenFirstVisible potrebbe essere utilizzata al posto di whenActivated).

In molti casi, lo stato dovrebbe essere controllato anche in caso di modifiche generali di visibilitychange. Ad esempio, quando si torna a una pagina che è stata in background, i contatori del carrello degli acquisti dovrebbero essere aggiornati con il numero più recente di articoli nel carrello. Quindi non si tratta di un problema specifico del prerendering, ma il prerendering rende più evidente un problema esistente.

Un modo in cui Chrome riduce la necessità di eseguire manualmente il wrapping di script o funzioni è che alcune API vengono trattenute, come menzionato in precedenza, e inoltre gli iframe di terze parti non vengono visualizzati, quindi è necessario trattenere manualmente solo i contenuti aggiuntivi.

Misurare il rendimento

Per misurare le metriche sul rendimento, l'analisi dovrebbe valutare se è meglio misurarle in base al tempo di attivazione anziché al tempo di caricamento della pagina che verrà registrato dalle API del browser.

Per quanto riguarda i Core Web Vitals, misurati da Chrome tramite il Chrome User Experience Report, l'obiettivo è misurare l'esperienza utente. Quindi, vengono misurati in base al tempo di attivazione. Spesso, questo si traduce in un LCP di 0 secondi, ad esempio, dimostrando che si tratta di un ottimo modo per migliorare i Core Web Vitals.

A partire dalla versione 3.1.0, la libreria web-vitals è stata aggiornata per gestire le navigazioni prerenderizzate nello stesso modo in cui Chrome misura i Core Web Vitals. Questa versione segnala anche le navigazioni prerenderizzate per queste metriche nell'attributo Metric.navigationType se la pagina è stata prerenderizzata completamente o parzialmente.

Misura i prerender

Se una pagina è stata prerenderizzata, puoi vedere una voce activationStart diversa da zero di PerformanceNavigationTiming. Questi dati possono poi essere registrati utilizzando una dimensione personalizzata o un metodo simile durante la registrazione delle visualizzazioni di pagina, ad esempio utilizzando la funzione pagePrerendered descritta in precedenza:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

In questo modo, l'analisi mostrerà quante navigazioni sono prerenderizzate rispetto ad altri tipi di navigazione e ti consentirà di correlare eventuali metriche sul rendimento o metriche aziendali a questi diversi tipi di navigazione. Pagine più veloci significano utenti più soddisfatti, il che spesso può avere un impatto reale sulle metriche aziendali, come dimostrano i nostri case study.

Mentre misuri l'impatto aziendale del prerendering delle pagine per le navigazioni istantanee, puoi decidere se vale la pena investire più impegno nell'utilizzo di questa tecnologia per consentire il prerendering di più navigazioni o per indagare sul motivo per cui le pagine non vengono prerenderizzate.

Misura le percentuali di hit

Oltre a misurare l'impatto delle pagine visitate dopo un prerendering, è importante anche misurare le pagine prerenderizzate e non visitate successivamente. Ciò potrebbe implicare che stai eseguendo un prerendering eccessivo e utilizzando risorse preziose dell'utente per un vantaggio minimo.

Questo può essere misurato attivando un evento di analisi quando vengono inserite le regole di speculazione, dopo aver verificato che il browser supporti il prerendering utilizzando HTMLScriptElement.supports('speculationrules'), per indicare che è stato richiesto il prerendering. (Tieni presente che il fatto che sia stato richiesto un prerendering non indica che sia stato avviato o completato, poiché, come indicato in precedenza, un prerendering è un suggerimento per il browser e quest'ultimo potrebbe scegliere di non prerenderizzare le pagine in base alle impostazioni utente, alla memoria utilizzata attuale o ad altre euristiche.)

Puoi quindi confrontare il numero di questi eventi con le visualizzazioni di pagina di prerendering effettive. In alternativa, attiva un altro evento all'attivazione se questo semplifica il confronto.

Il "tasso di hit riusciti" può quindi essere approssimato osservando la differenza tra queste due cifre. Per le pagine in cui utilizzi l'API Speculation Rules per eseguire il prerendering delle pagine, puoi modificare le regole in modo appropriato per assicurarti di mantenere un tasso di hit elevato e mantenere l'equilibrio tra l'utilizzo delle risorse degli utenti per aiutarli e l'utilizzo inutile.

Tieni presente che potrebbe essere in corso un prerendering dovuto al prerendering della barra degli indirizzi e non solo alle regole di speculazione. Se vuoi differenziarle, puoi controllare la proprietà document.referrer (che sarà vuota per la navigazione dalla barra degli indirizzi, incluse le navigazioni dalla barra degli indirizzi con prerendering).

Ricorda di esaminare anche le pagine che non hanno prerendering, in quanto ciò potrebbe indicare che queste pagine non sono idonee per il prerendering, nemmeno dalla barra degli indirizzi. Ciò potrebbe significare che non stai usufruendo di questo miglioramento del rendimento. Il team di Chrome sta cercando di aggiungere strumenti aggiuntivi per testare l'idoneità al prerendering, forse simili allo strumento di test bfcache, e potenzialmente anche un'API per mostrare il motivo per cui un prerendering non è riuscito.

Impatto sulle estensioni

Consulta il post dedicato su Estensioni di Chrome: estensione dell'API per supportare la navigazione istantanea, che descrive in dettaglio alcune considerazioni aggiuntive che gli autori di estensioni potrebbero dover tenere presenti per le pagine prerenderizzate.

Feedback

Il prerendering è in fase di sviluppo attivo da parte del team di Chrome e sono previsti molti piani per espandere l'ambito di ciò che è stato reso disponibile nella release di Chrome 108. Saremo lieti di ricevere feedback sul repository GitHub o tramite il nostre Issue Tracker e non vediamo l'ora di ascoltare e condividere i case study di questa nuova entusiasmante API.

Ringraziamenti

Immagine in miniatura di Marc-Olivier Jodoin su Unsplash