Miglioramenti all'API Speculation Rules

Barry Pollard

Il team di Chrome sta lavorando ad alcuni aggiornamenti interessanti all'API Speculation Rules, che verranno utilizzati per migliorare le prestazioni di navigazione mediante il precaricamento o addirittura il prerendering delle navigazioni future. Questi miglioramenti aggiuntivi sono ora tutti disponibili a partire da Chrome 122 (con alcune funzionalità disponibili nelle versioni precedenti).

Queste modifiche rendono notevolmente più semplice l'implementazione del precaricamento e il prerendering delle pagine e riducono lo spreco di risorse, il che ci auguriamo ne incoraggerà un'ulteriore adozione.

Altre funzionalità

La prima è una spiegazione delle nuove aggiunte che abbiamo aggiunto all'API Speculation Rules e di come utilizzarle. Al termine, mostreremo una demo per vederle in azione.

Regole per i documenti

In precedenza, l'API Speculation Rules consentiva di specificare un elenco di URL da precaricare o da prerenderizzare:

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

Le regole di speculazione erano semidinamiche, in quanto potevano essere aggiunti nuovi script per le regole di speculazione e rimossi quelli precedenti per eliminare queste speculazioni (tieni presente che l'aggiornamento dell'elenco urls di uno script delle regole di speculazione esistente non attiva una modifica nelle speculazioni). Tuttavia, lasciava comunque la scelta degli URL al sito, inviandoli dal server al momento della richiesta della pagina o creando dinamicamente questo elenco tramite JavaScript lato client.

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

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

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

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

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

Ciò consente di utilizzare un'unica serie di regole di speculazione in tutto il sito, anziché averne di specifiche per pagina, rendendo molto più facile per i siti l'implementazione di regole di speculazione.

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

entusiasmo

Con qualsiasi tipo di speculazione, esiste un compromesso tra precisione e richiamo e tempo di risposta. Il prerendering di tutti i link al caricamento della pagina comporta quasi sicuramente il prerendering di un link su cui un utente fa clic (supponendo che faccia clic su un link dello stesso sito nella pagina) e con il maggior tempo di risposta possibile, ma con uno spreco potenzialmente enorme di larghezza di banda.

D'altra parte, il prerendering solo dopo che un utente ha fatto clic su un link consente di evitare sprechi, ma il costo di un lead time 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 eseguire le speculazioni, separando quando per speculare su quali URL eseguire le speculazioni. L'impostazione eagerness è disponibile per le regole del codice sorgente list e document e ha quattro impostazioni, per le quali Chrome ha le seguenti euristiche:

