Miglioramenti all'API Speculation Rules

Barry Pollard

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

Queste modifiche rendono il precaricamento e il prerendering delle pagine notevolmente più facili da implementare e meno sprechi, cosa che speriamo incoraggerà un'ulteriore adozione.

Altre funzionalità

La prima è una spiegazione delle nuove aggiunte che abbiamo aggiunto all'API Speculation Rules e del relativo utilizzo. A questo punto, ti mostreremo una demo per permetterti di vedere come funziona.

Regole per i documenti

In precedenza, l'API Speculation Rules veniva specificata specificando un elenco di URL da precaricare o eseguire il prerendering:

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

Le regole di speculazione erano semi-dinamiche perché era possibile aggiungere nuovi script di regole di speculazione e rimuovere i vecchi script per eliminare quelle speculazioni (tieni presente che l'aggiornamento dell'elenco urls di uno script di regole di speculazione esistente non attiva una modifica delle 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 elenco rimangono un'opzione per i casi d'uso più semplici (dove la navigazione successiva avviene da un piccolo insieme di quelli ovvi) o per i casi d'uso più avanzati (in cui l'elenco di URL viene calcolato dinamicamente in base a qualsiasi euristica che il proprietario del sito voglia utilizzare e poi inserito nella pagina).

In alternativa, siamo lieti di offrire una nuova opzione per la ricerca automatica dei link utilizzando le regole per i documenti. Funziona mediante l'acquisizione degli URL dal documento stesso in base a una condizione where. Questa metrica può essere basata 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 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'unica serie di regole di speculazione in tutto il sito, anziché avere specifiche regole per pagina, semplificando così l'implementazione da parte dei siti di queste regole.

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

Interesse

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

D'altra parte, il prerendering solo dopo che un utente ha fatto clic su un link evita sprechi, ma a costo di un tempo di risposta notevolmente ridotto. Questo significa che è improbabile che il prerendering sia stato completato prima che il browser passi alla pagina in questione.

L'impostazione eagerness consente di definire quando eseguire le speculazioni, separando quando eseguire la speculazione da quali URL eseguire. L'impostazione eagerness è disponibile per le regole di origine list e document e include quattro impostazioni, per le quali Chrome ha la seguente euristica:

