Présentation intro

Le trafic emprunte un réseau CDN pour parvenir à une couche de serveur web Apache, qui prend en charge les modules, y compris le Dispatcher. Pour améliorer les performances, le Dispatcher sert essentiellement de cache pour limiter les traitements des nœuds de publication.
Il est possible d’appliquer des règles à la configuration du Dispatcher pour modifier les paramètres d’expiration du cache par défaut, ce qui entraîne la mise en cache sur le réseau CDN. Notez que le Dispatcher respecte également les en-têtes d’expiration de cache qui en résultent si enableTTL est activé dans sa configuration, ce qui implique qu’il actualisera un contenu spécifique même en dehors du contenu en cours de republication.

Cette page décrit également comment le cache du Dispatcher est invalidé, ainsi que le fonctionnement de la mise en cache au niveau du navigateur concernant les bibliothèques côté client.

Mise en cache caching

HTML/texte html-text

Define DISABLE_DEFAULT_CACHING

Cette méthode peut se révéler utile, par exemple, lorsque votre logique commerciale nécessite un réglage précis de l’en-tête d’âge (avec une valeur basée sur le jour du calendrier) puisque, par défaut, l’en-tête d’âge est défini sur 0. Cela étant, faites preuve de prudence lorsque vous désactivez la mise en cache par défaut.

Bibliothèques côté client (js, css) client-side-libraries

Images et tout contenu suffisamment volumineux pour être stocké dans le stockage blob images

Le comportement par défaut des programmes créés après la mi-mai 2022 (en particulier, pour les identifiants de programme supérieurs à 65 000) est de mettre en cache par défaut, tout en respectant le contexte d’authentification de la requête. Les programmes plus anciens (id de programme égal ou inférieur à 65 000) ne mettent pas en cache le contenu de l’objet Blob par défaut.

Dans les deux cas, les en-têtes de mise en cache peuvent être remplacés à un niveau plus fin au niveau de la couche Apache ou du Dispatcher à l’aide des directives Apache mod_headers, par exemple :

   <LocationMatch "^/content/.*\.(jpeg|jpg)$">
     Header set Cache-Control "max-age=222"
     Header set Age 0
   </LocationMatch>

Lorsque vous modifiez les en-têtes de mise en cache sur la couche du Dispatcher, veillez à ne pas créer un cache trop important. Consultez la discussion dans la section HTML/texte ci-dessus. Assurez-vous également que les ressources destinées à être conservées en privé (plutôt que mises en cache) ne font pas partie des filtres de directive LocationMatch.

Les ressources JCR (plus de 16 Ko) stockées dans la banque d’objets Blob sont généralement diffusées sous la forme de redirections 302 par AEM. Ces redirections sont interceptées et suivies par le réseau de diffusion de contenu et le contenu est diffusé directement à partir de la banque d’objets blob. Seul un ensemble limité d’en-têtes peut être personnalisé sur ces réponses. Par exemple, pour personnaliser Content-Disposition vous devez utiliser les directives dispatcher comme suit :

<LocationMatch "\.(?i:pdf)$">
  ForceType application/pdf
  Header set Content-Disposition inline
  </LocationMatch>

La liste des en-têtes pouvant être personnalisés dans les réponses d’objets blob est la suivante :

content-security-policy
x-frame-options
x-xss-protection
x-content-type-options
x-robots-tag
access-control-allow-origin
content-disposition
permissions-policy
referrer-policy
x-vhost
content-disposition
cache-control
vary

Nouveau comportement de mise en cache par défaut new-caching-behavior

La couche AEM définit les en-têtes de cache en fonction de la définition éventuelle de l’en-tête de cache et de la valeur du type de requête. Si aucun en-tête de contrôle du cache n’est défini, le contenu public est mis en cache et le trafic authentifié est défini sur privé. Si un en-tête de contrôle du cache est défini, les en-têtes du cache sont laissés intacts.

Bien que cela ne soit pas recommandé, il est possible de modifier le nouveau comportement par défaut pour suivre l’ancien comportement (identifiants de programme égaux ou inférieurs à 65 000) en définissant la variable d’environnement Cloud Manager. AEM_BLOB_ENABLE_CACHING_HEADERS sur false.

Ancien comportement de mise en cache par défaut old-caching-behavior

Par défaut, le calque AEM ne met pas en cache le contenu blob.

Actuellement, les images dans l’espace de stockage blob marquées comme privées ne peuvent pas être mises en cache dans le Dispatcher à l’aide de l’option Mise en cache sensible aux autorisations. L’image est toujours demandée à l’origine d’AEM et diffusée si la personne utilisatrice est autorisée.

Autres types de fichiers de contenu dans le magasin de nœuds other-content

Autres optimisations further-optimizations

Analyse du ratio d’accès au cache du réseau CDN analyze-chr

Voir tutoriel sur l’analyse du taux d’accès au cache pour plus d’informations sur le téléchargement des journaux CDN et l’analyse du taux d’accès au cache de votre site, à l’aide d’un tableau de bord.

Comportement de la requête HEAD request-behavior

