Optimisation des caches de site AEM

Description

Environnement

Adobe Experience Manager

Problèmes/symptômes

L’optimisation de la mise en cache dans votre architecture AEM est l’un des moyens les plus rapides pour obtenir un gain de performances important.  Cet article explique comment optimiser les différents caches disponibles dans une architecture AEM.

Architecture AEM et mise en cache

Dans toutes les architectures d’AEM, l’utilisateur rencontre plusieurs couches de cache lors de sa visite sur votre site.  Il existe 4 calques de cache à prendre en compte dans une architecture d’AEM standard.  Cela inclut les instances de navigateur web, CDN, Dispatcher et AEM.

Résolution

Mise en cache du navigateur

Le premier niveau de cache qu’un utilisateur rencontre lors d’une visite répétée de votre site est son propre navigateur.  La mise en cache au niveau du navigateur est généralement effectuée via le Cache-Control: max-age=… response header.  Le max-age indique au navigateur combien de secondes il doit mettre le fichier en cache avant de tenter de le "revalider" ou de le demander à nouveau sur le site.  Ce concept de cache max-age est généralement appelé "expiration du cache" ou TTL ("durée de vie").

Il existe différentes options (ou "directives") dans la variable Cache-Control en-tête qui affecte la manière dont la mise en cache se produit.  Voici quelques directives courantes :

1. ​private - le private dans la variable Cache-Control En-tête , il est ainsi créé afin que le fichier ne soit mis en cache que dans le navigateur, et non dans les caches intermédiaires tels que les CDN.  Une utilisation pratique de cette directive serait si votre page comprend du contenu personnalisé/spécifique à l’utilisateur.

   Cas d’utilisation :

     Cache-Control: max-age=300, privé

2. ​ s-maxage - le s-maxage dans la variable Cache-Control L’en-tête vous permet de définir un TTL différent pour les caches partagés, tels que les CDN.  Lorsque cette valeur est définie, le navigateur utilise ce qui est défini dans max-age et d’autres caches respecteraient s-maxage à la place.

   Cas d’utilisation :

   Cache-Control: max-age=600, s-maxage=300

Les navigateurs modernes prennent tous en charge la variable Cache-Control Toutefois, certains anciens en-têtes obsolètes existent à partir de HTTP/1.0 et peuvent avoir un impact sur la mise en cache.  Ces en-têtes sont Expires et Pragma.  Si vous n’avez pas besoin de prendre en charge de très anciens navigateurs, n’envoyez pas ces en-têtes de réponse.
Outre la mise en cache, la revalidation est également un concept important.  La revalidation repose sur la fonction Last-Modified (response) / If-Modified-Since (requête), et la variable ETag (réponse) / If-None-Match en-têtes (requête).

Attention aux tests du navigateur :

Lors du test de la mise en cache dans Google Chrome, si vous effectuez un test sur https et que vous disposez d’un certificat auto-signé, rien ne sera mis en cache.  Chrome ne met pas en cache les réponses ni n’effectue de revalidation lorsqu’il existe un certificat non approuvé ou non valide.

Remarque sur Dispatcher :

Il existe un problème avec AEM Dispatcher v4.2.3 et les versions antérieures où la variable /enableTTL uniquement les caches utilisant max-age .  Cela signifie que, même si private ou s-maxage Les directives sont définies. elles sont toujours mises en cache si max-age est définie.  Ce problème est résolu dans Dispatcher 4.2.4 et versions ultérieures.

Mise en cache CDN

A CDN ou "Réseau de diffusion de contenu", est un réseau distribué de serveurs web conçu pour mettre en cache et diffuser du contenu à partir de l’emplacement le plus proche de vos utilisateurs.  Cela réduit les sauts et la distance du réseau de l’ordinateur de l’utilisateur par rapport à votre contenu, ce qui réduit la fréquence "Tour Trip Time" (RTT).  La TTF correspond au temps nécessaire au navigateur pour envoyer une requête à votre site et recevoir une réponse.  La concurrence dans l’espace du fournisseur de réseau CDN a rendu les réseaux CDN très rentables.  Cela facilite la décision d’utiliser un réseau de diffusion de contenu pour votre site.  Si vous n’utilisez pas encore de réseau de diffusion de contenu, vous devez absolument en incorporer un sur votre site.

