Massimizzazione dell'indice di riscontri cache

Uno dei modi più efficaci per migliorare le prestazioni dello storefront è quello di massimizzare l'indice di riscontri cache. Qualsiasi richiesta che può essere soddisfatta dalla cache CDN di Managed Runtime viene conteggiata come un riscontro cache. Con ogni riscontro cache, i tempi di caricamento pagina per l'utente si riducono, in quanto si evitano i tempi di rendering della pagina sul lato server e l'esecuzione di richieste ai sistemi di back-end e alle API.

In questa guida vengono illustrate tre tecniche per massimizzare i riscontri cache: impostazione della durata ottimale della cache, rendering condizionale e filtro delle stringhe di query. Di seguito viene descritta dettagliatamente ogni tecnica.

La quantità di tempo ottimale di memorizzazione in cache di una richiesta HTTP dipende dal tipo di richiesta. Una richiesta di caricamento di una pagina di contenuto soggetta a rare modifiche può rimanere memorizzata in cache per un lungo periodo di tempo. Al contrario, una pagina di elenco prodotti soggetta a frequenti aggiornamenti con nuovi prodotti potrebbe richiedere una durata cache più breve, ad esempio quindici minuti. Se possibile, scegliere periodi di durata cache lunghi per massimizzare l'indice di riscontri cache.

Un'intestazione cache-control nella risposta HTTP determina il periodo di tempo durante il quale una risposta a una richiesta di pagina viene memorizzata nella cache CDN. La durata cache per le risposte di pagina in un progetto PWA Kit è di 600 secondi (o 10 minuti). La durata cache può essere personalizzata per singola pagina o per tutte le pagine.

La funzione getProps di qualsiasi componente di pagina consente di personalizzare la risposta HTTP utilizzando un oggetto trasferito nel res richiamato. Per impostare la durata cache per una pagina, utilizzare il metodo set dell'oggetto res per definire un'intestazione Cache-Control e specificare un valore in secondi per la direttiva max-age.

Ad esempio, il seguente componente ProductList estende la durata cache dal valore predefinito di 600 secondi a 900 secondi:

La durata cache può essere impostata per tutte le pagine in app/ssr.js. È possibile modificare la durata cache predefinita impostando un nuovo valore per defaultCacheTimeSeconds. Per un controllo più preciso sull'intestazione HTTP, aggiungere un gestore Express che imposti un'intestazione personalizzata, ad esempio:

È possibile verificare che i controlli di cache siano presenti nelle intestazioni di risposta esaminando le richieste di rete nella scheda Rete di Chrome DevTools. In alternativa, eseguire il seguente comando curl nel terminale, che restituisce tutte le intestazioni di risposta. Sostituire <URL> nel comando di esempio con l'URL completo da testare, incluse tutte le stringhe di query obbligatorie.

Per verificare che una pagina sia idonea per il caching da parte della rete CDN, è necessario aggiungere codice condizionale per evitare il rendering dei seguenti tipi di contenuto sul lato server:

• Contenuti personalizzati, ad esempio nome di un utente, numero di articoli nel carrello e metodo di pagamento preferito. I contenuti personalizzati sono appropriati e pertinenti solo per un singolo utente. Il caching delle risposte per un singolo utente non aumenta i riscontri cache.
• Contenuto soggetto a frequenti modifiche, come il prezzo di un prodotto, l'inventario rimanente o le promozioni di vendita. Questo tipo di contenuto non è idoneo al caching perché potrebbe confondere l'utente se la pagina contiene informazioni già obsolete.

Si pensi alla pagina renderizzata sul lato server come a una base generica che il client può personalizzare. Dopo il rapido caricamento della versione di lato server della pagina sul dispositivo dell'utente, il browser subentra renderizzando il contenuto personalizzato e soggetto a frequenti modifiche.

Per determinare se il rendering avviene sul lato client o sul lato server, verificare la presenza dell'oggetto window (presente solo sul lato client). Nel seguente esempio viene utilizzata questa tecnica per renderizzare un prezzo solo sul lato client:

La maggior parte delle app di storefront utilizza la stringa di query di un URL per memorizzare parametri e valori che rappresentano aspetti dello stato dell'app. Ad esempio, se un utente cerca "pullover", è possibile includere il termine di ricerca nella stringa di query come ?search=sweaters. Le stringhe di query sono comunemente utilizzate anche per monitorare le azioni utente. Ad esempio, è possibile aggiungere una stringa di query univoca a ogni link all'interno di un'email per monitorare le relative interazioni: user=juanita&source=email.

Per quanto riguarda il caching, non tutti i parametri di stringa di query sono pertinenti. Managed Runtime include una funzione edge denominata request processor (elaboratore richieste), che consente di modificare la stringa di query di una richiesta prima che cerchi le risposte memorizzate in cache. È possibile aumentare i riscontri cache utilizzando il request processor per associare URL simili alla stessa risposta memorizzata in cache.

Per personalizzare il request processor, modificare la funzione processRequest definita in app/request-processor.js.

Nel seguente esempio viene definito un request processor che filtra i parametri gclid e utm_campaign escludendoli dalla stringa di query. Questi parametri sono comunemente associati alle campagne di marketing di Google e sono utili solo sul lato client. Per semplificare le operazioni con le stringhe di query, viene importata la classe QueryParameters da PWA Kit React SDK.

L'URL completo utilizzato per cercare l'oggetto corrispondente nella cache include la versione della stringa di query restituita dal request processor. Se nessuna risposta viene memorizzata in cache per tale URL, questa versione modificata dell'URL viene trasferita all'app Express.

Quando si utilizza questo approccio, prestare attenzione a due aspetti:

Innanzitutto verificare che l'app non basi il rendering su parametri filtrati. Ad esempio, se si filtrasse il parametro search indicato sopra, sarebbe difficile visualizzare i risultati di ricerca corretti.

In secondo luogo, prestare attenzione quando si filtrano i parametri dalle richieste che si prevede di reindirizzare. Se il codice non è in grado di accedere a un parametro filtrato, questo non potrà essere utilizzato nemmeno per il reindirizzamento. Considerare una richiesta come un componente di pagina principale che reindirizza una richiesta di www.example.com?lang=en a un percorso specifico per impostazione locale, come www.example.com/en. Se si esclude il parametro lang, non è possibile effettuare il reindirizzamento all'impostazione locale corretta.

Si consideri la seguente sequenza:

1. Il request processor gestisce una richiesta di www.example.com/?gclid=123.
2. Il request processor filtra il parametro di stringa di query gclid.
3. La richiesta viene inoltrata all'applicazione con l'URL completo www.example.com.
4. L'applicazione restituisce un reindirizzamento a www.example.com/en.

Si noti che in questo ultimo passaggio il parametro gclid originale è andato perduto e, pertanto, non sarà disponibile per il browser dopo il reindirizzamento dell'utente. Per risolvere il problema, evitare di filtrare le stringhe di query delle richieste che si prevede di reindirizzare.

In questa guida sono state illustrate varie tecniche per migliorare i riscontri cache per le richieste di pagina.

Consultare la guida Invio delle richieste a un proxy per informazioni sul caching delle richieste API e altri vantaggi dei proxy.