Miglioramenti all'API Speculation Rules

Barry Pollard

Il team di Chrome sta lavorando ad alcuni interessanti aggiornamenti dell'API Speculation Rules utilizzata per migliorare le prestazioni di navigazione tramite il precaricamento o addirittura il prerendering delle navigazioni future. Questi miglioramenti aggiuntivi sono ora disponibili in Chrome 122 (alcune funzionalità sono disponibili nelle versioni precedenti).

Queste modifiche semplificano notevolmente il deployment del pre-caricamento e del pre-rendering delle pagine e riducono gli sprechi, il che ci auguriamo incoraggi l'adozione di questa funzionalità.

Altre funzionalità

Innanzitutto, una spiegazione delle nuove aggiunte all'API Speculation Rules e su come utilizzarle. Dopodiché, ti mostreremo una demo per farti vedere come funzionano.

Regole per i documenti

In precedenza, l'API Speculation Rules funzionava specificando un elenco di URL da prelevare o pre-renderizzare:

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

Le regole di speculazione erano semidinamiche in quanto era possibile aggiungere nuovi script di regole di speculazione e rimuovere quelli vecchi per ignorare le speculazioni (tieni presente che l'aggiornamento dell'elenco urls di uno script di regole di speculazione esistente non attiva una modifica delle speculazioni). Tuttavia, la scelta degli URL era ancora lasciata al sito, inviandoli dal server al momento della richiesta della pagina o creando dinamicamente questo elenco tramite JavaScript lato client.

