Présentation

L’optimisation de la mise en cache dans votre architecture AEM est l’une des méthodes les plus rapides pour optimiser les performances.  Cet article décrit comment optimiser les différents caches disponibles dans une architecture AEM.

Architecture et mise en cache de AEM

Dans toutes les architectures AEM, l’utilisateur rencontre plusieurs couches de cache lorsqu’il visite votre site.  Il y a 4 couches de cache à prendre en compte dans une architecture AEM standard.  Ceci inclut les navigateurs Web, les réseaux de distribution de contenu, Dispatcher et les instances AEM.

screenshot_2018-03-25160541

Mise en cache du navigateur :

Le premier niveau de cache qu'un utilisateur rencontre sur une visite répétée de votre site est son propre navigateur.  La mise en cache au niveau du navigateur est réalisée habituellement via le Cache-Control: max-age=... response header.  Le paramètre max-age indique au navigateur combien de secondes il doit mettre en cache le fichier avant de le « revalider » ou de le redemander au site.  Ce concept de cache max-age est généralement désigné sous le nom de « expiration du cache » ou TTL (« Time to Live »).

Il existe diverses options (ou « directives ») dans l'en-tête Cache-Control qui ont une incidence sur la façon dont la mise en cache se produit.  Voici quelques directives courantes :

  1. privé - La directive privé dans l'en-tête Cache-Control fait en sorte que le fichier est uniquement mis en cache dans le navigateur et non pas dans les caches intermédiaires tels que les réseaux de distribution de contenu.  Une utilisation pratique de cette directive serait si votre page inclut du contenu personnalisé ou spécifique à l'utilisateur. 

    Exemple d'utilisation :
    Cache-Control: max-age=300, privé.
  2. s-maxage - La directive s-maxage dans l'en-tête Cache-Control 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 emploie ce qui est défini sous max-age et les autres caches respectent le paramètre s-maxage à la place.

    Exemple d'utilisation :
    Cache-Control: max-age=600, s-maxage=300

Les navigateurs récents prennent tous en charge l'en-tête Cache-Control, cependant, certains anciens en-têtes obsolètes existent sous 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 des navigateurs très anciens, n’envoyez pas ces en-têtes de réponse.
En plus de la mise en cache, la revalidation est l'un des principaux concepts.  La revalidation repose sur les en-têtes Last-Modified (réponse) / If-Modified-Since (requête), et les en-têtes ETag (réponse) / If-None-Match (requête).

Attention :

Test du navigateur :

Lors du test de la mise en cache dans Google Chrome, si vous effectuez un test sur https et si vous disposez d’un certificat auto-signé, aucune mise en cache n’est effectuée.  Chrome ne masque pas les réponses ou n'exécute pas de revalidation lorsqu'il existe un certificat non approuvé ou non valide.

Remarque sur le dispatcher :

Il existe un problème avec le Dispatcher AEM v 4.2.3 et les versions antérieures où seuls les caches /enableTTL utilisant la directive max-age.  Cela signifie que même si les directives privé ou s-maxage sont paramétrées, le max-age est défini.  Ce problème est résolu dans le Dispatcher 4.2.4 et versions antérieures.

Mise en cache CDN

 Un CDN ou un "Content Delivery Network", est un réseau indiqué des serveurs web conçu pour masquer et afficher du contenu à partir de l'emplacement le plus proche de vos utilisateurs.  Cela réduit les sauts et la distance de réseau à partir de l’ordinateur de l’utilisateur jusqu’à votre contenu, ce qui réduit le « temps de voyage aller-retour » (RTT).  RTT est le temps nécessaire au navigateur pour envoyer une demande à votre site et recevoir une réponse.  La concurrence dans l'espace fournisseur CDN a été très rentable.  C'est pour cela qu'il est facile de décider d'utiliser un réseau de distribution de contenu pour votre site.  Si vous n'utilisez pas encore un réseau de distribution de contenu, vous devriez vraiment en incorporer un à votre site.

Il existe de nombreux fournisseurs de réseau de distribution de contenu, chacun propose différentes configurations et fonctionnalités.

Fonctionnement de la mise en cache du réseau de distribution de contenu :

Les réseaux de distribution de contenu masquent le contenu suivant des règles similaires aux navigateurs.  Ils s'appuient sur l'en-tête réponse HTTP de Cache-Control et généralement retombent sur l'en-tête Expires si aucun en-tête Cache-Control n'est détecté.

La plupart des réseaux de distribution de contenu offrent une méthode de purge manuelle du cache.  Dans de nombreux cas, les purges de cache ont un certain délai (par exemple 15 minutes) en vue de la diffusion sur tous les serveurs périphériques qui détiennent vos fichiers.

Optimisation du réseau de distribution de contenu :