Lorsqu’une requête HEAD est reçue sur le réseau CDN Adobe pour une ressource qui n’est pas mise en cache, la requête est transformée et reçue par le Dispatcher et/ou l’instance AEM en tant que requête GET. Si la réponse peut être mise en cache, les requêtes HEAD suivantes sont diffusées à partir du réseau CDN. Si la réponse ne peut pas être mise en cache, les requêtes HEAD suivantes sont transmises au Dispatcher et/ou à l’instance AEM pendant une période qui dépend de la durée de vie (TTL) du Cache-Control.

Paramètres de campagne marketing marketing-parameters

Les URL de site Web incluent souvent des paramètres de campagne marketing qui servent à suivre le succès d’une campagne.

Pour les environnements créés en octobre 2023 ou version ultérieure, afin de mieux mettre en cache les requêtes, le réseau de diffusion de contenu supprimera les paramètres de requête liés au marketing courants, en particulier ceux qui correspondent au modèle regex suivant :

^(utm_.*|gclid|gdftrk|_ga|mc_.*|trk_.*|dm_i|_ke|sc_.*|fbclid)$

Envoyez un ticket d’assistance si vous souhaitez que ce comportement soit désactivé.

Pour les environnements créés avant octobre 2023, il est recommandé de configurer le ignoreUrlParams property as documenté ici.

Il existe deux possibilités d'ignorer les paramètres marketing. (Où la première est préférée pour ignorer le cache via les paramètres de requête) :

/ignoreUrlParams {
   /0001 { /glob "*" /type "allow" }
   /0002 { /glob "page" /type "deny" }
   /0003 { /glob "product" /type "deny" }
}

/ignoreUrlParams {
   /0001 { /glob "*" /type "deny" }
   $include "../cache/marketing_query_parameters.any"
}

Invalidation du cache du Dispatcher disp

En général, il n’est pas nécessaire d’invalider le cache du Dispatcher. Vous devez au contraire vous fier au Dispatcher qui actualise son cache lorsque le contenu est republié et au réseau CDN qui respecte les en-têtes d’expiration du cache.

Invalidation du cache du Dispatcher pendant l’activation/la désactivation cache-activation-deactivation

Comme les versions précédentes d’AEM, la publication ou la dépublication des pages efface le contenu du cache du Dispatcher. Si un problème de mise en cache est suspecté, vous devez republier les pages en question et vous assurer qu’un hôte virtuel correspond à l’hôte local ServerAlias, ce qui est obligatoire pour l’invalidation du cache du Dispatcher.

Lorsque l’instance de publication reçoit une nouvelle version d’une page ou d’une ressource de l’auteur ou de l’autrice, elle utilise l’agent de vidage pour invalider les chemins d’accès appropriés sur son Dispatcher. Le chemin d’accès mis à jour est supprimé du cache du Dispatcher, ainsi que ses parents, jusqu’à un certain niveau (que vous pouvez configurer à l’aide de statfileslevel).

Invalidation explicite du cache du Dispatcher explicit-invalidation

Adobe recommande de s’appuyer sur des en-têtes de cache standard pour contrôler le cycle de vie de la diffusion du contenu. Cependant, si nécessaire, il est possible d’invalider le contenu directement dans le Dispatcher.

La liste suivante contient des scénarios dans lesquels vous souhaitez peut-être invalider explicitement le cache (tout en écoutant éventuellement la fin de l’invalidation) :

Il existe deux méthodes pour invalider explicitement le cache :

Les approches diffèrent en termes de disponibilité de niveau, de capacité à dédupliquer les événements et de garantie de traitement des événements. Le tableau ci-dessous résume ces options :

Les deux actions directement liées à l’invalidation du cache sont l’invalidation de l’API de distribution de contenu Sling (SCD) et la désactivation de l’API de réplication.

De plus, à partir du tableau, vous pouvez observer que :

En conclusion, si vous souhaitez invalider le cache du Dispatcher, l’option recommandée est d’utiliser l’action d’invalidation de l’API SCD depuis l’environnement de création. De plus, vous pouvez également écouter l’événement afin de déclencher d’autres actions en aval.

Distribution de contenu Sling (SCD) sling-distribution

Lors de l’utilisation de l’action SCD depuis l’environnement de création, le modèle d’implémentation est le suivant :

@Reference
private Distributor distributor;

ResourceResolver resolver = ...; // the resource resolver used for authorizing the request
String agentName = "publish";    // the name of the agent used to distribute the request

String pathToInvalidate = "/content/to/invalidate";
DistributionRequest distributionRequest = new SimpleDistributionRequest(DistributionRequestType.INVALIDATE, false, pathToInvalidate);
distributor.distribute(agentName, resolver, distributionRequest);

package org.apache.sling.distribution.journal.shared;