• immediate: questo parametro viene utilizzato per fare supposizioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.
• eager: al momento questa impostazione è identica all'impostazione immediate, ma in futuro abbiamo intenzione di collocarla tra immediate e moderate.
• moderate:vengono eseguite speculazioni se passi il mouse sopra un link per 200 millisecondi (o sull'evento pointerdown, se questo è dovuto prima e sui dispositivi mobili dove non è presente alcun evento hover).
• 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 statico molto semplice, fare supposizioni con più entusiasmo potrebbe 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 semplice, 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": [{
    "source": "document",
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Limiti di Chrome

Anche se è stata scelta l'API eagerness, Chrome prevede dei limiti per impedire l'uso eccessivo di questa API:

Le impostazioni moderate e conservative, che dipendono dall'interazione dell'utente, funzionano in 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.

Il fatto che le speculazioni moderate e conservative vengano attivate dagli utenti ci consente di utilizzare una soglia di 2 più modesta per risparmiare memoria. Le impostazioni immediate e eager non vengono attivate da un'azione dell'utente, pertanto hanno un limite più elevato, in quanto il browser non può sapere quali e quando sono necessari.

Una speculazione che viene annullata tramite push dalla coda FIFO può essere attivata di nuovo, ad esempio passando di nuovo il mouse sopra il link, e di conseguenza l'URL verrà ricalcolato. In tal caso, la speculazione precedente potrebbe aver causato la memorizzazione nel browser di alcune risorse nella cache HTTP per quell'URL, quindi la ripetizione della speculazione dovrebbe avere una rete molto ridotta e quindi in termini di tempo.

Anche i limiti immediate e eager sono dinamici. Rimuovere un elemento di script delle regole di speculazione utilizzando questi livelli di entusiasmo creerà capacità annullando le speculazioni rimosse. Questi URL possono anche essere rispeculati se sono inclusi in un nuovo script dell'URL e il limite non è stato raggiunto.

Inoltre, Chrome impedirà l'utilizzo di speculazioni in determinate condizioni, tra cui:

• Save-Data (Salva dati).
• Risparmio energetico.
• 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.

L'obiettivo di tutte queste condizioni è ridurre l'impatto di una speculazione eccessiva che potrebbe essere dannosa per gli utenti.

source (facoltativo)

Chrome 122 rende facoltativa la chiave source poiché può essere dedotta dalla presenza delle chiavi 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 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.

Migliore riutilizzo della cache

Abbiamo apportato una serie di miglioramenti alla memorizzazione nella cache in Chrome in modo che il precaricamento (o anche il prerendering) di un documento possa archiviare e riutilizzare le risorse nella cache HTTP. Ciò significa che le speculazioni possono comunque avere vantaggi futuri, anche se questa speculazione non viene utilizzata.

Inoltre, le nuove speculazioni (ad esempio, per le regole relative ai documenti con un'impostazione di interesse moderate) risultano notevolmente più economiche, poiché Chrome utilizzerà la cache HTTP per le risorse memorizzabili nella cache.

Supportiamo anche la nuova proposta No-Vary-Search per migliorare ulteriormente il riutilizzo della cache.

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 generano differenze rispetto alle risorse pubblicate e consente a un browser di riutilizzare versioni precedentemente 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 speculazioni di navigazione precaricate.

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.

Demo

All'indirizzo https://speculative-rules.glitch.me/common-fruits.html abbiamo creato una demo che può essere usata per visualizzare le regole del documento con un'impostazione di interesse moderate in azione:

Apri DevTools e fai clic sul riquadro Applicazione. Quindi, nella sezione Servizi in background, fai clic su Caricamenti speculativi, poi sul riquadro Speculazioni e ordina i dati in base alla colonna Stato.

Mentre passi il mouse sopra i frutti, vedrai il prerendering delle pagine. Se fai clic sulle ricette, il tempo LCP verrà mostrato molto più rapidamente rispetto a una delle ricette, che non sono state sottoposte a prerendering. Questa demo è spiegata anche nel seguente video:

Puoi anche consultare il precedente post del blog sulle regole di speculazione sul debug per saperne di più 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ò rendere tutto questo un compito con un solo clic. Abbiamo collaborato con vari partner e piattaforme per semplificare l'implementazione delle regole di speculazione.

Stiamo inoltre lavorando duramente per standardizzare l'API tramite il Web Incubator Community Group (WICG) per consentire anche ad altri browser di implementare questa interessante API, se lo desiderano.

WordPress

Il team di WordPress Core Performance (inclusi gli sviluppatori di Google) ha creato un plug-in delle regole di speculazione. Questo plug-in consente di aggiungere con un solo clic il supporto delle regole dei documenti a qualsiasi sito WordPress. Questo plug-in può essere installato anche tramite il plug-in WordPress Performance Lab, che ti consigliamo di installare anche perché ti terrà aggiornato sui plug-in per le prestazioni correlati da parte del team.

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

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

Akamai

Akamai è uno dei principali provider CDN al mondo e da tempo sta sperimentando attivamente l'API Speculation Rules. Akamai ha pubblicato la documentazione relativa alle modalità con cui i clienti possono abilitare questa API nelle impostazioni CDN. Inoltre, in precedenza hanno condiviso gli straordinari risultati possibili con questa nuova API.

NitroPack

NitroPack è una soluzione di ottimizzazione delle prestazioni che utilizza Navigation AI personalizzata per prevedere quali pagine aggiungere alle regole di speculazione. Questa soluzione mira a fornire un tempo di risposta più lungo rispetto al passaggio del mouse sopra un link, ma senza sprecare inutilmente speculazioni su tutti i link osservati. Per ulteriori informazioni, consulta la documentazione relativa all'API Nitropack Speculation Rules. Questa soluzione innovativa dimostra che le regole per gli elenchi meno recenti hanno ancora molto da offrire se abbinate a informazioni specifiche per il sito.

Il team di Chrome ha inoltre collaborato con NitroPack a un webinar per l'API Speculation Rules, per chi cerca maggiori informazioni, tra cui una discussione approfondita sulle considerazioni necessarie per fare supposizioni in anticipo e con frequenza, oltre che in ritardo e con minore frequenza.

Astro

Astro ha aggiunto il prerendering delle pagine utilizzando l'API Speculation Rules nella versione 4.2 in modo sperimentale, consentendo agli sviluppatori che usano Astro di abilitare questa funzionalità con facilità, utilizzando al contempo un precaricamento standard per i browser che non supportano l'API Speculation Rules. Per ulteriori informazioni, leggi la documentazione relativa al prerendering dei client.

Conclusione

Queste aggiunte all'API Speculation Rules consentono di semplificare l'uso di questa nuova ed entusiasmante funzionalità per le prestazioni dei siti, con un minore rischio di sprecare risorse con speculazioni inutilizzate. È entusiasmante vedere le piattaforme che si affidano già a questa API. Ci auguriamo di vedere un'adozione più ampia di questa API nel 2024 e, in definitiva, di migliorare le prestazioni per gli utenti finali.

Oltre ai miglioramenti in termini di prestazioni offerti dall'API Speculation Rules, non vediamo l'ora di scoprire nuove opportunità. View Transiziones è una nuova API che consente agli sviluppatori di specificare più facilmente le transizioni tra le navigazioni. Questa opzione è attualmente disponibile per le applicazioni a pagina singola (APS), ma è in corso la versione con più pagine (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 fornire. Abbiamo già rilevato siti che stanno sperimentando questa combinazione.

Ci auguriamo di continuare ad adottare l'API Speculation Rules nel corso del 2024 e ti aggiorneremo su eventuali ulteriori miglioramenti che apporteremo all'API.

Ringraziamenti

Miniatura di Robbie Down su Unsplash