Le regole elenco rimangono un'opzione per casi d'uso più semplici (in cui la navigazione successiva proviene da un piccolo insieme di navigazione evidenti) o più avanzati (in cui l'elenco di URL viene calcolato dinamicamente in base a qualsiasi euristica il proprietario del sito vuole utilizzare e poi inserito nella pagina).

In alternativa, siamo lieti di offrire una nuova opzione per la ricerca automatica dei link utilizzando le regole dei documenti. Questo funziona estraendo gli URL dal documento stesso in base a una condizione where. Questo può essere basato sui link stessi:

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

Nota: una versione precedente delle regole dei documenti, disponibile durante la prova dell'origine, aveva un href_matches più complesso che richiedeva una sintassi aggiuntiva per abbinare i parametri e i frammenti dell'URL ({"href_matches": "/*\\?*#*"}). Questa operazione è stata semplificata nella versione di rilascio.

I selettori CSS possono essere utilizzati anche come alternativa o in combinazione con le corrispondenze href per trovare i link nella pagina corrente:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

In questo modo è possibile utilizzare un unico insieme di regole di speculazione per l'intero sito, anziché avere regole specifiche per pagina, semplificando notevolmente il deployment delle regole di speculazione per i siti.

Ovviamente, il prerendering di tutti i link di una pagina sarebbe decisamente uno spreco, quindi con questa nuova funzionalità abbiamo introdotto un'impostazione eagerness.

Impatienza

Con qualsiasi tipo di previsione, esiste un compromesso tra precisione e richiamo e tempo di risposta. Se esegui il prerendering di tutti i link al caricamento della pagina, prerenderizzerai quasi sicuramente un link su cui fa clic un utente (supponendo che faccia clic su un link all'interno dello stesso sito nella pagina) e con il tempo di risposta più lungo possibile, ma con un potenziale spreco enorme di larghezza di banda.

D'altra parte, il prerendering solo dopo che un utente ha fatto clic su un link evita gli sprechi, ma a costo di un tempo di risposta molto ridotto. Ciò significa che è improbabile che il prerendering sia stato completato prima che il browser passi a quella pagina.

L'impostazione eagerness consente di definire quando devono essere eseguite le speculazioni, separando quando eseguire le speculazioni dagli URL su cui eseguirle. L'impostazione eagerness è disponibile sia per le regole di origine list che document e ha quattro impostazioni, per le quali Chrome ha le seguenti strategie di euristica:

• immediate: viene utilizzato per fare speculazioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.
• eager: al momento si comporta in modo identico all'impostazione immediate, ma in futuro prevediamo di posizionarlo tra immediate e moderate.
• moderate: esegue delle speculazioni se passi il mouse sopra un link per 200 millisecondi (o sull'evento pointerdown se si verifica prima e sui dispositivi mobili dove non è presente l'evento hover).
• conservative: si tratta di un'ipotesi sul cursore o sul 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 eagerness predefinito per le regole document è conservative. Poiché un documento può essere composto da molti URL, l'utilizzo di immediate o eager per le regole document deve essere usato con cautela (vedi anche la sezione Limiti di Chrome di seguito).

L'impostazione eagerness da utilizzare dipende dal tuo sito. Per un sito statico molto semplice, fare speculazioni più attivamente potrebbe avere un costo ridotto ed essere vantaggioso per gli utenti. I siti con architetture più complesse e payload delle pagine più pesanti potrebbero preferire ridurre gli sprechi effettuando meno speculazioni finché non ricevi un segnale più positivo di intenti da parte degli utenti per limitare gli sprechi.

Attenzione: la sovrastima ha un costo chiaro per gli utenti in termini di larghezza di banda, memoria e CPU, ma anche per i siti stessi. Tieni presente l'impatto che stai causando sugli utenti quando implementi le speculazioni. Le impostazioni eagerness ti consentono di ridurre la probabilità di speculazioni sprecate. Chrome impone inoltre limiti alle speculazioni per ridurre l'impatto dell'uso eccessivo.

L'opzione moderate è una via di mezzo e molti siti potrebbero trarre vantaggio dalla seguente semplice regola di speculazione che prerenderizza tutti i link al passaggio del mouse o al clic del mouse come implementazione di base, ma efficace, delle regole di speculazione:

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

Limiti di Chrome

Anche con la scelta di eagerness, Chrome ha limiti per evitare un uso eccessivo di questa API:

eagerness	Precaricamento	Prerender
immediate/eager	50	10
moderate/conservative	2 (FIFO)	2 (FIFO)

Limiti di speculazione in Chrome

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

Il fatto che le speculazioni moderate e conservative vengano attivate dagli utenti ci consente di utilizzare una soglia più modesta di 2 per risparmiare memoria. Le impostazioni immediate e eager 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.

Una speculazione annullata perché espulsa dalla coda FIFO può essere attivata di nuovo, ad esempio passando il mouse sopra il link di nuovo, il che comporterà una nuova speculazione sull'URL. In questo caso, la speculazione precedente avrà probabilmente causato la memorizzazione nella cache di alcune risorse nella cache HTTP per quell'URL, quindi la ripetizione della speculazione dovrebbe avere costi di rete e tempo molto ridotti.

Anche i limiti immediate e eager sono dinamici. La rimozione di un elemento dello script delle regole di speculazione che utilizza questi livelli di anticipazione creerà capacità annullando le speculazioni rimosse. Questi URL possono anche essere specificati di nuovo se sono inclusi in un nuovo script URL e il limite non è stato raggiunto.

Chrome impedirrà inoltre l'utilizzo di speculazioni in determinate condizioni, tra cui:

• Risparmio dati.
• Risparmio energetico.
• Vincoli di memoria.
• Quando l'impostazione "Precarica pagine" è disattivata (che viene disattivata anche esplicitamente dalle estensioni di Chrome come uBlock Origin).
• Pagine aperte nelle schede in background.

Tutte queste condizioni hanno lo scopo di ridurre l'impatto della sovraspeculazione quando sarebbe dannosa per gli utenti.

source

In Chrome 122, il tasto source è facoltativo, poiché può essere dedotto dalla presenza dei tasti url o where. Queste due regole di speculazione sono quindi identiche:

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

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

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"

Avviso: poiché si tratta di un'intestazione strutturata, le virgolette sono importanti e devono essere incluse nel valore dell'intestazione.

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. Questa opzione può essere particolarmente utile se devi selezionare alcuni o tutti i link della stessa origine.

Riutilizzo della cache migliore

Abbiamo apportato una serie di miglioramenti alla memorizzazione nella cache in Chrome in modo che il pre-caricamento (o anche il pre-rendering) di un documento consenta di archiviare e riutilizzare le risorse nella cache HTTP. Ciò significa che la speculazione può comunque avere vantaggi futuri, anche se non viene utilizzata.

Inoltre, la nuova speculazione (ad esempio per le regole dei documenti con un'impostazione di moderate eagerness) è notevolmente più economica, in quanto Chrome utilizzerà la cache HTTP per le risorse cacheabili.

Sosteniamo inoltre la nuova proposta No-Vary-Search per migliorare ulteriormente il riutilizzo della cache.

Assistenza No-Vary-Search

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

Ad esempio, i parametri UTM vengono utilizzati da Google Analytics per la misurazione delle campagne, ma in genere non comportano l'invio di 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 inviata e, di conseguenza, consente a un browser di riutilizzare le versioni memorizzate nella cache di un documento che differiscono solo per questi parametri. Nota: al momento questa funzionalità è supportata solo in Chrome (e nei browser basati su Chromium) per le speculazioni di navigazione di prefetch.

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 puoi evitare ulteriori 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.No-Vary-Search

Demo

Abbiamo creato una demo all'indirizzo https://speculative-rules.glitch.me/common-fruits.html che può essere utilizzata per vedere le regole dei documenti con un'impostazione di anticipazione moderate in azione:

Demo delle regole di speculazione

Apri DevTools, fai clic sul riquadro Applicazione. Nella sezione Servizi in background, fai clic su Carichi speculativi, poi sul riquadro Stime e ordina in base alla colonna Stato.

Quando passi il mouse sopra i frutti, vedrai il pre-rendering delle pagine. Se fai clic su di essi, verrà visualizzato un tempo LCP molto più rapido rispetto a una delle ricette, che non vengono pre-elaborate. Questa demo è spiegata anche nel seguente video:

Puoi anche consultare il post del blog precedente sul debug delle regole di speculazione per ulteriori informazioni su come utilizzare DevTools per eseguire il debug delle regole di speculazione.

Supporto della piattaforma per le regole di speculazione

Sebbene le regole di speculazione siano relativamente semplici da implementare inserendole in un elemento <script type="speculationrules">, il supporto della piattaforma può semplificare il processo con un solo clic. Stiamo collaborando con varie piattaforme e partner per semplificare l'implementazione delle regole sulla speculazione.

Inoltre, ci stiamo adoperando per standardizzare l'API tramite il Web Incubator Community Group (WICG) per consentire ad altri browser di implementare questa interessante API, se lo desiderano.

WordPress

Il team WordPress Core Performance (inclusi gli sviluppatori di Google) ha creato un plug-in Regole di scommessa. Questo plug-in consente di aggiungere facilmente con un solo clic il supporto delle regole dei documenti a qualsiasi sito WordPress. Questo plug-in è disponibile anche per l'installazione tramite il plug-in WordPress Performance Lab, che ti consigliamo di installare anche per rimanere al passo con i plug-in per il rendimento del team.

Sono disponibili due gruppi di impostazioni: la modalità di speculazione e l'impostazione Attività:

Plug-in Regole di speculazione di WordPress

Per configurazioni più complesse, ad esempio per escludere determinati URL dal prelievo o dal prerendering, leggi la documentazione.

Akamai

Akamai è uno dei principali provider di reti CDN al mondo e da tempo sperimenta attivamente l'API Speculation Rules. Akamai ha rilasciato la documentazione su come i clienti possono attivare questa API nelle impostazioni della CDN. In precedenza, ha anche condiviso gli impressionanti risultati possibili con questa nuova API.

NitroPack

NitroPack è una soluzione di ottimizzazione del rendimento che utilizza l'IA di navigazione personalizzata per prevedere quali pagine aggiungere alle regole di speculazione, il cui obiettivo è fornire un tempo di risposta più lungo rispetto al passaggio del mouse sopra un link, ma senza lo spreco di speculare inutilmente su tutti i link osservati. Per saperne di più, consulta la documentazione dell'API Nitropack Speculation Rules. Questa soluzione innovativa dimostra che le regole degli elenchi precedenti hanno ancora molto da offrire se abbinate a approfondimenti specifici per sito.

Il team di Chrome ha collaborato con NitroPack anche a un webinar per l'API Speculation Rules per chi cerca maggiori informazioni, inclusa una buona discussione sulle considerazioni necessarie tra la speculazione anticipata e frequente, nonché tardiva e meno frequente.

Astrofotografia

In Astro 4.2 è stato aggiunto il prerendering delle pagine utilizzando l'API Speculation Rules su base sperimentale, consentendo agli sviluppatori che utilizzano Astro di attivare facilmente questa funzionalità, riducendo al contempo a un prefetch standard per i browser che non supportano l'API Speculation Rules. Per saperne di più, leggi la documentazione sul prerendering del client.

Conclusione

Queste aggiunte all'API Speculation Rules consentono un utilizzo molto più semplice di questa nuova ed entusiasmante funzionalità di rendimento per i siti, con meno rischio di sprecare risorse con speculazioni inutilizzate. È entusiasmante vedere che le piattaforme si stanno già orientando verso questa API. Ci auguriamo di assistere a un'adozione più ampia di questa API nel 2024 e, di conseguenza, a un miglioramento del rendimento per gli utenti finali.

Oltre ai miglioramenti delle prestazioni offerti dall'API Speculation Rules, siamo entusiasti di scoprire quali nuove opportunità si aprono. View Transitions è una nuova API che consente agli sviluppatori di specificare più facilmente le transizioni tra le navigazioni. Questa funzionalità è attualmente disponibile per le applicazioni a pagina singola (SPA), ma la versione multipagina è in fase di sviluppo (e disponibile dietro un flag in Chrome). Il prerendering è un componente aggiuntivo naturale di questa funzionalità per garantire che non ci siano ritardi, che altrimenti impedirebbero il miglioramento dell'esperienza utente che la transizione intende offrire. Abbiamo già notato siti che stanno sperimentando questa combinazione.

Prevediamo di estendere l'adozione dell'API Speculation Rules nel corso del 2024 e ti aggiorneremo su eventuali ulteriori miglioramenti apportati all'API.

Ringraziamenti

Miniatura di Robbie Down su Unsplash