Pour vous assurer que vous mettez en cache des fichiers de manière optimale dans le réseau de distribution de contenu, vous devez procéder de la façon suivante :

  1. Utilisez un réseau de distribution de contenu prenant en charge les directives stale-while-revalidate et stale-if-error dans l'en-tête Cache-Control.
    • stale-while-revalidate - Cette directive demande au réseau de distribution de contenu de servir l'ancienne version (déjà en cache) du fichier lorsqu'il en cherche une nouvelle à la suite de l'expiration du fichier cache.
    • stale-if-error - De la même manière, cette directive demande au réseau de distribution de contenu de servir l'ancienne version (déjà en cache) du fichier lorsque l'origine répond avec une erreur durant 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.  Cela permet de réduire le nombre d’octets envoyés au réseau de distribution de contenu.  Les réseaux de distribution de contenu sont tarifés généralement par octets transférés donc compresser les réponses peut en réduire le coût.
    • Activer la compression GZip au niveau du dispatcher :
      • Apache - Utilisez mod_deflate.  Soyez prudent pour l'utilisation de mod_deflate de Vary.  Dans certains cas, l’en-tête dépendant peut provoquer la mise en cache et l’exécution du navigateur pour ignorer entièrement la mise en cache.
      • Microsoft IIS - Utilisez la Compression Dynamique.
  3. Si votre fournisseur de CDN prend en charge Edge-side Includes (ESI) alors exploitez cette fonctionnalité.
    • Les composants AEM peuvent être divisés en utilisant ESI.  Pour le faire, utilisez Apache Sling Dynamic Includes ou implémentez une solution personnalisée.
    • Il est utile lorsque vous avez suffisamment de pages statiques mais que vous diffusez un contenu plus dynamique dans quelques parties de la page.  Dans ces cas, vous divisez la page en plusieurs fichiers de réseau de distribution de contenu.  Ainsi, vous pouvez mettre en cache différentes parties de la page pour différentes périodes.

Fournisseurs de réseau de distribution de contenu populaires :

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

Attention :

Faites attention à l'en-tête de réponse Vary.  Dans certains cas, Vary peut totalement faire sauter la mise en cache au CDN et au navigateur.  En règle générale, évitez d'ajouter l'exception Vary à l'exception de : Vary: Accept-Encoding (appliqué seulement 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 de différentes versions du code HTML pour mobile et bureau, utilisez une autre URL.  Cela permet aux navigateurs de réseau de distribution de contenu et aux navigateurs de mettre en mémoire cache plus efficacement.

Mise en cache du dispatcher AEM :

Si le cache de réseau de distribution de contenu a expiré, la requête aurait atteint la mémoire cache du dispatcher AEM.  À ce niveau, il existe de nombreux éléments qui peuvent être utilisés pour optimiser la mise en cache.

Comme il s'agit d'une plus grande rubrique, reportez-vous à cet article pour apprendre à optimiser le cache du dispatcher.

Instances de publication AEM :

Au niveau AEM, il existe quelques choses à faire pour optimiser la mise en cache sur 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 défaut par AEM.
    1. Cache-Control : max-age =… - Pour définir cet en-tête, ACS Commons - Dispatcher TTL peut être utilisé, ou vous pourriez mettre en œuvre un code personnalisé pour le définir.
    2. Last-Modified - Si le contenu de la page est relativement statique, comme par exemple un article, vous pouvez définir la dernière modification de son en-tête à cq:lastModified date/heure (la dernière fois que l'article a été modifié).  Toutefois, si la page est dynamique avec des résultats de requête JCR intégrés au contenu du composant, il serait préférable de la définir pour utiliser la date/heure actuelle.
    3. ETag - Si vous décidez d'utiliser ceci à la place de Last-Modified, vous pouvez saisir un ReplicationEventListener qui écoute les activations de page et génère un hachage md5 du contenu de la page.  Cela peut être défini comme propriété sur le nœud jcr:content de la page de l’occurrence d’auteur.  Une fois les pages répliquées, elles sont envoyées aux instances de publication.  Pour les composants de page dont le contenu est relativement statique, ceci peut bien fonctionner, mais si la page est assez dynamique ou comporte beaucoup de références, la propriété ETag doit être omise (ou calculée).
  2. Si le site dispose de contenu dynamique ou personnalisé :
    1. Utilisez Apache Sling Dynamic Includes pour diviser le contenu de façon à ce que les parties différentes de la page puissent être mises en cache pour différentes périodes.
      1. La mise en cache peut être réalisée avec les technologies suivantes :
        1. Edge-side comprend (MCI) sur le CDN
        2. Server-side Includes (SSI) sur le serveur Web
        3. Ou, Asynchronous JavaScript et XML (AJAX) sur le navigateur
      2. Les composants de la page peuvent être divisés en requêtes distinctes qui peuvent être mises en cache pour des périodes différentes.  Les parties de la page qui sont relativement statiques peuvent être mises en cache pour des périodes beaucoup plus longues.
    2. Utilisez la fonction de cache de HTTP de ACS Commons.
    3. Activer la minification sur des bibliothèques client.
    4. Des bibliothèques client intégrées pour compresser et réduire des fichiers js et css.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne