Expiration des objets statiques

Les objets statiques (par exemple, les icônes) ne changent pas. Par conséquent, le système devrait être configuré de façon à ce qu’elles n’expirent pas (pendant une période raisonnable) de façon à réduire le trafic inutile.

Cela se répercute de la manière suivante :

  • Décharge les demandes de l’infrastructure du serveur.
  • Augmente les performances de chargement des pages dans la mesure où le navigateur met en cache les objets dans le cache du navigateur.

Les expirations sont spécifiées par la norme HTTP concernant « l’expiration » des fichiers (voir, par exemple, Chapitre 14.21 de RFC 2616 « Hypertext Transfer Protocol - HTTP 1.1 »). Cette norme utilise l’en-tête pour permettre aux clients de mettre en cache des objets jusqu’à ce qu’ils soient considérés comme périmés ; ces objets sont mis en cache pendant la durée spécifiée sans qu’aucun contrôle de statut ne soit effectué sur le serveur d’origine.

REMARQUE

Cette configuration est complètement distincte du Dispatcher (et ne fonctionnera pas pour lui).

Le Dispatcher a pour objectif de mettre les données en mémoire cache en amont d’AEM.

Tous les fichiers, qui ne sont pas dynamiques et qui ne changent pas au fil du temps, peuvent et doivent être mis en cache. La configuration du serveur HTTPD Apache peut ressembler à l’une des suivantes, selon l’environnement :

ATTENTION

Soyez prudent lorsque vous définissez la période pendant laquelle un objet est considéré comme étant à jour. Dans la mesure où il n’y a pas de vérification tant que la période spécifiée n’a pas expiré, le client peut finir par présenter du contenu ancien à partir du cache.

  1. Pour une instance d’auteur :

    LoadModule expires_module modules/mod_expires.so
<Location /libs>
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/gif "access plus 1 month"
</Location>

    Cela permet au cache intermédiaire (par exemple le cache du navigateur) de stocker des fichiers CSS, Javascript, PNG et GIF pendant un mois au maximum, jusqu’à leur expiration. Cela signifie qu’il est inutile de les demander à AEM ou au serveur web, mais qu’ils peuvent rester dans le cache du navigateur.

    Les autres sections du site ne doivent pas être mises en cache sur une instance d’auteur, car elles peuvent être modifiées à tout moment.

  2. Pour une instance de publication :

    LoadModule expires_module modules/mod_expires.so
<Location /content>
  ExpiresByType text/css "access plus 1 day"
  ExpiresByType text/javascript "access plus 1 day"
  ExpiresByType image/png "access plus 1 day"
  ExpiresByType image/gif "access plus 1 day"
</Location>
<Location /etc/designs>
  ExpiresByType text/css "access plus 1 day"
  ExpiresByType text/javascript "access plus 1 day"
  ExpiresByType image/png "access plus 1 day"
  ExpiresByType image/gif "access plus 1 day"
</Location>

    Cela permet au cache intermédiaire (par exemple le cache du navigateur) de stocker des fichiers CSS, Javascript, PNG et GIF pendant un jour au maximum dans les caches clients. Bien que cet exemple illustre les paramètres globaux pour tout ce qui se situe sous /content et /etc/designs, vous devriez les rendre plus granulaires.

    Selon la fréquence de mise à jour de votre site, vous pouvez également envisager de mettre en cache les pages HTML. Un intervalle de temps raisonnable serait d’une heure :

    <Location /content>
  ExpiresByType text/html "access plus 1 hour"
</Location>

Après avoir configuré les objets statiques, parcourez request.log, tout en sélectionnant les pages qui contiennent de tels objets, pour confirmer qu’aucune demande (inutile) n’est faite pour les objets statiques.

Sur cette page