import org.apache.sling.discovery.DiscoveryService;
import org.apache.sling.distribution.journal.impl.event.DistributionEvent;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.event.Event;
import org.osgi.service.event.EventHandler;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import static org.apache.sling.distribution.DistributionRequestType.INVALIDATE;
import static org.apache.sling.distribution.event.DistributionEventProperties.DISTRIBUTION_PATHS;
import static org.apache.sling.distribution.event.DistributionEventProperties.DISTRIBUTION_TYPE;
import static org.apache.sling.distribution.event.DistributionEventTopics.AGENT_PACKAGE_DISTRIBUTED;
import static org.osgi.service.event.EventConstants.EVENT_TOPIC;

@Component(immediate = true, service = EventHandler.class, property = {
        EVENT_TOPIC + "=" + AGENT_PACKAGE_DISTRIBUTED
})
public class InvalidatedHandler implements EventHandler {
    private static final Logger LOG = LoggerFactory.getLogger(InvalidatedHandler.class);

    @Reference
    private DiscoveryService discoveryService;

    @Override
    public void handleEvent(Event event) {

        String distributionType = (String) event.getProperty(DISTRIBUTION_TYPE);

        if (INVALIDATE.name().equals(distributionType)) {
            boolean isLeader = discoveryService.getTopology().getLocalInstance().isLeader();
            // process the OSGi event on the leader author instance
            if (isLeader) {
                String[] paths = (String[]) event.getProperty(DISTRIBUTION_PATHS);
                String packageId = (String) event.getProperty(DistributionEvent.PACKAGE_ID);
                invalidated(paths, packageId);
            }
        }
    }

    private void invalidated(String[] paths, String packageId) {
        // custom logic
        LOG.info("Successfully applied package with id {}, paths {}", packageId, paths);
    }
}

API de réplication replication-api

Ci-dessous, se trouve présenté le modèle d’implémentation lors de l’utilisation de l’action de désactivation de l’API de réplication :

Le point d’entrée de l’agent de vidage n’est pas configurable, mais il est préconfiguré pour pointer sur le Dispatcher, conformément au service de publication exécutant l’agent de vidage.

L’agent de vidage peut généralement être déclenché par des codes personnalisés basés sur des événements ou des workflows OSGi.

String[] paths = …
ReplicationOptions options = new ReplicationOptions();
options.setSynchronous(true);
options.setFilter( new AgentFilter {
  public boolean isIncluded (Agent agent) {
   return agent.getId().equals("flush");
  }
});

Replicator.replicate (session,ReplicationActionType.DELETE,paths, options);

Bibliothèques côté client et cohérence entre les versions content-consistency

Les pages sont composées de code HTML, JavaScript et CSS, ainsi que d’images. Nous vous recommandons d’utiliser le framework de bibliothèques côté client (clientlibs) pour importer des ressources JavaScript et CSS dans des pages HTML, en tenant compte des dépendances entre les bibliothèques JS.

Le framework clientlibs fournit une gestion automatique des versions. Cela signifie que les développeurs et développeuses peuvent archiver les modifications apportées aux bibliothèques JS dans le contrôle de code source et que la dernière version est disponible lorsqu’un client ou une cliente envoie sa version. Sans ce processus, les développeurs et développeuses doivent modifier manuellement le code HTML avec des références à la nouvelle version de la bibliothèque, ce qui est particulièrement onéreux si la même bibliothèque partage de nombreux modèles HTML.

Lorsque les nouvelles versions des bibliothèques sont publiées en production, les pages HTML de référence sont mises à jour avec de nouveaux liens vers ces versions de bibliothèques mises à jour. Une fois que la mémoire cache du navigateur expire pour une page de HTML donnée, il n’est plus possible que les anciennes bibliothèques soient chargées à partir de la mémoire cache du navigateur. En effet, il est désormais garanti que la page actualisée (à partir d’AEM) référence les nouvelles versions des bibliothèques. En d’autres termes, une page HTML actualisée comprend toutes les dernières versions de bibliothèque.

Le mécanisme derrière cette fonctionnalité est un hachage sérialisé, qui est ajouté au lien de la bibliothèque cliente. Cela garantit une URL unique et versionnée au navigateur pour mettre en cache le CSS/JS. Le hachage sérialisé n’est mis à jour que lorsque le contenu de la bibliothèque cliente change. Cela signifie que si des mises à jour non liées se produisent (c’est-à-dire qu’aucune modification n’est apportée au css/js sous-jacent de la bibliothèque cliente), même avec un nouveau déploiement, la référence reste la même. En retour, les interruptions de la mémoire cache du navigateur sont moins nombreuses.

Activer les versions Longcache des bibliothèques côté client – Démarrage rapide du SDK d’AEM as a Cloud Service enabling-longcache

Les inclusions clientlib par défaut sur une page HTML ressemblent à l’exemple suivant :

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.css" type="text/css">

Lorsque le contrôle de version clientlib strict est activé, une clé de hachage à long terme est ajoutée en tant que sélecteur à la bibliothèque cliente. Par conséquent, la référence clientlib ressemble à ceci :

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css" type="text/css">

Le contrôle de version clientlib strict est activé par défaut dans tous les environnements AEM as a Cloud Service.

Pour activer le contrôle de version clientlib strict dans le démarrage rapide du SDK local, effectuez les opérations suivantes :