Il existe de nombreux fournisseurs de réseau de diffusion de contenu, chacun d’eux offre différentes fonctionnalités et configurations.

Comment fonctionne la mise en cache CDN ?

Les CDN mettent en cache le contenu en suivant des règles similaires aux navigateurs.  Ils dépendent de la variable Cache-Control HTTP response et revient généralement au Expires header if Cache-Control L’en-tête se trouve.

La plupart des CDN offrent un moyen de déclencher un vidage manuel du cache.  Dans de nombreux cas, les vidages de cache ont un certain délai (par exemple, 15 minutes) en ce qui concerne la propagation vers tous les serveurs Edge contenant vos fichiers.

Optimisation de l’utilisation du réseau de diffusion de contenu

Pour vous assurer que vous mettez en cache les fichiers de manière optimale dans le réseau de diffusion de contenu, procédez comme suit :

1. Utilisation d’un réseau de diffusion de contenu qui prend en charge stale-while-revalidate et stale-if-error dans les Cache-Control en-tête .

   • stale-while-revalidate - Cette directive indique au réseau de diffusion de contenu de servir l’ancienne version (déjà mise en cache) du fichier pendant qu’il en récupère une nouvelle une fois que le fichier de cache a expiré.
   • stale-if-error - de même, cette directive indique au réseau de diffusion de contenu de servir l’ancienne version (déjà mise en cache) du fichier lorsque l’origine répond avec une erreur lors de la revalidation.

2. GZip compresse les réponses pour tous les types de fichiers qui ne sont pas pré-compressés.
   Vous devez le faire à partir du niveau du Dispatcher.  Vous réduirez ainsi le nombre d’octets envoyés au réseau CDN.  Les CDN sont généralement chargés par octets transférés, de sorte que la compression des réponses réduit les coûts.

• Activer la compression GZip au niveau de Dispatcher : Apache - use mod_deflate.  Faites attention à l’utilisation de mod_deflate de Vary.  Dans certains cas, l’en-tête Vary peut faire que le réseau de diffusion de contenu et le navigateur ignorent entièrement la mise en cache.

• Microsoft IIS - use Compression dynamique.

• N’autorisez pas la compression gzip des fichiers volumineux ou déjà compressés.  Notez que la plupart des formats d’image et vidéo sont déjà précompressés.  Les compresser à la volée au niveau du serveur web coûte très cher en performances.

  • Sous Apache, vous pouvez le faire via la directive AddOutputFilterByType :

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  • Sur IIS, cela peut être contrôlé via la fonction < dynamicTypes> configuration.

