Maximiser votre taux d\u2019accès au cache

L'un des meilleurs moyens d'améliorer les performances de votre boutique en ligne consiste à maximiser le taux d'accès au cache. Toute request qui peut être satisfaite à partir du cache CDN de Managed Runtime est considérée comme un accès au cache. Avec chaque accès au cache, vous accélérez le chargement de la page pour l'utilisateur, car vous économisez le coût du rendu de la page côté serveur et les requests aux systèmes backend et aux API.

Ce guide couvre trois techniques permettant de maximiser le nombre d'accès au cache : la définition de durées de vie optimales du cache, le rendu conditionnel et le filtrage des chaînes de requête. Examinons chaque technique en détail.

La durée optimale de mise en cache d'une request HTTP dépend de ce qui est demandé. Une request de chargement d'une page de contenu qui change rarement peut être mise en cache en toute sécurité pendant une longue période. En revanche, pour une page de liste de produits fréquemment mise à jour avec de nouveaux produits, il peut être indiqué de réduire la durée de vie de la mémoire cache, par exemple à quinze minutes. Dans la mesure du possible, préférez de longues durées de vie du cache afin de maximiser le taux de réussite du cache.

Un en-tête cache-control dans la réponse HTTP détermine la durée pendant laquelle une réponse à une request de page est stockée dans le cache du CDN. La durée de vie du cache pour les réponses aux pages dans un projet PWA Kit est de 600 secondes (soit 10 minutes) par défaut. Vous pouvez personnaliser la durée de vie du cache pour chaque page ou pour toutes les pages.

La fonction getProps de tout composant de page permet de personnaliser la réponse HTTP à l'aide d'un objet appelé res passé dans la fonction. Pour définir la durée de vie en cache d'une page, utilisez la méthode set de l'objet res pour définir un en-tête Cache-Control et spécifier une valeur en secondes pour la directive max-age.

Par exemple, ce composant ProductList étend la durée de vie du cache de 600 secondes par défaut à 900 secondes :

Vous pouvez définir la durée de vie en cache de toutes les pages dans app/ssr.js. Vous pouvez modifier la durée de vie en cache par défaut en définissant une nouvelle valeur pour defaultCacheTimeSeconds. Si vous avez besoin d'un contrôle plus fin sur l'en-tête HTTP, ajoutez un gestionnaire Express qui définit un en-tête personnalisé, comme ceci :

Vous pouvez tester que vos contrôles de cache sont présents dans les en-têtes de réponse en inspectant vos requests réseau à l'aide des DevTools de Chrome dans l'onglet Réseau. Vous pouvez également exécuter la commande curl suivante dans votre terminal, pour afficher tous les en-têtes de réponse. Remplacez <URL> dans l'exemple de commande par l'URL complète que vous souhaitez tester, y compris les chaînes de requête requises.

Pour s'assurer qu'une page est adaptée à la mise en cache par le CDN, vous devez ajouter un code conditionnel pour éviter de rendre les types de contenu suivants côté serveur :

• Le contenu personnalisé, comme le nom d'un utilisateur, le nombre d'articles dans le panier et le mode de paiement préféré. Le contenu personnalisé est inapproprié et non pertinent s'il ne s'agit pas d'un seul utilisateur. La mise en cache des réponses pour un seul utilisateur n'augmente pas votre nombre d'accès au cache.
• Le contenu souvent modifié, comme le prix d'un produit, les stocks restants ou les promotions commerciales. Ce contenu n'est pas adapté à la mise en cache car cette dernière pourrait entraîner un risque de confusion pour l'utilisateur si la page contient des informations déjà périmées.

Considérez la page rendue côté serveur comme une base générique sur laquelle le client peut s'appuyer. Après avoir rapidement chargé la version de la page côté serveur sur l'appareil de l'utilisateur, le navigateur prend le relais pour rendre le contenu personnalisé ou fréquemment modifié.

Pour déterminer si le rendu se produit côté client ou côté serveur, vérifiez la présence de l'objet window, qui n'est présent que du côté client. L'exemple suivant utilise cette technique pour rendre un prix uniquement côté client :

La plupart des applications de boutique utilisent la chaîne de requête d'une URL pour stocker des paramètres et des valeurs qui représentent des aspects de l'état de l'application. Par exemple, si un utilisateur recherche des « sweaters », vous pouvez inclure le terme de recherche dans la chaîne de requête comme suit : ?search=sweaters. Les chaînes de requête sont aussi couramment utilisées pour suivre les actions des utilisateurs. Nous pouvons par exemple ajouter une chaîne de requête unique à chaque lien figurant dans un e-mail pour suivre les interactions avec ce dernier : user=juanita&source=email.

Tous les paramètres de chaîne de requête ne sont pas pertinents en matière de mise en cache. Managed Runtime comprend une fonction périphérique appelée request processor (processeur de request) qui permet de modifier la chaîne de requête d’une request avant de rechercher des réponses en cache. Vous pouvez augmenter le nombre d'accès au cache en utilisant le request processor pour mapper des URL similaires à la même réponse en cache.

Pour personnaliser le request processor, modifiez la fonction processRequest définie dans app/request-processor.js.

L'exemple suivant définit un request processor qui filtre et supprime les paramètres gclid et utm_campaign de la chaîne de requête. Ces paramètres sont généralement associés aux campagnes de marketing Google et ne sont utiles que côté client. Pour simplifier le travail avec les chaînes de requête, le request processor importe la classe QueryParameters du SDK React de PWA Kit.

L'URL complète qui est utilisée pour rechercher l'objet correspondant dans le cache inclut la version de la chaîne de requête renvoyée par le request processor. Si aucune réponse n'est mise en cache pour cette URL, cette même version modifiée de l'URL est transmise à l'application Express.

Attention à deux écueils lorsque vous utilisez cette approche :

Tout d'abord, assurez-vous que votre application ne dépend d'aucun des paramètres filtrés pour son rendu ! Par exemple, si vous filtrez le paramètre search de la request ci-dessus, vous aurez du mal à afficher les bons résultats de recherche.

Deuxièmement, soyez prudent lorsque vous filtrez des paramètres des requests que vous souhaitez rediriger. Si votre code ne peut pas accéder à un paramètre filtré, ce paramètre ne peut pas non plus être utilisé pour la redirection. Considérons une request d'un composant de page d'accueil qui redirige une request pour www.example.com?lang=en vers un chemin spécifique local comme www.example.com/en. Si vous filtrez le paramètre lang, vous ne pouvez pas rediriger vers le bon paramètre régional.

Prenons cette séquence :

1. Le request processor traite une request pour www.example.com/?gclid=123.
2. Le request processor filtre le paramètre gclid de la chaîne de requête.
3. La request est transmise à l'application avec l'URL complète www.example.com.
4. L'application renvoie une redirection vers www.example.com/en.

Remarquez que lors de cette dernière étape, nous avons perdu le paramètre original gclid, il ne sera donc pas disponible pour le navigateur après la redirection de l'utilisateur. Pour contourner ce problème, évitez de filtrer les chaînes de requête des requests que vous souhaitez rediriger.

Vous savez maintenant comment améliorer vos accès au cache pour les requests de pages à l'aide de plusieurs techniques.

Lisez notre guide sur Requests via proxy pour en savoir plus sur la mise en cache des requests API et les autres avantages du proxy.