Supporto dei browser
Il team di Chrome ha ripristinato il prerendering completo delle pagine future che un utente potrebbe visitare.
Una breve storia del prerendering
In passato, Chrome supportava il suggerimento relativo alle risorse <link rel="prerender" href="/next-page">
, che tuttavia non era supportato su larga scala oltre Chrome e non era un'API molto espressiva.
Questo prerendering precedente che utilizzava l'indicazione del link rel=prerender
è stato ritirato a favore del precaricamento senza stato, che invece recuperava le risorse necessarie per la pagina futura, ma non eseguiva il prerendering completo della pagina né JavaScript. Il precaricamento NoState contribuisce a migliorare le prestazioni della pagina migliorando il caricamento delle risorse, ma non garantisce 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 per consentire l'espansione futura del prerendering, questo nuovo meccanismo di prerendering non utilizzerà la sintassi <link rel="prerender"...>
, che rimarrà in vigore per il precaricamento senza stato, con l'obiettivo di ritirarla in futuro.
Come viene eseguito il prerendering di una pagina?
È possibile eseguire il prerendering di una pagina in quattro modi, ognuno dei quali ha lo scopo di rendere la navigazione più rapida:
- 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 elevata certezza che la visiterai, in base alla tua cronologia di navigazione precedente.
- Quando utilizzi la barra dei preferiti, Chrome potrebbe eseguire automaticamente il prerendering della pagina se tieni premuto il cursore sopra uno dei pulsanti dei preferiti.
- 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 il motore di ricerca lo richiede.
- I siti possono utilizzare l'API Speculation Rules per indicare a Chrome in modo programmatico quali pagine prerenderizzare. Questa operazione sostituisce la precedente funzionalità di
<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 elementi possono esistere in modo statico nelle pagine o essere iniettati dinamicamente da JavaScript in base alle esigenze del proprietario della pagina.
In ognuno di questi casi, un prerendering si comporta come se la pagina fosse stata aperta in una scheda di sfondo invisibile, quindi viene "attivato" sostituendo la scheda in primo piano con quella pagina sottoposta a prerendering. Se una pagina viene attivata prima del prerendering completo, il suo stato corrente è "in primo piano" e continua a caricarsi, il che significa che puoi comunque avere un buon vantaggio.
Quando la pagina sottoposta a prerendering viene aperta in 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. Nei rari casi in cui ciò non sia 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 al fine di semplificare l'identificazione di questi casi limite.
Impatto del prerendering
Il prerendering consente un caricamento della pagina quasi istantaneo, come mostrato nel seguente video:
Il sito di esempio è già 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 valore LCP quasi pari a zero, una riduzione della metrica CLS (dal momento che qualsiasi caricamento avviene prima della visualizzazione iniziale) e un miglioramento INP (dal momento che il caricamento deve essere completato prima dell'interazione dell'utente).
Anche se una pagina viene attivata prima di essere completamente caricata, avere un vantaggio sul caricamento della pagina dovrebbe migliorare l'esperienza di caricamento. Quando un link viene attivato mentre è ancora in corso il prerendering, la pagina del prerendering viene spostata nel frame principale e il caricamento continua.
Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntive. Fai attenzione a non eseguire un prerendering eccessivo, a discapito delle risorse utente. Esegui il prerendering solo quando è molto probabile che l'utente visiti la pagina.
Per ulteriori informazioni su come misurare l'impatto effettivo sul rendimento in Analytics, consulta la sezione Misurazione del rendimento.
Visualizzare 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
:
Le linee verdi indicano una confidenza sufficiente per attivare il prerendering. In questo esempio, digitare "s" fornisce un livello di confidenza ragionevole (ambra), ma una volta digitato "sh", Chrome ha la certezza sufficiente che quasi sempre accedi a https://sheets.google.com
.
Questo screenshot è stato acquisito in un'installazione di Chrome relativamente recente e ha escluso le previsioni con confidenza pari a zero, ma se visualizzi i tuoi predittori probabilmente vedrai molte più voci 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:
Chrome aggiorna continuamente i suoi predittori in base alle tue digitazioni e selezioni.
- Per un livello di confidenza superiore al 50% (indicato in ambra), Chrome esegue la preconnessione al dominio in modo proattivo, ma non esegue il prerendering della pagina.
- Per un livello di confidenza superiore all'80% (visualizzato in verde), Chrome eseguirà il prerendering dell'URL.
L'API Speculation Rules
Per l'opzione di prerendering dell'API Speculation Rules, gli sviluppatori web possono inserire istruzioni JSON nelle proprie pagine per informare il browser sugli URL di cui eseguire il prerendering:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
In alternativa, puoi utilizzare le regole del documento (disponibili da Chrome 121), che eseguono il prerendering dei link trovati nel documento in base ai selettori href
(basati sull'API URL Pattern) 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>
Il team di Chrome ha preparato un codelab sulle regole di speculazione che ti guiderà nell'aggiunta di regole di speculazione a un sito.
Impatienza
Supporto dei browser
Viene utilizzata un'impostazione eagerness
per indicare quando devono essere attivate le speculazioni, una funzionalità particolarmente utile per le regole dei documenti:
immediate
: viene utilizzato per fare speculazioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.eager
: si comporta in modo identico all'impostazioneimmediate
, ma in futuro prevediamo di posizionarla traimmediate
emoderate
.moderate
: esegue delle supposizioni se tieni premuto il cursore su un link per 200 millisecondi (o sull'eventopointerdown
se si verifica prima e sui dispositivi mobili dove non è presente l'eventohover
).conservative
: indica un evento del cursore o del tocco.
Il valore eagerness
predefinito per le regole list
è immediate
. Le opzioni moderate
e conservative
possono essere utilizzate per limitare le regole list
agli URL con cui un utente interagisce a un elenco specifico. Tuttavia, in molti casi, le regole document
con una condizione where
appropriata potrebbero essere più appropriate.
Il valore predefinito di eagerness
per le regole document
è conservative
. Dato che un documento può contenere molti URL, devi utilizzare con cautela i valori immediate
o eager
per le regole document
(vedi anche la sezione Limiti di Chrome di seguito).
L'impostazione di eagerness
da usare dipende dal tuo sito. Per un sito statico e leggero, fare più offerte potrebbe avere un costo ridotto ed essere vantaggioso per gli utenti. I siti con architetture più complesse e payload di pagine più pesanti potrebbero preferire la riduzione degli sprechi attraverso una speculazione meno frequente fino a quando non ottieni un segnale più positivo di intenzione da parte degli utenti per limitare gli sprechi.
L'opzione moderate
è una via di mezzo e molti siti potrebbero trarre vantaggio dalla seguente regola di speculazione che eseguirà il prerendering di un link quando il cursore viene tenuto sopra il link per 200 millisecondi o sull'evento pointerdown come implementazione di base, ma efficace, 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 prerendering completo. Spesso può essere un buon primo passo verso il prerendering:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Limiti di Chrome
In Chrome sono in vigore dei limiti per impedire l'uso eccessivo dell'API Speculation Rules:
impazienza | Precaricamento | Prerender |
---|---|---|
immediate /eager |
50 | 10 |
moderate /conservative |
2 (FIFO) | 2 (FIFO) |
Le impostazioni moderate
e conservative
, che dipendono dall'interazione dell'utente, funzionano in ordine di arrivo (FIFO): dopo aver raggiunto il limite, una nuova speculazione comporterà 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 il mouse sopra il link di nuovo, il che comporterà la nuova speculazione sull'URL e l'eliminazione della speculazione più vecchia. In questo caso, la speculazione precedente avrà memorizzato nella cache tutte le risorse memorizzabili nella cache HTTP per quell'URL, quindi eseguire un'altra speculazione dovrebbe avere un costo ridotto. Per questo motivo, il limite è impostato sulla soglia modesta di 2. Le regole degli elenchi statici non vengono attivate da un'azione dell'utente e hanno un limite più elevato perché non è possibile per il browser sapere quali sono necessarie e quando.
Anche i limiti di immediate
e eager
sono dinamici, pertanto la rimozione di un elemento di script URL list
creerà capacità annullando le speculazioni rimosse.
Chrome inoltre impedirà l'utilizzo di speculazioni in determinate condizioni, tra cui:
- Risparmio dati.
- Risparmio energetico se attivato e con batteria in esaurimento.
- Vincoli di memoria.
- Quando l'impostazione "Precarica pagine" è disattivata (viene disattivata anche esplicitamente dalle estensioni di Chrome come uBlock Origin).
- Pagine aperte nelle schede in background.
Inoltre, Chrome non esegue il rendering di iframe cross-origin nelle pagine pre-renderizzate fino all'attivazione.
Tutte queste condizioni mirano a ridurre l'impatto dell'eccessiva speculazione nei casi in cui sarebbe dannoso per gli utenti.
Come includere regole di speculazione in una pagina
Le regole di speculazione possono essere incluse in modo statico nel codice HTML della pagina o inserite dinamicamente nella pagina tramite JavaScript:
- Regole di speculazione incluse in modo statico: ad esempio, un sito di notizie o un blog potrebbe eseguire il prerendering dell'articolo più recente, se spesso è la pagina di navigazione successiva per una grande percentuale di utenti. In alternativa, le regole del documento con
moderate
oconservative
possono essere utilizzate per fare supposizioni quando gli utenti interagiscono con i link. - Regole di speculazione inserite dinamicamente: potrebbero basarsi sulla logica dell'applicazione, personalizzate per l'utente o su altre euristiche.
A chi preferisce l'inserimento dinamico in base ad azioni come il passaggio del mouse sopra un link o il clic su un link, come molte librerie hanno fatto 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 nel tag <head>
o <body>
nel frame principale. Le regole di speculazione nei frame secondari non vengono applicate e le regole di speculazione nelle pagine pre-renderizzate vengono applicate solo dopo l'attivazione della pagina.
L'intestazione HTTP Speculation-Rules
Le regole di speculazione possono essere pubblicate anche utilizzando un'intestazione HTTP Speculation-Rules
, anziché includerle direttamente nel codice HTML del documento. Ciò consente un deployment più semplice da parte delle CDN senza dover 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 cross-origin, deve superare un controllo CORS.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
Se vuoi utilizzare gli 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.
Regole di speculazione e APS
Le regole di speculazione sono supportate solo per le navigazioni a pagine intere gestite dal browser e non per le pagine di app a pagina singola (APS) o shell dell'app. Queste architetture non utilizzano i recuperi dei 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 prerecuperati dall'app al di fuori delle regole di speculazione, ma non possono essere pre-renderizzati.
Le regole di speculazione possono essere utilizzate per eseguire il prerendering dell'applicazione stessa da una pagina precedente. Ciò consente di compensare alcuni dei costi di caricamento iniziale aggiuntivi di alcune APS. Tuttavia, non è possibile eseguire il prerendering delle modifiche al percorso all'interno dell'app.
Regole di speculazione di debug
Consulta il post dedicato sul debug delle regole di speculazione per conoscere le nuove funzionalità di Chrome DevTools che forniscono assistenza nella visualizzazione e nel debug di questa nuova API.
Più regole di speculazione
Alla stessa pagina possono essere aggiunte anche più regole di speculazione, che verranno aggiunte alle regole esistenti. Pertanto, i seguenti diversi modi generano 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>
Assistenza No-Vary-Search
Durante 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 ed essere utilizzati solo dal codice JavaScript lato client.
Ad esempio, i parametri UTM vengono utilizzati da Google Analytics per la misurazione delle campagne, ma in genere non generano pagine diverse dal server. Ciò significa che page1.html?utm_content=123
e page1.html?utm_content=456
pubblicheranno la stessa pagina dal server, quindi la stessa pagina potrà essere riutilizzata dalla cache.
Analogamente, le applicazioni possono utilizzare altri parametri URL gestiti solo lato client.
La proposta No-Vary-Search consente a un server di specificare parametri che non comportano differenze nella risorsa pubblicata e, di conseguenza, consente a un browser di riutilizzare le versioni memorizzate nella cache in precedenza di un documento che differiscono solo per questi parametri. Questa funzionalità è supportata in Chrome (e nei browser basati su Chromium) per le supposizioni di navigazione di precaricamento (anche se stiamo cercando di supportarla anche per il prerendering).
Le regole di speculazione supportano l'utilizzo di expects_no_vary_search
per indicare dove è previsto che venga restituita un'intestazione HTTP No-Vary-Search
. In questo modo eviterai ulteriormente di download non necessari.
<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, il codice HTML della pagina iniziale /products
è lo stesso per entrambi gli ID prodotto 123
e 124
. Tuttavia, i contenuti della pagina alla fine differiscono in base al rendering lato client che utilizza JavaScript per recuperare i dati di prodotto utilizzando il parametro di ricerca id
. Pertanto, precarichiamo l'URL in modo esplicito e dovrebbe restituire 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 ha quindi la possibilità di recuperare di nuovo il link o di attendere il completamento del pre-caricamento 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 expects_no_vary_search
e di attendere il completamento del prefetch.
Restrizioni delle regole di speculazione e miglioramenti futuri
Le regole di scommessa sono limitate alle pagine aperte nella stessa scheda, ma stiamo lavorando per ridurre questa limitazione.
Per impostazione predefinita, le speculazioni sono limitate alle pagine della stessa origine. Pagina di speculazione cross-origin nello 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 di speculazione (https://b.example.com
in questo esempio) deve essere attivata includendo un'intestazione HTTP Supports-Loading-Mode: credentialed-prerender
, altrimenti Chrome annullerà la speculazione.
Le versioni future potrebbero anche consentire il prerendering per pagine cross-origin non dello stesso sito, a condizione che non esistano cookie per la pagina prerenderizzata e che la pagina prerenderizzata venga attivata con un'intestazione HTTP Supports-Loading-Mode: uncredentialed-prerender
simile.
Le regole di speculazione supportano già i precaricamenti cross-origin, ma sempre solo quando non esistono cookie per il dominio cross-origin. Se esistono cookie dell'utente che ha visitato il sito in precedenza, la speculazione non verrà attivata e verrà visualizzato un errore in DevTools.
Date le attuali limitazioni, un pattern che può migliorare le esperienze degli utenti sia per i link interni che per quelli esterni, se possibile, è prerenderizzare gli URL dello stesso dominio e tentare di precaricare gli URL cross-origin:
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
],
"prefetch": [
{
"where": { "not": { "href_matches": "/*" } },
"eagerness": "moderate"
}
]
}
</script>
La limitazione che impedisce le speculazioni cross-origin per i link cross-origin per impostazione predefinita è necessaria per la sicurezza. Si tratta di un miglioramento rispetto a <link rel="prefetch">
per le destinazioni cross-origin che non inviano cookie, ma tentano comunque il prefetch, il che comporterà un prefetch sprecato che deve essere inviato di nuovo o, peggio ancora, il caricamento errato della pagina.
Le regole di speculazione non sono supportate per il pre-caricamento delle pagine controllate dai service worker. Stiamo lavorando per aggiungere questo supporto. Per gli aggiornamenti, segui questo problema relativo al servizio di assistenza. Il prerendering è supportato per le pagine controllate dai service worker.
Supporto dell'API Detect Speculation Rules
Puoi rilevare il 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.');
}
Aggiungere regole di speculazione in modo dinamico tramite JavaScript
Questo è 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.
Se inserisci un elemento <script type = "speculationrules">
direttamente nel DOM utilizzando innerHTML
, le regole di speculazione non verranno registrate per motivi di sicurezza e devono essere aggiunte 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 e lo script per aggiungerlo dinamicamente al DOM deve essere eseguito dalla console per inserire le regole.
Aggiungere regole di speculazione tramite un gestore di tag
Per aggiungere regole di speculazione utilizzando un tag manager come Google Tag Manager (GTM), è necessario che queste vengano inserite tramite JavaScript, anziché aggiungere l'elemento <script type = "speculationrules">
direttamente tramite GTM per gli stessi motivi sopra indicati:
Tieni presente che questo esempio utilizza var
perché GTM non supporta const
.
Annullare le regole di speculazione
La rimozione delle regole di speculazione comporterà l'annullamento del prerendering, ma quando ciò è avvenuto, le risorse saranno probabilmente già state spese per avviare il prerendering, quindi è consigliabile non eseguire il prerendering se esiste la possibilità di dover annullare il prerendering.
Regole sulla speculazione e norme sulla sicurezza del contenuto
Poiché le regole di speculazione utilizzano un elemento <script>
, anche se contengono solo JSON, devono essere incluse in script-src
Content-Security-Policy se il sito le utilizza, utilizzando un hash o un nonce.
È possibile aggiungere un nuovo inline-speculation-rules
a script-src
per supportare il supporto di elementi <script type="speculationrules">
inseriti da script hash o non ced. Non sono supportate le regole incluse nell'HTML iniziale, pertanto le regole devono essere iniettate da JavaScript per i siti che utilizzano un CSP rigoroso.
Rilevare e disattivare il prerendering
In genere, il prerendering è un'esperienza positiva per gli utenti perché consente di visualizzare rapidamente le pagine, spesso in modo istantaneo. Questo è vantaggioso sia per l'utente sia per il proprietario del sito, poiché le pagine pre-renderizzate consentono un'esperienza utente migliore che altrimenti potrebbe essere difficile da ottenere.
Tuttavia, potrebbero esserci casi in cui non vuoi che venga eseguito il prerendering delle pagine, ad esempio quando le pagine cambiano stato in base alla richiesta iniziale o in base all'esecuzione di JavaScript nella pagina.
Attivare e disattivare il prerendering in Chrome
Il prerendering è attivato solo per gli utenti di Chrome che hanno impostato l'opzione "Precarica pagine" in chrome://settings/performance/
. Inoltre, il prerendering è disattivato anche sui dispositivi con poca memoria 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 pre-renderizzate verranno inviate con l'intestazione HTTP Sec-Purpose
:
Sec-Purpose: prefetch;prerender
Per le pagine prelevate 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 che non ha avuto esito positivo (ossia non compreso tra 200 e 299 dopo i reindirizzamenti), la pagina non verrà sottoposta a prerendering e tutte le pagine di precaricamento verranno ignorate. Tieni inoltre presente che le risposte 204 e 205 non sono valide per il prerendering, ma sono valide per il prefetch.
Se non vuoi che una determinata pagina venga sottoposta a prerendering, la restituzione di un codice di risposta non 2XX (ad esempio 503) è il modo migliore per assicurarti che non accada. Tuttavia, per offrire l'esperienza migliore, è consigliabile consentire invece il prerendering, ma ritardare le azioni che dovrebbero avvenire 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 finché la pagina non viene effettivamente attivata.
Una volta attivato un documento sottoposto a prerendering, anche PerformanceNavigationTiming
verrà impostato su un valore diverso da zero che rappresenta il tempo che intercorre tra l'avvio del prerendering e l'attivazione effettiva del documento.
Puoi avere una funzione per verificare la presenza di pagine prerenderizzate e prerenderizzate come la seguente:
function pagePrerendered() {
return (
document.prerendering ||
self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
);
}
Il modo più semplice per vedere se una pagina è stata sottoposta a prerendering (totalmente 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 la pagina è stata pre-riferita:
Quando la pagina viene attivata dall'utente che la visualizza, l'evento prerenderingchange
viene inviato a document
, che può essere utilizzato per attivare le attività che in precedenza sarebbero state avviate per impostazione predefinita al caricamento della 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 in modo appropriato sulle pagine sottoposte a prerendering.
Impatto sull'analisi
Analytics 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, puoi misurare le metriche sul rendimento delle pagine utilizzando il monitoraggio dei real user (RUM).
Le pagine devono essere sottoposte a prerendering solo quando è molto probabile che vengano caricate dall'utente. Questo è il motivo per cui le opzioni di prerendering della barra degli indirizzi di Chrome vengono eseguite solo quando esiste una probabilità così elevata (superiore all'80% delle volte).
Tuttavia, in particolare quando utilizzi l'API Speculation Rules, le pagine sottoposte a prerendering potrebbero avere un impatto sull'analisi e i proprietari dei siti potrebbero dover aggiungere altro codice per abilitare solo l'analisi per le pagine sottoposte a prerendering al momento dell'attivazione, poiché non tutti i fornitori di analisi possono eseguire questa operazione per impostazione predefinita.
Questo risultato può essere ottenuto utilizzando un Promise
che attende l'evento prerenderingchange
se è in corso il prerendering di un documento o si risolve immediatamente se è così:
// 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 a quando la pagina non viene visualizzata per la prima volta, il che coprirebbe sia il caso di prerendering sia l'apertura delle schede in background (ad esempio, con il clic destro 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 questa opzione possa essere utile per casi d'uso di analisi e simili, in altri casi potresti voler caricare più contenuti per questi casi e, di conseguenza, potresti utilizzare document.prerendering
e prerenderingchange
per scegliere come target specifico le pagine di prerendering.
Non mostrare altri contenuti durante il pre-rendering
Le stesse API discusse in precedenza possono essere utilizzate per trattenere altri contenuti durante la fase di prerendering. Possono essere parti specifiche di JavaScript o interi elementi dello script che preferisci non eseguire durante la fase di prerendering.
Ad esempio, con 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 dati e analisi o per visualizzare i contenuti in base allo stato o ad altre variabili che possono cambiare durante una visita. Ad esempio, i consigli, lo stato di accesso o le icone del carrello degli acquisti potrebbero essere trattenuti per garantire la presentazione delle informazioni più aggiornate.
Sebbene questo problema sia più probabile che si verifichi con l'utilizzo del prerendering, queste condizioni valgono 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, idealmente lo stato dovrebbe essere controllato anche in caso di modifiche generali a visibilitychange
. Ad esempio, quando torni a una pagina che è stata visualizzata in background, tutti i contatori del carrello devono essere aggiornati con il numero più recente di articoli nel carrello. Pertanto, non si tratta di un problema specifico del prerendering, ma il prerendering rende più evidente un problema esistente.
Un modo in cui Chrome riduce parte della necessità di eseguire il wrapping manuale di script o funzioni è che alcune API vengono trattenute come indicato in precedenza e che non viene eseguito il rendering degli iframe di terze parti, quindi solo i contenuti oltre a questo devono essere trattenuti manualmente.
Misurare le prestazioni
Per misurare le metriche sul rendimento, gli analisti devono valutare se è meglio misurarle in base al momento dell'attivazione anziché al tempo di caricamento della pagina registrato dalle API del browser.
Per Core Web Vitals, misurati da Chrome tramite il Report sull'esperienza utente di Chrome, il loro scopo è misurare l'esperienza utente. Pertanto, vengono misurate in base al momento dell'attivazione. Ciò spesso si traduce, ad esempio, in un LCP di 0 secondi, a dimostrazione del fatto che si tratta di un ottimo modo per migliorare i Core Web Vitals.
Dalla versione 3.1.0, la libreria web-vitals
è stata aggiornata per gestire le navigazioni pre-renderizzate nello stesso modo in cui Chrome misura Core Web Vitals. Questa versione segnala anche le navigazioni pre-renderizzate per le metriche nell'attributo Metric.navigationType
se la pagina è stata pre-renderizzata completamente o parzialmente.
Misurare i pre-rendering
È possibile sapere se una pagina è pre-riferita tramite una voce activationStart
diversa da zero di PerformanceNavigationTiming
. Questi dati possono essere registrati utilizzando una dimensione personalizzata o un'altra metrica simile quando vengono registrate le 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, i tuoi dati e analisi potranno mostrare quante navigazioni vengono sottoposte a prerendering rispetto ad altri tipi di navigazione e puoi anche correlare le metriche delle prestazioni o dell'attività a questi diversi tipi di navigazione. Più velocità significa utenti più soddisfatti, il che spesso può avere un impatto reale sulle misurazioni aziendali, come dimostrano i nostri case study.
Mentre misuri l'impatto commerciale del prerendering delle pagine per le navigazioni istantanee, puoi decidere se vale la pena investire di più nell'utilizzo di questa tecnologia per consentire il prerendering di più navigazioni o per scoprire perché le pagine non vengono prerenderizzate.
Misurare le percentuali di hit
Oltre a misurare l'impatto delle pagine visitate dopo un prerendering, è importante anche misurare quelle che sono state sottoposte a prerendering e non vengono visitate successivamente. Ciò potrebbe significare che il prerendering è eccessivo e che stai utilizzando risorse preziose dell'utente per un piccolo vantaggio.
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 il prerendering sia stato avviato o completato, in quanto, come indicato in precedenza, il prerendering è un suggerimento per il browser e quest'ultimo potrebbe scegliere di non eseguire il prerendering delle pagine in base alle impostazioni dell'utente, all'utilizzo corrente della memoria o ad altre strategie di euristica.
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 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 il prerendering, puoi modificare le regole in modo appropriato per mantenere un tasso di hit elevato e mantenere il giusto equilibrio tra l'utilizzo delle risorse degli utenti per aiutarli e l'utilizzo non necessario.
Tieni presente che potrebbe essere in corso un prerendering parziale a causa del prerendering della barra degli indirizzi e non solo delle regole di speculazione. Puoi controllare document.referrer
(che sarà vuoto per la navigazione nella barra degli indirizzi, incluse le navigazioni nella barra degli indirizzi pre-renderizzate) se vuoi distinguerli.
Ricordati di controllare anche le pagine senza prerendering, perché ciò potrebbe indicare che non sono idonee per il prerendering, anche 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 verificare l'idoneità al prerendering, forse simili allo strumento di test bfcache, e potenzialmente anche un'API per indicare il motivo del fallimento di un prerendering.
Impatto sulle estensioni
Leggi il post dedicato su Chrome Extensions: Extending API to support Instant Navigation che descrive in dettaglio alcune considerazioni aggiuntive che gli autori di estensioni potrebbero dover prendere in considerazione per le pagine sottoposte a prerendering.
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. Accogliamo con favore qualsiasi feedback sul repository GitHub o tramite il nostro tracker dei problemi e non vediamo l'ora di ascoltare e condividere casi d'uso di questa nuova entusiasmante API.
Link correlati
- Codelab sulle Regole di speculazione
- Eseguire il debug delle regole di speculazione
- Introduzione al pre-caricamento NoState
- Specifica dell'API Regole di scommessa
- Repository GitHub di speculazione di navigazione
- Estensioni di Chrome: estensione dell'API per supportare la navigazione istantanea
Ringraziamenti
Immagine in miniatura di Marc-Olivier Jodoin su Unsplash