Data di pubblicazione: 7 marzo 2025
L'API Speculation Rules consente agli utenti di usufruire di un aumento delle prestazioni tramite il prefetching o il pre-rendering delle navigazioni future delle pagine per offrire navigazioni più rapide o addirittura istantanee.
L'API è stata progettata specificamente pensando alla facilità di implementazione, ma ci sono alcune considerazioni che i siti complessi in particolare devono prendere in considerazione prima di utilizzarla. Questa guida aiuta i proprietari di siti a comprendere queste considerazioni.
Pianificazione
Prima di implementare le regole di speculazione, vale la pena considerare come implementare l'API (poiché sono disponibili alcune opzioni) e anche i costi delle speculazioni (che dovrebbero guidarti in merito alle pagine su cui fare speculazioni).
Decidere come implementare le regole di speculazione
Una delle prime decisioni da prendere è come implementare le regole di speculazione sul tuo sito, in quanto sono disponibili diversi metodi:
- Direttamente nel codice HTML della pagina
- Utilizzo di JavaScript
- Utilizzo di un'intestazione HTTP
In definitiva, ogni metodo ha lo stesso effetto, ma possono esserci vantaggi in termini di facilità di implementazione e flessibilità.
I siti devono scegliere l'opzione più adatta alle loro esigenze e, se necessario, possono anche utilizzare una combinazione di queste opzioni. In alternativa, possono essere implementati utilizzando un plug-in (ad esempio il plug-in di caricamento speculativo per WordPress) o librerie o piattaforme che potrebbero fare la scelta per te, ma vale comunque la pena conoscere le opzioni disponibili.
Includi le regole di speculazione direttamente nel codice HTML della pagina
Le regole di speculazione possono essere implementate direttamente nella pagina includendo l'elemento <script type="speculationrules"> nel codice HTML. Questo può essere aggiunto in fase di compilazione per i siti statici che utilizzano i modelli o in fase di esecuzione dal server quando viene richiesta la pagina. Possono anche essere iniettati in HTML dagli edge worker (anche se il metodo dell'intestazione HTTP discusso più avanti in questa guida è probabilmente più semplice per questo).
In questo modo puoi includere regole statiche nell'intero sito, ma le regole del documento possono comunque essere dinamiche perché ti consentono di scegliere gli URL da visualizzare nella pagina utilizzando regole da attivare tramite classi CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Lo script precedente eseguirà il prerendering dei link con una classe prerender e, in modo simile, il pre-caricamento quando un link ha una classe prerender.prefetch In questo modo, gli sviluppatori possono includere queste classi in HTML per attivare le speculazioni.
Oltre a includere i link a questi elementi nell'HTML iniziale di una pagina, i link verranno dedotti anche se questi elementi vengono aggiunti dinamicamente dall'app, il che consente all'app di attivare (e rimuovere) le deduzioni in base alle esigenze. Questo può essere più semplice che creare o rimuovere regole di speculazione più specifiche. È anche possibile includere più regole di speculazione per pagina se vuoi una regola di base utilizzata dalla maggior parte del sito e regole specifiche per pagina.
In alternativa, se devi utilizzare regole di speculazione più specifiche, le regole specifiche per pagina o modello possono consentire regole diverse per determinate pagine o tipi di pagine.
Infine, le pagine con rendering lato server possono avere anche regole più dinamiche in base alle informazioni disponibili per il server, ad esempio informazioni di analisi per quella pagina o percorsi utente comuni per determinate pagine.
Aggiungere regole di speculazione utilizzando JavaScript
Un'alternativa all'inclusione delle regole in uno script in-page è inserirle utilizzando JavaScript. Ciò potrebbe richiedere meno aggiornamenti ai modelli di pagina. Ad esempio, l'inserimento delle regole da parte di un tag manager può essere un modo rapido per implementare le regole di speculazione (e consente anche di disattivarle rapidamente, se necessario).
Questa opzione consente anche regole dinamiche lato client in base al modo in cui l'utente interagisce con la pagina. Ad esempio, se l'utente aggiunge un articolo al carrello, puoi eseguire il prerendering della pagina di pagamento. In alternativa, può essere utilizzato per attivare speculazioni in base a determinate condizioni. Sebbene l'API includa un'impostazione di intensità che consente regole di base basate sulle interazioni, JavaScript consente agli sviluppatori di utilizzare la propria logica per decidere quando e su quali pagine fare previsioni.
Come accennato in precedenza, un approccio alternativo all'inserimento di nuove regole consiste nel disporre di una regola di base per i documenti nella pagina e di attivare le regole dei documenti con JavaScript aggiungendo classi appropriate ai link in modo che corrispondano alla regola.
Aggiungere regole di speculazione utilizzando un'intestazione HTTP
L'ultima opzione per gli sviluppatori è includere le regole utilizzando un'intestazione HTTP:
Speculation-Rules: "/speculationrules.json"
Esistono alcuni requisiti aggiuntivi per la modalità di caricamento e utilizzo della risorsa regole (/speculationrules.json in questo esempio).
Questa opzione consente un deployment più semplice da parte delle CDN senza dover modificare i contenuti del documento. Ciò significa che non è possibile modificare le regole di scommessa in modo dinamico utilizzando JavaScript. Tuttavia, le regole del documento con attivatori di selettori CSS possono comunque consentire modifiche dinamiche, ad esempio rimuovendo la classe prerender da un link.
Analogamente all'opzione JavaScript, l'implementazione delle regole di speculazione con un'intestazione HTTP consente di implementarle indipendentemente dai contenuti del sito, il che può semplificare l'aggiunta e la rimozione delle regole senza una ricostruzione completa del sito.
Valuta le implicazioni sui costi
Prima di implementare le regole di speculazione, ti consigliamo di prenderti un po' di tempo per valutare le implicazioni in termini di costi per gli utenti e per il tuo sito con questa API. I costi includono la larghezza di banda (che comporta un costo sia per gli utenti sia per i siti) e i costi di elaborazione (sia lato client sia lato server).
Tieni conto del costo per gli utenti
Il caricamento speculativo consiste nel fare un'ipotesi informata su dove un utente potrebbe passare a una nuova pagina. Tuttavia, se la navigazione non avviene, potresti aver sprecato risorse. Ecco perché devi essere consapevole dell'impatto sugli utenti, in particolare:
- Larghezza di banda aggiuntiva utilizzata per scaricare le navigazioni future, in particolare sui dispositivi mobili, dove la larghezza di banda potrebbe essere più limitata.
- Costi di elaborazione aggiuntivi per il rendering di queste pagine quando si utilizza il prerendering.
Con previsioni completamente accurate, non sono previsti costi aggiuntivi, perché i visitatori visiteranno queste pagine in un secondo momento, con l'unica differenza che questi costi vengono caricati in anticipo. Tuttavia, è impossibile prevedere il futuro con assoluta precisione e, più aggressiva è la strategia di speculazione, maggiore è il rischio di spreco.
Chrome ha esaminato attentamente questo problema e l'API include una serie di funzionalità che significano che il costo è molto più basso di quanto potresti pensare. In particolare, riutilizzando la cache HTTP e non caricando iframe cross-origin, il costo del prerendering di una navigazione nello stesso sito è spesso notevolmente inferiore a quello di una pagina completa senza risorse memorizzate nella cache, rendendo i caricamenti speculativi meno costosi di quanto si possa supporre.
Tuttavia, anche con queste misure di salvaguardia, i siti devono valutare attentamente le pagine su cui fare offerte e il costo per l'utente di queste offerte. I candidati ideali per il caricamento speculativo sono quelli che possono essere ragionevolmente previsti con un elevato grado di certezza (ad esempio in base ad analisi o percorsi comuni degli utenti) e quando il costo è basso (ad esempio pagine meno ricche).
Ti consigliamo inoltre di valutare quale codice JavaScript deve essere ritardato fino all'attivazione. In modo simile al caricamento differito dei contenuti finché non sono necessari, questa operazione può rendere i pre-rendering meno costosi, ma offre un'esperienza utente molto migliorata. Con le speculazioni più economiche, potresti sentirti a tuo agio a fare speculazioni più frequentemente o con maggiore entusiasmo.
Se non è possibile, ti consigliamo di utilizzare una strategia meno aggressiva che utilizza regole di proattività moderate o conservative. In alternativa, puoi utilizzare il prefetch, che ha un costo notevolmente inferiore rispetto al prerendering quando il livello di attendibilità è basso, per poi eseguire l'upgrade a un prerendering completo se il livello di attendibilità aumenta, ad esempio quando si passa il mouse sopra un link o si fa clic su di esso.
Valuta il carico extra del backend
Oltre a considerare i costi aggiuntivi per l'utente, i proprietari dei siti devono considerare i propri costi di infrastruttura. Se ogni pagina genera due, tre o più caricamenti di pagine, i costi di backend potrebbero aumentare con l'utilizzo di questa API.
Garantire che le pagine e le risorse siano memorizzabili nella cache ridurrà notevolmente il carico dell'origine e, di conseguenza, il rischio complessivo. Se li combini con una CDN, i tuoi server di origine dovrebbero avere un carico aggiuntivo minimo, ma tieni conto di eventuali aumenti dei costi della CDN.
Un server o una CDN può essere utilizzato anche per controllare i risultati delle speculazioni identificati dall'intestazione HTTP sec-purpose. Ad esempio, il prodotto Speed Brain di Cloudflare consente solo le speculazioni già memorizzate nella cache sul server edge di una CDN e non invia nuovamente le richieste all'origine.
Tuttavia, poiché i caricamenti speculativi vengono in genere utilizzati per i caricamenti di pagine dello stesso dominio, gli utenti avranno già risorse condivise nella cache del browser, a condizione che siano memorizzabili nella cache. Pertanto, una speculazione in genere non è così onerosa come un caricamento completo della pagina.
Trovare il giusto equilibrio tra fare troppe o troppo poche speculazioni
La chiave per ottenere il massimo dall'API Speculation Rules è trovare il giusto equilibrio tra fare troppe speculazioni, ovvero quando i costi vengono pagati inutilmente e la speculazione non viene utilizzata, e fare troppo poco o troppo tardi, quando i vantaggi sono scarsi.
Se i costi sono ridotti (ad esempio, pagine piccole generate in modo statico memorizzate nella cache sui nodi di confine CDN), puoi permetterti di essere più aggressivo con le speculazioni.
Tuttavia, per le pagine più grandi e più complete che forse non possono essere memorizzate nella cache all'edge della CDN, è necessario prestare maggiore attenzione. Analogamente, le pagine che richiedono molte risorse possono utilizzare la larghezza di banda della rete o la potenza di elaborazione, il che può influire negativamente sulla pagina corrente. Lo scopo dell'API è migliorare le prestazioni, quindi le regressioni del rendimento non sono assolutamente ciò che vogliamo. Questo è un altro motivo per limitare i prerendering a una o due pagine al massimo (tieni presente che Chrome ne limita a due o dieci alla volta, a seconda dell'eagerness).
Passaggi per implementare le regole di speculazione
Una volta deciso come implementare le regole di speculazione, devi pianificare cosa fare e come implementare la strategia. I siti più semplici, come i blog personali statici, potrebbero essere in grado di passare direttamente al prerendering completo di determinate pagine, ma i siti più complessi presentano complessità aggiuntive da considerare.
Inizia con il prefetch
Di solito, l'implementazione del pre-caricamento è relativamente sicura per la maggior parte dei siti e questo è l'approccio iniziale adottato da molti, inclusi gli implementazioni su larga scala come Cloudflare e WordPress.
I problemi principali da tenere presente sono che il pre-caricamento di un URL può causare modifiche dello stato e costi lato server, in particolare per le pagine non memorizzabili nella cache. Idealmente, le modifiche dello stato, ad esempio il pre-caricamento di una pagina /logout, non dovrebbero essere implementate come link GET, ma purtroppo questo non è insolito sul web.
Questi URL possono essere esclusi specificamente dalle regole:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
I pre-caricamenti possono essere limitati alle navigazioni comuni da una pagina all'altra o per tutti i link della stessa origine al passaggio del mouse o al clic utilizzando l'impostazione moderate o conservative eagerness. L'impostazione conservative comporta il rischio più basso, ma anche il rendimento potenziale più basso. Se parti da qui, punta almeno a moderate, ma idealmente oltre a eager per ottenere ulteriori vantaggi in termini di rendimento (e poi esegui l'upgrade a prerender, se opportuno).
Prerendering a basso rischio
Le speculazioni di precaricamento sono più facili da implementare, ma il vantaggio finale in termini di prestazioni dell'API è il prerendering. Questo può comportare alcune considerazioni aggiuntive quando la pagina non viene visitata poco dopo la speculazione (argomento che tratteremo nella sezione successiva), ma con un prerendering di moderate o conservative, dove è probabile che la navigazione avvenga poco dopo, il passaggio successivo potrebbe essere relativamente poco rischioso.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Esegui il pre-caricamento delle pagine comuni per migliorare i pre-rendering non eager
Una tattica comune è prelevare un numero minore di pagine successive visitate di frequente al caricamento con un'impostazione eager (specificandole in un elenco di URL o utilizzando selector_matches) e poi eseguire il prerendering con un'impostazione moderate. Poiché è probabile che il pre-caricamento HTML sia stato completato al momento del passaggio del mouse sopra il link, questo offre un vantaggio rispetto al semplice pre-rendering al passaggio del mouse senza pre-caricamento.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Prerendering precedenti
Sebbene le regole dei documenti moderate consentano un utilizzo dell'API con rischi relativamente ridotti e una relativa facilità di implementazione, spesso il tempo non è sufficiente per un prerendering completo. Per ottenere le navigazioni istantanee consentite da questa API, probabilmente dovrai fare di più e eseguire il prerendering delle pagine in modo più rapido.
Questo risultato viene ottenuto con un elenco statico di URL (come nell'esempio di prefetch precedente) o con selector_matches che identifica un numero limitato di URL (idealmente una o due pagine), con regole del documento che coprono gli altri URL:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Per avere le migliori probabilità di prevedere con precisione la navigazione successiva, potrebbe essere necessaria un'analisi del traffico. Comprendere i percorsi tipici dei clienti sul tuo sito può anche aiutarti a identificare buoni candidati per il caricamento speculativo.
Il passaggio a un prerendering più avido può anche introdurre ulteriori considerazioni su analisi, annunci e JavaScript e sulla necessità di mantenere aggiornata una pagina preriferita o addirittura di annullare o aggiornare le supposizioni sulle modifiche dello stato.
Analytics, annunci e JavaScript
Quando utilizzi il prerendering, i siti più complessi devono anche considerare l'impatto su Analytics. In genere, non è consigliabile registrare una visualizzazione di pagina (o annuncio) quando la pagina è oggetto di speculazione e solo quando la speculazione è attivata.
Alcuni fornitori di servizi di analisi (come Google Analytics) e fornitori di servizi pubblicitari (come il tag publisher Google) supportano già le regole di speculazione e non registrano le visualizzazioni finché la pagina non viene attivata. Tuttavia, altri fornitori o analisi personalizzate che hai implementato potrebbero richiedere un'attenzione aggiuntiva.
Puoi aggiungere controlli a JavaScript per impedire l'esecuzione di parti specifiche di codice fino a quando le pagine non vengono attivate o rese visibili e persino incapsulare interi elementi <script> in questi controlli. Se le pagine utilizzano gestori di tag per iniettare questi script, potrebbe essere possibile affrontarli tutti in una volta ritardando lo script del gestore di tag stesso.
Analogamente, i gestori del consenso sono un'opportunità per ritardare gli script di terze parti fino all'attivazione e Google collabora con varie piattaforme di gestione del consenso per renderle compatibili con il prerendering. Saremo lieti di aiutare chi vuole fare lo stesso. PubTech è una di queste aziende che offre agli sviluppatori la possibilità di eseguire o bloccare il proprio codice JavaScript durante il prerendering.
Analogamente, per il codice dell'applicazione puoi aggiungere una modifica per ritardare l'esecuzione del codice fino all'attivazione, in particolare se la pagina non richiede il rendering del codice JavaScript. Si tratta di un'opzione più rapida e sicura, ma significa che tutto il codice verrà eseguito contemporaneamente all'attivazione. Ciò può comportare un sacco di lavoro al momento dell'attivazione, che può influire sull'INP, soprattutto perché la pagina potrebbe sembrare completamente caricata e pronta per essere utilizzata.
Inoltre, se i contenuti dipendono da JavaScript (ad esempio i contenuti con rendering lato client), il ritardo ridurrà l'impatto positivo sul LCP e sul CLS che il prerendering può avere. Un approccio più mirato per consentire l'esecuzione di più codice JavaScript durante la fase di prerendering comporterà un'esperienza migliore, ma potrebbe essere meno banale da implementare.
Iniziare a posticipare completamente molti tag script può essere una buona strategia per i siti più complessi all'inizio. Tuttavia, per ottenere il massimo vantaggio dall'API, l'obiettivo finale dovrebbe essere consentire l'esecuzione di più JavaScript possibile durante il prerendering.
I siti con problemi relativi ad annunci o dati e analisi potrebbero anche iniziare con il prefetch, dove questi problemi sono meno gravi, mentre valutano cosa occorre fare per supportare il prerendering.
Aggiorna le supposizioni di prerendering
Quando esegui il prerendering delle pagine prima della navigazione, c'è il rischio che la pagina preriferita diventi obsoleta. Ad esempio, una pagina pre-renderizzata di un sito di e-commerce potrebbe includere un carrello di pagamento, un carrello pieno di articoli o anche solo un contatore che mostra il numero di articoli nel carrello in altre pagine. Se vengono aggiunti altri articoli a un carrello e poi si accede a una pagina pre-renderizzata, sarebbe fonte di confusione per l'utente vedere il vecchio stato di pagamento.
Non si tratta di un problema nuovo e si verifica anche quando gli utenti hanno più schede aperte nel browser. Tuttavia, con le pagine pre-renderizzate questo è più probabile e più inaspettato, poiché l'utente non ha avviato consapevolmente il pre-rendering.
L'API Broadcast Channel è un modo per consentire a una pagina del browser di trasmettere aggiornamenti come questo ad altre pagine. In questo modo si risolverebbe anche il problema delle schede multiple. Le pagine pre-renderizzate possono ascoltare i messaggi di trasmissione, ma non possono inviare i propri messaggi di trasmissione finché non vengono attivate.
In alternativa, le pagine pre-renderizzate possono ricevere aggiornamenti utilizzando il server (con una chiamata fetch() periodica o una connessione WebSocket), ma con potenziali ritardi negli aggiornamenti.
Annullare o aggiornare le supposizioni di prerendering
L'aggiornamento di una pagina sottoposta a prerendering è l'approccio consigliato per continuare a utilizzare le pagine sottoposte a prerendering evitando di creare confusione tra gli utenti. Se ciò non è possibile, è possibile annullare le speculazioni.
Questa tecnica può essere utilizzata anche per rispettare i limiti di Chrome se i siti vogliono eseguire il prerendering di altre pagine che hanno maggiori probabilità di essere visitate.
Per annullare le speculazioni, devi rimuovere le regole di speculazione dalla pagina oppure rimuovere classi o altri criteri di corrispondenza, se utilizzi questo approccio. In alternativa, la pagina supposta può chiamare window.close() se rileva che non è più attuale. Tuttavia, se la pagina è in grado di rilevarlo, un'opzione migliore sarebbe aggiornarne lo stato per riportarlo in linea.
È anche possibile reinserire queste regole (o criteri di corrispondenza) in modo che le pagine possano essere pre-generate di nuovo (anche se, di nuovo, mantenere aggiornata una pagina esistente è in genere l'opzione migliore in quanto meno dispendiosa). Dopo la rimozione delle regole di speculazione, il riassorbimento deve essere completato in un nuovo microtask o in un secondo momento, per consentire al browser di rilevare le rimozioni e annullare le speculazioni. Un approccio per eliminare e rimuovere tutti gli script delle regole di speculazione è mostrato nell'esempio seguente:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
La rimozione delle regole annullerà i pretendenti (o i pre-caricamenti) esistenti, ma la loro reinserimento ipotizzerà solo regole immediate o eager (incluse le regole degli elenchi di URL che utilizzano il valore predefinito di immediate). Tuttavia, le speculazioni moderate o conservative verranno rimosse, ma non riattivate automaticamente finché non verrà eseguita nuovamente un'interazione con il link.
Questa opzione di aggiornamento non è limitata alle regole inserite in JavaScript. Anche le regole statiche incluse nell'HTML possono essere rimosse o modificate nello stesso modo, poiché si tratta di una modifica DOM standard. Le regole di speculazione HTTP non possono essere rimosse, ma i criteri di corrispondenza (ad esempio le classi prerender) possono essere rimossi e aggiunti di nuovo da JavaScript.
Chrome sta anche valutando l'aggiunta del supporto di Clear-Site-Header per consentire alle risposte del server di annullare i pre-rendering (ad esempio quando viene effettuata una richiesta di aggiornamento del carrello).
Misurare l'impatto
Dopo aver implementato le regole di speculazione, devi misurare il successo e non semplicemente presumere che sia automaticamente più veloce. Come accennato in precedenza, l'over-speculation può causare regressioni delle prestazioni se il client o il server sono sovraccaricati.
Quando esegui l'implementazione con più passaggi (prefetch, prerendering a basso rischio e prerendering anticipato), devi eseguire la misurazione in ogni passaggio.
Come misurare il successo
Le regole di speculazione dovrebbero avere un impatto positivo sulle metriche di rendimento chiave come LCP (e possibilmente anche su CLS e INP), ma questo potrebbe non essere evidente nelle metriche complessive a livello di sito. Questo perché i siti potrebbero essere costituiti principalmente da altri tipi di navigazione (ad esempio pagine di destinazione) o perché le navigazioni all'interno della stessa origine sono già abbastanza veloci da non influire sulle metriche del 75° percentile, come riportato nel Report sull'esperienza utente di Chrome (CrUX), anche se migliorate notevolmente.
Puoi utilizzare i tipi di navigazione tra pagine in CrUX per controllare la percentuale di navigazioni di tipo navigate_cache o prerender e se questa percentuale aumenta nel tempo. Tuttavia, per un'analisi dettagliata, potresti dover utilizzare il monitoraggio degli utenti reali per segmentare i dati in navigazioni stimate per vedere quanto sono più veloci rispetto ad altre navigazioni.
Come misurare l'utilizzo e lo spreco
Un'altra considerazione importante è misurare se stai facendo offerte sulle pagine corrette. In questo modo, eviti gli sprechi e scegli come target le pagine migliori per trarre vantaggio da questa API.
Purtroppo, la pagina che avvia le speculazioni non è in grado di vedere direttamente lo stato dei tentativi di speculazione. Inoltre, non si può presumere che i tentativi siano stati attivati, poiché il browser potrebbe trattenere le speculazioni in determinate circostanze. Pertanto, devono essere misurati nella pagina stessa. Inoltre, è necessario controllare due API per verificare se la pagina effettua o ha effettuato speculazioni:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Questa pagina può quindi registrare il tentativo di speculazione sui server di backend.
Un aspetto complicato dell'analisi è che i fornitori (come Google Analytics) sono compatibili con il prerendering e ignorano le chiamate di analisi fino all'attivazione della pagina, anche le chiamate di eventi separate. Pertanto, gli utenti di Google Analytics devono utilizzare un'altra opzione di registrazione lato server.
È possibile anche lato client, in cui ogni pagina pre-renderizzata registra il pre-rendering nello spazio di archiviazione condiviso e la pagina chiamante lo legge. localStorage è la scelta migliore perché può essere letto quando si esce da una pagina (tieni presente che sessionStorage non può essere utilizzato perché ha un trattamento speciale per le pagine pre-renderizzate). Tuttavia, tieni presente che localStorage non è sicuro per le transazioni e altre pagine potrebbero aggiornarlo contemporaneamente se vengono pre-elaborate più pagine. Questa demo utilizza un hash univoco e voci individuali per evitare problemi.
Conclusione
Le regole di speculazione offrono la possibilità di un notevole miglioramento del rendimento delle tue pagine. Questa guida fornisce consigli sulle considerazioni da tenere presenti durante l'implementazione di questa API per evitare potenziali problemi e ottenere il massimo dall'API.
Pianificare in anticipo l'implementazione eviterà di dover ripetere il lavoro. In particolare per i siti più complessi, deve essere seguito da un'implementazione in più passaggi, a partire dal pre-caricamento prima di passare al pre-rendering a basso rischio e poi al pre-rendering anticipato. Infine, è importante misurare i miglioramenti, nonché l'utilizzo e lo spreco, per assicurarti di utilizzare l'API in modo ottimale.