• Si votre fournisseur de réseau de diffusion de contenu prend en charge Inclusions côté périphérie (ESI) exploitez ensuite cette fonctionnalité. Les composants AEM peuvent être fragmentés à l’aide de l’ESI. Pour ce faire, utilisez Apache [ Inclusions dynamiques Sling] (https://github.com/Cognifide/Sling-Dynamic-Include) ou implémentez une solution personnalisée. Cela s’avère utile lorsque vous disposez de pages assez statiques mais que vous diffusez du contenu plus dynamique dans quelques parties de la page. Dans ce cas, vous divisez essentiellement la page en plusieurs fichiers CDN. Vous pouvez ainsi mettre en cache différentes parties de la page pendant différentes périodes.

Fournisseurs de réseau de diffusion de contenu populaires

Voici une liste de certains fournisseurs de réseau de diffusion de contenu populaires :

• Microsoft Azure CDN
• Amazon Cloudfront
• Akamai
• Google Cloud CDN
• Rackspace CDN
• Réseau de diffusion de contenu Stackpath (anciennement appelé réseau de diffusion de contenu max.)
• Cloudflare
• Fastly
• Réseau de diffusion de contenu F5

Il y en a plusieurs autres, chacune avec des fonctionnalités différentes.

Attention :

Faites attention aux Vary en-tête de la réponse.  Dans certains cas, Vary peut empêcher le CDN et le navigateur d’ignorer entièrement la mise en cache.  En règle générale, évitez d’ajouter Vary sauf pour Vary: Accept-Encoding (appliquée uniquement lorsque la réponse est compressée par gzip).  En d’autres termes, si vous devez "varier" la sortie d’une réponse, utilisez une URL différente.

Par exemple, si vous disposez d’une version différente du HTML pour mobile et bureau, utilisez une autre URL.  Cela permet aux CDN et aux navigateurs de mettre en cache plus efficacement.

Mise en cache AEM Dispatcher

Si le cache du réseau de diffusion de contenu a expiré, la demande atteint le cache du Dispatcher AEM.  À ce niveau, de nombreuses actions peuvent être entreprises pour optimiser la mise en cache.

Puisqu’il s’agit d’un sujet plus important, reportez-vous à la section cet article pour plus d’informations sur l’optimisation du cache du dispatcher.

Instances de publication AEM

Au niveau de l’AEM, quelques actions sont nécessaires pour optimiser les différentes couches de cache :

1. Définissez les en-têtes de réponse HTTP suivants qui ne sont pas définis par AEM par défaut.

   1. Cache-Control: max-age=… - Pour définir cet en-tête, ACS Commons - Dispatcher TTL peut être utilisé ou vous pouvez implémenter du code personnalisé pour le définir.
   2. Last-Modified - Si le contenu de la page est relativement statique, par exemple un article, vous pouvez définir son en-tête de dernière modification sur la date/heure cq:lastModified (dernière fois que l’article a été modifié).  Cependant, si la page est dynamique avec des résultats de requête JCR contenus dans le contenu du composant, il est préférable de la définir pour utiliser la date/l’heure actuelle.
   3. ETag - Si vous décidez d’utiliser ceci au lieu de Last-Modified, vous pouvez écrire une ReplicationEventListener qui écoute les activations de page et génère un hachage md5 du contenu de la page.  Cela peut être défini en tant que propriété sur le noeud jcr:content de la page sur l’instance de création.  Lorsque des pages sont répliquées, elles sont envoyées aux instances de publication.  Pour les composants de page dont le contenu est relativement statique, cela peut fonctionner. Toutefois, si la page est quelque peu dynamique ou référence un contenu important, l’ETag doit être omis (ou calculé).

2. Si le site comporte du contenu personnalisé/dynamique :

   1. Utilisation Inclusions dynamiques Apache Sling pour séparer le contenu afin que différentes parties de la page puissent être mises en cache pendant différentes périodes.

      1. La mise en cache peut être réalisée à l’aide des technologies suivantes :

         1. Edge-side Includes (ESI) sur le réseau de diffusion de contenu
         2. Server-side Includes (SSI) sur le serveur web
         3. Ou, JavaScript et XML asynchrones (AJAX) sur le navigateur

      2. Les composants de la page peuvent être divisés en requêtes distinctes qui peuvent être mises en cache pendant différentes périodes.  Certaines parties de la page relativement statiques peuvent être mises en cache pendant une période beaucoup plus longue.

   2. Envisagez d’utiliser la variable Fonctionnalité de cache HTTP d’ACS Commons.

3. Optimisez les bibliothèques clientes.

   1. Activer la minification sur les bibliothèques clientes.

   2. Si les fichiers de la bibliothèque cliente sont préminifiés, désactivez la minification sur cette bibliothèque cliente.  Modifiez le noeud cq:ClientLibraryFolder :

      1. Définir la propriété jsProcessor de type Chaîne[ ] avec valeur min:none
      2. et définissez la propriété cssProcessor de type Chaîne[ ] avec valeur min:none
      3. Voir plus de détails, here.

   3. client intégré bibliothèques pour réduire et réduire les fichiers js et css.

   4. Mise en oeuvre versioned-clientlibs d’ACS Commons pour permettre au réseau de diffusion de contenu et au Dispatcher de mettre en cache les fichiers js et css pendant de plus longues périodes.