• immediate:viene utilizzato per eseguire speculazioni il prima possibile, ovvero non appena vengono osservate le regole di speculazione.
• eager: al momento il comportamento dell'impostazione è identico a quello dell'impostazione immediate, ma in futuro cercheremo di inserirlo tra immediate e moderate.
• moderate:esegue delle speculazioni se passi il mouse sopra un link per 200 millisecondi (o sull'evento pointerdown, se è precedente, e su dispositivi mobili in cui non è presente alcun evento hover).
• conservative: si verifica il puntatore o il tocco verso il basso.

Il valore predefinito di eagerness per le regole list è immediate. Le opzioni moderate e conservative possono essere utilizzate per limitare le regole di 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. Nel caso di un sito statico molto semplice, fare delle specchiazioni con più accese può avere un costo minimo 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 positivo di intenzione da parte degli utenti al fine di limitare gli sprechi.

L'opzione moderate è una via di mezzo e molti siti potrebbero trarre vantaggio dalla seguente semplice regola di speculazione, che eseguirebbe il prerendering di tutti i link al passaggio del mouse o al puntatore del mouse come implementazione di base di regole di speculazione:

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

Limiti di Chrome

Anche con la scelta eagerness, Chrome ha dei limiti per evitare 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 più modesta, pari a 2, per risparmiare memoria. Le impostazioni immediate e eager non vengono attivate da un'azione dell'utente e, di conseguenza, prevedono un limite più elevato, in quanto il browser non può capire quali sono e quando sono necessarie.

Una speculazione annullata dall'uscita dalla coda FIFO può essere attivata di nuovo, ad esempio passando di nuovo il mouse sopra il link, con una nuova speculazione dell'URL. In questo caso, la speculazione precedente probabilmente ha indotto il browser a memorizzare nella cache alcune risorse nella cache HTTP per quell'URL, quindi la ripetizione della speculazione dovrebbe avere una rete molto ridotta e quindi costi in termini di tempo.

Anche i limiti immediate e eager sono dinamici. La rimozione di 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 URL e se il limite non è stato raggiunto.

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

• Salva-Dati.
• Risparmio energetico.
• Vincoli di memoria.
• Quando l'opzione "Precarica le pagine" viene disattivata (e viene disattivata esplicitamente anche dalle estensioni di Chrome come uBlock Origin).
• Pagine aperte nelle schede in background.

Tutte queste condizioni mirano a ridurre l'impatto della sovraspeculazione nei casi in cui sarebbe dannoso 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 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 reti CDN senza la necessità di modificare i contenuti dei documenti.

L'intestazione HTTP Speculation-Rules viene restituita con il documento e punta 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, deve 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 tue 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.

Migliore riutilizzo della cache

Abbiamo apportato una serie di miglioramenti alla memorizzazione nella cache in Chrome, in modo che il precaricamento (o persino il prerendering) di un documento archivi e riutilizzi le risorse nella cache HTTP. Ciò significa che la speculazione può comunque avere vantaggi futuri, anche se non viene utilizzata.

In questo modo, la rispeculazione (ad esempio, per le regole per i documenti con un'impostazione di eagerness moderate) risulta notevolmente più economica, in quanto Chrome utilizzerà la cache HTTP per le risorse memorizzabili nella cache.

Sosteniamo inoltre 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 da JavaScript lato client.

Ad esempio, i parametri UTM vengono utilizzati da Google Analytics per la misurazione delle campagne, ma in genere non comportano la pubblicazione 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 può essere riutilizzata dalla cache.

Analogamente, le applicazioni possono utilizzare altri parametri URL gestiti solo sul lato client.

La proposta Ricerca senza Varia consente a un server di specificare parametri che non comportano alcuna differenza rispetto alla risorsa fornita e, pertanto, consente a un browser di riutilizzare le versioni memorizzate in precedenza di un documento che differiscono solo per questi parametri. Nota: al momento questa opzione è supportata solo in Chrome (e nei browser basati su Chromium) per le speculazioni di navigazione di precaricamento.

Le regole di speculazione supportano l'utilizzo di expects_no_vary_search per indicare dove si prevede 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 è uguale per gli ID prodotto 123 e 124. Tuttavia, i contenuti della pagina differiscono in base al rendering lato client utilizzando JavaScript per recuperare i dati di prodotto utilizzando il parametro di ricerca id. L'URL viene quindi precaricato con entusiasmo 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, è possibile che il browser non abbia 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 scegliere se recuperare di nuovo il link o attendere il completamento del precaricamento 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 No-Vary-Search e di attendere il completamento del precaricamento.

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 per il desiderio di moderate in azione:

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

Passando il mouse sopra i frutti, vedrai le pagine sottoposte a prerendering. Se fai clic sui pulsanti, visualizzerai un tempo LCP molto più rapido rispetto a quello di una delle ricette, che non è stata sottoposta a prerendering. Questa demo è spiegata anche nel seguente video:

Puoi anche consultare il precedente post del blog 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ò rendere tutto questo un affare che richiede un solo clic. Collaboriamo con vari partner e piattaforme per semplificare l'implementazione delle regole di speculazione.

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

WordPress

Il team WordPress Core Performance (inclusi gli sviluppatori di Google) ha creato un plug-in delle regole di speculazione. Questo plug-in consente di aggiungere facilmente 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 dovrebbe anche valutare di installare, in quanto vi terrà aggiornati sui plug-in correlati alle prestazioni forniti dal team.

Sono disponibili due gruppi di impostazioni: Modalità speculazione e 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 sta sperimentando attivamente l'API Speculation Rules da qualche tempo. Akamai ha pubblicato la documentazione su come i clienti possono abilitare questa API nelle proprie impostazioni CDN. Inoltre, in precedenza ha condiviso gli incredibili risultati possibili con questa nuova API.

NitroPack

NitroPack è una soluzione di ottimizzazione delle prestazioni che utilizza l'AI di navigazione personalizzata per prevedere quali pagine aggiungere alle regole di speculazione, con l'obiettivo di fornire un tempo di risposta più lungo rispetto al passaggio del mouse sopra un link, ma senza lo spreco di speculazioni inutilmente su tutti i link osservati. Per ulteriori informazioni, consulta la documentazione relativa all'API Nitropack Speculation Rules. Questa soluzione innovativa dimostra che le vecchie regole per gli elenchi non hanno ancora moltissimo da offrire se abbinate ad approfondimenti specifici 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, inclusa un'ottima discussione sulle considerazioni necessarie tra speculazioni iniziali e frequenti, nonché in ritardo e meno frequenti.

Astrofotografia

Astro ha aggiunto il prerendering delle pagine utilizzando l'API Speculation Rules nella versione 4.2 su base sperimentale, consentendo agli sviluppatori che utilizzano Astro di attivare 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 del client.

Conclusione

Queste aggiunte all'API Speculation Rules consentono un uso molto più semplice di questa nuova entusiasmante funzionalità per le prestazioni per i siti, con meno rischi di sprecare risorse con speculazioni inutilizzate. È entusiasmante vedere che le piattaforme si affidano già a questa API. Ci auguriamo di estendere l'adozione di questa API nel 2024 e di migliorare il rendimento per gli utenti finali.

Oltre ai miglioramenti di rendimento offerti dall'API Speculation Rules, non vediamo l'ora di scoprire le nuove opportunità che si apre. Visualizza transizioni è 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 la versione con più pagine è in corso (e disponibile dietro un flag in Chrome). Il prerendering è un componente aggiuntivo naturale a questa funzionalità per garantire che non ci siano ritardi, che altrimenti impedirebbero il miglioramento dell'esperienza utente che la transizione è destinata a fornire. Abbiamo già rilevato siti che stanno sperimentando questa combinazione.

Non vediamo l'ora di adottare ulteriormente 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