Supporto dei browser
- 109
- 109
- x
- x
Il team di Chrome sta lavorando a opzioni per ripristinare il prerendering completo delle pagine future che è probabile che un utente visiti.
Breve cronologia del prerendering
In passato, Chrome supportava il suggerimento per le 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 precedente con il suggerimento rel=prerender del link è stato ritirato a favore di NoState Prefetch, che invece recuperava le risorse necessarie per la pagina futura, ma non esegue il prerendering completo della pagina né esegue JavaScript. NoState Prefetch aiuta a migliorare le prestazioni della pagina migliorando il caricamento delle risorse, ma non restituisce un caricamento della pagina istantaneo come un prerendering completo.
Il team di Chrome ha ora reintrodotto il prerendering completo in Chrome. Per evitare complicazioni nell'utilizzo esistente e per consentire un'espansione futura del prerendering, questo nuovo meccanismo di prerendering non utilizzerà la sintassi <link rel="prerender"...>, che rimane attiva per NoState Prefetch, con l'obiettivo di ritirarla in futuro.
In che modo viene eseguito il prerendering di una pagina?
Una pagina può essere sottoposta a prerendering in uno dei seguenti quattro modi, ognuno dei quali ha lo scopo di velocizzare la navigazione:
- Quando digiti un URL nella barra degli indirizzi di Chrome (nota anche come "omnibox"), Chrome potrebbe eseguire automaticamente il prerendering della pagina per te, se è sicuro che la visiterai.
- Quando digiti un termine nella barra degli indirizzi di Chrome, Chrome potrebbe eseguire automaticamente il prerendering della pagina dei risultati di ricerca su richiesta del motore di ricerca.
- I siti possono utilizzare l'API Speculation Rules per indicare in modo programmatico a Chrome quali pagine eseguire il prerendering. Questa funzionalità sostituisce le attività di
<link rel="prerender"...>e consente ai siti di eseguire il prerendering proattivo di una pagina in base a regole di speculazione. Possono essere presenti in modo statico nelle pagine o inseriti dinamicamente da JavaScript secondo le necessità del proprietario della pagina.
In ognuno di questi casi, un prerendering si comporta come se la pagina fosse stata aperta in una scheda in background invisibile e poi "attivato" sostituendo la scheda in primo piano con quella pagina sottoposta a prerendering. Se una pagina viene attivata prima di aver eseguito il prerendering completo, il suo stato attuale è "in primo piano" e continua a caricarsi, il che significa che puoi comunque iniziare bene.
Poiché la pagina sottoposta a prerendering viene aperta in uno stato nascosto, una serie di API che causano comportamenti invasivi (ad esempio le richieste) non vengono attivate in questo stato, ma vengono ritardate fino all'attivazione della pagina. Nei pochi casi in cui non è ancora possibile, il prerendering viene annullato. Il team di Chrome sta lavorando all'esposizione dei motivi di annullamento del prerendering come API, nonché al miglioramento delle 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:
Il sito di esempio è già veloce, ma anche con questo puoi vedere come il prerendering migliora l'esperienza utente. Ciò può quindi avere un impatto diretto anche sui Segnali web essenziali di un sito, con un valore LCP quasi pari a zero, riduzione della CLS (dal momento che qualsiasi CLS del carico avviene prima della visualizzazione iniziale) e miglioramento dell'INP (dal momento che il caricamento deve essere completato prima dell'interazione dell'utente).
Anche quando una pagina si attiva prima di essere completamente caricata, avere un avvio iniziale nel caricamento pagina dovrebbe migliorare l'esperienza di caricamento. Quando viene attivato un link mentre il prerendering è ancora in corso, la pagina di prerendering verrà spostata nel frame principale e continuerà a caricarsi.
Tuttavia, il prerendering utilizza memoria e larghezza di banda di rete aggiuntivi. Fai attenzione a non eseguire il prerendering eccessivo, a scapito delle risorse utente. Esegui il prerendering solo quando c'è un'alta probabilità di accedere alla pagina.
Consulta la sezione Misurazione del rendimento per ulteriori informazioni su come misurare l'impatto effettivo sul rendimento nelle analisi.
Visualizzare le previsioni nella 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 un grado di confidenza sufficiente per attivare il prerendering. In questo esempio, se digiti "s" ottieni un livello di confidenza ragionevole (ambra), ma quando digiti "sh" Chrome ha abbastanza sicurezza che il livello di sicurezza verrà quasi sempre indirizzato a https://sheets.google.com.
Questo screenshot è stato acquisito in un'installazione di Chrome relativamente recente e ha filtrato le previsioni a confidenza zero, ma se visualizzi i tuoi previsioni, probabilmente vedrai molte più voci e potenzialmente più caratteri necessari per raggiungere un livello di confidenza sufficientemente elevato.
Questi predittori sono anche ciò che determina le opzioni suggerite nella barra degli indirizzi che potresti aver notato:
Chrome aggiornerà continuamente i propri predittori in base alla tua digitazione e alle tue selezioni.
- Per un livello di confidenza superiore al 50% (indicato in ambra), Chrome si precollega in modo proattivo al dominio, ma non esegue il prerendering della pagina.
- Per un livello di confidenza superiore all'80% (indicato in verde), Chrome eseguirà il prerendering dell'URL.
L'API Speculation Rules
Per la terza opzione di prerendering, gli sviluppatori web possono inserire istruzioni JSON nelle loro pagine per comunicare al browser quali URL eseguire il prerendering:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
In alternativa, in base alle regole del documento (disponibili da Chrome 121), che eseguono il prerendering dei link trovati nel documento in base ai selettori href o CSS:
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"selector_matches": ".do-not-prerender"}},
{ "not": {"selector_matches": "[rel=nofollow]"}}
]
}
}]
}
</script>
entusiasmo
Supporto dei browser
- 121
- 121
- x
- x
Un'impostazione eagerness viene utilizzata per indicare quando attivare le speculazioni, una funzionalità particolarmente utile per le regole relative ai documenti:
immediate: questo parametro viene utilizzato per fare supposizioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.eager: questo comportamento è identico all'impostazioneimmediate, ma in futuro intendiamo collocarlo traimmediateemoderate.moderate:vengono eseguite speculazioni se passi il mouse sopra un link per 200 millisecondi (o sull'eventopointerdown, se questo è dovuto prima e sui dispositivi mobili dove non è presente alcun eventohover).conservative: esegue una speculazione sul puntatore o sul touchdown.
Il valore predefinito di eagerness 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 con un elenco specifico. Anche se 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ò essere composto da molti URL, l'utilizzo delle regole immediate o eager per document deve essere utilizzato con cautela (consulta anche la sezione Limiti di Chrome di seguito).
L'impostazione di eagerness da utilizzare dipende dal tuo sito. Per un sito leggero e statico, fare supposizioni con più entusiasmo può avere pochi costi ed essere vantaggioso per gli utenti. I siti con architetture più complesse e un payload più pesante per le pagine potrebbero preferire ridurre gli sprechi speculando meno spesso fino a quando non si ottiene un segnale di intenzione più positivo 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 eseguirebbe il prerendering di tutti i link al passaggio del mouse o al puntatore come un'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 soltanto le pagine, senza un prerendering completo. Spesso questa procedura può essere un buon primo passo verso il prerendering:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Limiti di Chrome
Chrome prevede dei limiti per impedire l'uso eccessivo dell'API Speculation Rules:
| entusiasmo | Precaricamento | Prerendering |
|---|---|---|
immediate/eager |
50 | 10 |
moderate/conservative |
2 (FIFO) | 2 (FIFO) |
Le impostazioni moderate e conservative, che dipendono dall'interazione dell'utente, funzionano secondo il modo FIFO (First In, First Out): una volta raggiunto il limite, una nuova speculazione farà sì che la speculazione meno recente venga annullata e sostituita da quella più recente per risparmiare memoria. Una speculazione annullata può essere attivata di nuovo, ad esempio passando di nuovo il mouse sopra il link. In questo modo, l'URL viene speculato, eliminando la speculazione meno recente. In questo caso, la speculazione precedente avrà memorizzato nella cache tutte le risorse memorizzabili nella cache nella cache HTTP per quell'URL, quindi ipotizzare un periodo di tempo aggiuntivo dovrebbe avere un costo ridotto. Ecco perché il limite viene impostato sulla soglia modesta di 2. Le regole dell'elenco statico non vengono attivate da un'azione dell'utente, pertanto hanno un limite più alto, in quanto il browser non può sapere quali sono e quando sono necessarie.
Anche i limiti immediate e eager sono dinamici, quindi la rimozione di un elemento script URL list creerà capacità annullando le speculazioni rimosse.
Inoltre, Chrome impedirà l'utilizzo di speculazioni in determinate condizioni, tra cui:
- Save-Data (Salva dati).
- Risparmio energetico quando questa funzionalità è attiva e con batteria in esaurimento.
- Vincoli di memoria.
- Quando l'impostazione "Precarica le pagine" è disattivata (disattivata anche esplicitamente da estensioni di Chrome, come uBlock Origin).
- Pagine aperte in schede in background.
Inoltre, Chrome non esegue il rendering degli iframe multiorigine sulle pagine sottoposte a prerendering fino all'attivazione.
L'obiettivo di tutte queste condizioni è ridurre l'impatto di una speculazione eccessiva che potrebbe essere dannosa 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 staticamente: ad esempio un sito di notizie o un blog può eseguire il prerendering dell'articolo più recente, se questa è spesso la navigazione successiva per una grande percentuale di utenti. In alternativa, le regole per i documenti con
moderateoconservativepossono essere utilizzate per speculare quando gli utenti interagiscono con i link. - Regole di speculazione inserite dinamicamente: potrebbero basarsi sulla logica dell'applicazione, personalizzate in base all'utente o ad altre euristiche.
Consigliamo a chi preferisce l'inserimento dinamico in base ad azioni quali il passaggio del mouse o il clic verso il basso su un link, come facevano in passato molte librerie con <link rel=prefetch>, di esaminare le regole dei documenti, poiché queste consentono al browser di gestire molti dei casi d'uso.
Le regole di speculazione possono essere aggiunte in <head> o in <body> nel frame principale. Non viene eseguita alcuna azione sulle regole di speculazione nei frame secondari e le regole di speculazione nelle pagine sottoposte a prerendering vengono eseguite solo dopo che la pagina è stata attivata.
L'intestazione HTTP Speculation-Rules
Le regole di speculazione possono essere caricate anche utilizzando un'intestazione HTTP Speculation-Rules, invece di includerle direttamente nel codice HTML del documento. Ciò consente un deployment più semplice da parte delle reti CDN senza dover modificare i contenuti dei documenti.
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 collegamenti della stessa origine.
Regole di speculazione e APS
Le regole di speculazione sono supportate solo per le navigazioni nelle pagine complete gestite dal browser e non per le app a pagina singola (APS) o le pagine shell dell'app. Queste architettura non utilizzano i recuperi dei documenti, ma eseguono recuperi parziali di dati o pagine da parte dell'API o di 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 sottoposti a prerendering.
Puoi usare regole di speculazione per eseguire il prerendering dell'applicazione stessa da una pagina precedente. Ciò può aiutarti a compensare alcuni dei costi di caricamento iniziali aggiuntivi sostenuti da alcune APS. Tuttavia, le modifiche al percorso all'interno dell'app non possono essere sottoposte a prerendering.
Debug delle regole di speculazione
Consulta il post dedicato sul debug delle regole di speculazione per scoprire le nuove funzionalità di Chrome DevTools che ti aiuteranno a visualizzare e eseguire il debug di questa nuova API.
Regole di speculazione multipla
Puoi anche aggiungere più regole di speculazione alla stessa pagina, che vengono aggiunte alle regole esistenti. Di conseguenza, tutti questi modi diversi comportano il prerendering sia di one.html sia di two.html:
Elenco di URL:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html", "two.html"]
}
]
}
</script>
Più speculationrules:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
}
]
}
</script>
<script type="speculationrules">
{
"prerender": [
{
"urls": ["two.html"]
}
]
}
</script>
Più elenchi in 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 di solito non generano pagine diverse pubblicate dal server. Ciò significa che page1.html?utm_content=123 e page1.html?utm_content=456 pubblicheranno la stessa pagina dal server, pertanto la stessa pagina può essere riutilizzata dalla cache.
Analogamente, le applicazioni possono utilizzare altri parametri URL gestiti solo sul lato client.
La proposta No-Vary-Search consente a un server di specificare parametri che non risultano in una differenza rispetto alla risorsa pubblicata, consentendo al browser di riutilizzare 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) solo per le speculazioni di navigazione con precaricamento.
Le regole di speculazione supportano l'uso di expects_no_vary_search per indicare dove è previsto che venga restituita un'intestazione HTTP No-Vary-Search. In questo modo è possibile evitare ulteriori download inutili.
<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 di /products è lo stesso per gli ID prodotto 123 e 124. Tuttavia, alla fine i contenuti della pagina differiscono in base al rendering lato client se viene utilizzato JavaScript per recuperare i dati di prodotto usando il parametro di ricerca id. Di conseguenza, precaricamo con entusiasmo l'URL e dovrebbe restituire un'intestazione HTTP No-Vary-Search che mostra 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 può quindi scegliere se recuperare di nuovo il link o attendere il completamento del precaricamento per vedere 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.
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 queste restrizioni. Per impostazione predefinita, il prerendering è limitato alle pagine della stessa origine.
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à, l'attivazione della pagina sottoposta a prerendering (https://b.example.com in questo esempio) deve includere un'intestazione HTTP Supports-Loading-Mode: credentialed-prerender. In caso contrario, Chrome annullerà il prerendering.
Le versioni future potrebbero anche consentire il prerendering per le pagine multiorigine (in cui il sito viene attivato con un'intestazione HTTP Supports-Loading-Mode: uncredentialed-prerender simile) e attivare il prerendering nelle nuove schede.
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.');
}
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 JavaScript, in questa pagina demo di prerendering.
Annulla regole di speculazione
La rimozione di regole di speculazione comporterà l'annullamento del prerendering, ma, quando ciò è avvenuto, è probabile che le risorse siano già state esaurite per avviare il prerendering, pertanto è consigliabile non eseguire il prerendering se esiste la probabilità che sia necessario annullarlo.
Regole di speculazione e Criterio di sicurezza del contenuto
Poiché le regole di speculazione utilizzano un elemento <script>, anche se contengono solo JSON, devono essere incluse nei Content-Security-Policy di script-src se il sito lo utilizza usando 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 hash o non gestiti. Non supporta le regole incluse nell'HTML iniziale, di conseguenza le regole devono essere inserite da 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 delle pagine veloce, spesso istantaneo. Questo è vantaggioso sia per l'utente sia per il proprietario del sito, poiché le pagine sottoposte a prerendering consentono una migliore esperienza utente che altrimenti sarebbe difficile ottenere.
Tuttavia, in alcuni casi non vuoi che venga eseguito il prerendering delle pagine, ad esempio quando lo stato delle pagine cambia, in base alla richiesta iniziale o in base all'esecuzione di JavaScript sulla pagina.
Attivare e disattivare il prerendering in Chrome
Il prerendering viene attivato solo per gli utenti di Chrome con l'impostazione "Precarica le pagine" in chrome://settings/performance/. Inoltre, il prerendering viene disattivato anche sui dispositivi con memoria ridotta o se il sistema operativo è in modalità Salva dati o Risparmio energetico. Consulta la sezione Limiti di Chrome.
Rileva e disattiva il prerendering lato server
Le pagine sottoposte a prerendering verranno inviate con l'intestazione HTTP Sec-Purpose:
Sec-Purpose: prefetch;prerender
Per le pagine precaricate che utilizzano l'API Speculation Rules, l'intestazione sarà impostata su prefetch:
Sec-Purpose: prefetch
I server possono rispondere in base a questa intestazione, per registrare richieste di speculazione, restituire contenuti diversi o impedire un prerendering. Se viene restituito un codice di risposta di non riuscita (ovvero non 200 o 304), la pagina non verrà sottoposta a prerendering e qualsiasi pagina di precaricamento verrà eliminata.
Se non vuoi che una determinata pagina venga sottoposta a prerendering, questo è il modo migliore per assicurarti che ciò non avvenga. Tuttavia, per offrire un'esperienza ottimale, è consigliabile consentire 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. Questa funzionalità può essere utilizzata dalle pagine per evitare, o ritardare, determinate attività durante il prerendering fino all'attivazione effettiva della pagina.
Una volta attivato un documento sottoposto a prerendering, anche il valore activationStart di PerformanceNavigationTiming verrà impostato su un tempo diverso da zero che rappresenta il tempo tra l'inizio del prerendering e l'effettiva attivazione del documento.
Puoi avere una funzione per verificare le pagine di prerendering e prerendering 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, sai che la pagina è stata sottoposta a prerendering:
Quando la pagina viene attivata dall'utente che la visualizza, l'evento prerenderingchange viene inviato sulla pagina document, che può essere quindi utilizzata per abilitare le attività che in precedenza sarebbero state avviate per impostazione predefinita al caricamento della pagina, ma che vuoi ritardare finché la pagina non viene effettivamente visualizzata dall'utente.
Utilizzando queste API, il codice JavaScript frontend può rilevare le pagine sottoposte a prerendering e intervenire in modo appropriato.
Impatto sull'analisi
Analytics viene utilizzato 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 degli utenti reali (RUM).
Le pagine devono essere sottoposte a prerendering solo quando è molto probabile che la pagina venga caricata dall'utente. Questo è il motivo per cui le opzioni di prerendering della barra degli indirizzi di Chrome vengono visualizzate solo quando c'è una probabilità così alta (superiore all'80% delle volte).
Tuttavia, in particolare quando si utilizza l'API Speculation Rules, le pagine sottoposte a prerendering potrebbero influire sull'analisi e i proprietari dei siti potrebbero dover aggiungere codice aggiuntivo per abilitare l'analisi solo per le pagine sottoposte a prerendering al momento dell'attivazione, poiché non tutti i fornitori di analisi potrebbero farlo per impostazione predefinita.
Puoi ottenere questo risultato utilizzando un elemento Promise che attende l'evento prerenderingchange se è in corso il prerendering di un documento o si risolve immediatamente se lo è:
// 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à fino a quando la pagina non viene resa visibile per la prima volta, il che include sia le maiuscole che le richieste di prerendering e anche quando le schede vengono aperte in background (ad esempio, facendo clic con il tasto destro del mouse e aprendo in una nuova scheda):
// Set up a promise for when the page is first made visible
const whenActivated = new Promise((resolve) => {
if (document.hidden) {
document.addEventListener('visibilitychange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
Anche se questo può avere senso per dati e analisi e casi d'uso simili, in altri casi potresti voler caricare più contenuti in questi casi, quindi utilizzare document.prerendering e prerenderingchange per scegliere come target specificamente pagine di prerendering.
Misurare il rendimento
Per misurare le metriche sul rendimento, Analytics dovrebbe valutare se è meglio misurarle in base al tempo di attivazione anziché al tempo di caricamento della pagina segnalato dalle API del browser.
Per i Segnali web essenziali, misurati da Chrome tramite il Report sull'esperienza utente di Chrome, hanno lo scopo di misurare l'esperienza utente. che vengono quindi misurate in base al tempo di attivazione. Ad esempio, questo si traduce in un LCP di 0 secondi. Questo è un ottimo modo per migliorare i tuoi Segnali web essenziali.
A partire dalla versione 3.1.0, la libreria web-vitals è stata aggiornata per gestire le navigazioni con prerendering allo stesso modo in cui Chrome misura i Segnali web essenziali. Questa versione segnala anche le navigazioni con prerendering per queste metriche nell'attributo Metric.navigationType se la pagina è stata sottoposta a prerendering completamente o parzialmente.
Misurare il prerendering
Indica se una pagina è sottoposta a prerendering può essere visualizzata con una voce activationStart diversa da zero di PerformanceNavigationTiming. Questo può essere registrato utilizzando una dimensione personalizzata o simile quando registri 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, le tue analisi potranno mostrare quante navigazioni vengono sottoposte a prerendering rispetto ad altri tipi di navigazione e potrai correlare eventuali metriche sul rendimento o sull'attività con questi diversi tipi di navigazione. Pagine più veloci significano utenti più soddisfatti, il che spesso può avere un impatto reale sulle misure aziendali, come mostrano i nostri case study.
Quando 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 capire perché le pagine non vengono sottoposte a prerendering.
Misurare le percentuali di successo
Oltre a misurare l'impatto delle pagine visitate dopo un prerendering, è importante anche misurare le pagine che vengono sottoposte a prerendering e non visitate successivamente. Ciò potrebbe significare che stai eseguendo troppo il prerendering e che stai utilizzando risorse preziose dell'utente per pochi vantaggi.
Questo può essere misurato attivando un evento di analisi quando vengono inserite regole di speculazione, dopo aver verificato che il browser supporti il prerendering tramite HTMLScriptElement.supports('speculationrules'), per indicare che è stato richiesto il prerendering. Tieni presente che solo perché è stato richiesto un prerendering, non indica che un prerendering è stato avviato o completato poiché, come indicato in precedenza, un prerendering è un suggerimento per il browser e potrebbe scegliere di non eseguire il prerendering delle pagine in base alle impostazioni utente, all'utilizzo corrente della memoria o ad altre euristiche.)
Puoi quindi confrontare il numero di questi eventi con le effettive visualizzazioni di pagina di prerendering. In alternativa, attiva un altro evento al momento dell'attivazione, se questo semplifica il confronto.
La "percentuale di hit andati a buon fine" può quindi essere approssimata osservando la differenza tra queste due cifre. Per le pagine in cui utilizzi l'API Speculation Rules per il prerendering delle pagine, puoi modificare le regole in modo appropriato per mantenere un alto tasso di successo e mantenere l'equilibrio tra l'utilizzo eccessivo delle risorse per gli utenti e l'uso superfluo.
Tieni presente che potrebbe verificarsi qualche prerendering a causa del prerendering della barra degli indirizzi e non solo delle tue regole di speculazione. Puoi selezionare document.referrer (che sarà vuoto per la navigazione nella barra degli indirizzi, incluse le navigazioni nella barra degli indirizzi sottoposti a prerendering) se vuoi distinguerli.
Ricordati di controllare anche le pagine che non hanno prerendering, poiché ciò potrebbe indicare che queste pagine non sono idonee per il prerendering, anche dalla barra degli indirizzi. Ciò potrebbe significare che non stai beneficiando di questo miglioramento delle prestazioni. Il team di Chrome sta cercando di aggiungere ulteriori strumenti per testare l'idoneità di prerendering, forse simili allo strumento di test bfcache, nonché aggiungere potenzialmente un'API per scoprire il motivo per cui un prerendering non è riuscito.
Impatto sulle estensioni
Leggi il post dedicato Chrome Extensions: estensione dell'API per supportare la navigazione istantanea che descrive in dettaglio alcune considerazioni aggiuntive a cui gli autori delle estensioni potrebbero dover tenere conto per le pagine sottoposte a prerendering.
Feedback
Il prerendering è in fase di sviluppo attivo da parte del team di Chrome e sono in programma molti per estendere l'ambito di ciò che è stato reso disponibile con la release 108 di Chrome. Siamo lieti di ricevere feedback sul repository GitHub o sull'utilizzo del nostro strumento di monitoraggio dei problemi. Non vediamo l'ora di ascoltare e condividere i case study di questa nuova ed entusiasmante API.
Link correlati
- Debug delle regole di speculazione
- Introduzione a NoState Prefetch
- API Speculation Rules
- Il repository GitHub di speculazione relativa alla navigazione
- Estensioni di Chrome: estensione dell'API per supportare la navigazione istantanea
Ringraziamenti
Immagine in miniatura di Marc-Olivier Jodoin su Unsplash