Optimisation des performances AEM site

Description

Environnement
Adobe Experience Manager

Problème/Symptômes
Cet article se concentre sur les moyens d’améliorer les performances de votre site. Nous avons mis en évidence les différents aspects des applications et architectures Adobe Experience Manager (AEM) qui ont causé le plus de problèmes de performances. En implémentant les optimisations répertoriées ici, vous pouvez éviter ces problèmes courants.

Résolution

Performances du site

  1. Effectuer maintenance régulière.
  2. Rendre les appels de service principal intolérants aux erreurs - voir cet article pour plus d’informations.
  3. Soyez prudent lors de l’utilisation de structures d’interface utilisateur tierces : nous avons vu un certain nombre de clients utiliser ou créer des bibliothèques qui construisent une couche entière sur la structure web AEM/Sling. Notez que nous ne faisons pas référence aux utilitaires qui ciblent des fonctionnalités spécifiques de l’interface utilisateur (par exemple, ACS Commons), mais aux structures qui modifient fondamentalement la manière dont vous implémentez votre application sur AEM. Bien que ces structures puissent légèrement réduire le temps de développement, nous avons souvent constaté qu’elles peuvent avoir un impact négatif sur les performances.
    Les structures tierces ne sont pas prises en charge ni testées par Adobe. Lors de l’utilisation ou de l’implémentation de telles structures, assurez-vous de charger et de tester minutieusement votre application avec un trafic réaliste.

Performances côté client

  • Utiliser et optimiser les bibliothèques clientes d’AEM : les bibliothèques clientes sont un moyen facile de centraliser la gestion et l’optimisation du code CSS et JavaScript dans votre site.

    • Incorporer bibliothèques clientes pour les consolider en moins de fichiers.
    • Minify les bibliothèques.

  • Insérer CSS dans la balise d’en-tête de HTML : permet d’éviter le scintillement et la réactualisation de la page après le chargement.

  • Insérer un script JavaScript dans la balise de fin de corps ou ajouter la balise attribut de script asynchrone : permet au navigateur de charger des fichiers JavaScript en parallèle pendant le rendu de la page.

  • Mise en oeuvre du partage de domaine : par défaut, les navigateurs web limitent le nombre maximum de requêtes parallèles par domaine pendant le chargement de la page. Cela peut entraîner des retards dans le chargement de la page si vous disposez de nombreuses ressources telles que CSS, JavaScript, etc. qui doit être chargé avant le rendu de votre page. Le partage de domaine est une solution qui permet de résoudre ce problème. Le partage de domaine est l’emplacement où vous incluez des fichiers tels que CSS et JavaScript sur votre site via plusieurs sous-domaines.

    • Par exemple :

      script src="//includes1.yoursite.com/etc/clientlibs/test.js"/script

      script src="//includes2.yoursite.com/etc/clientlibs/test2.js"/script

    • Utilisation ACS Commons - Static Reference Rewriter pour mettre en oeuvre le partage de domaine.

  • Cache JavaScript et CSS pendant de longues périodes : pour permettre la mise en cache de JavaScript et de CSS pendant de longues périodes, utilisez ACS Commons - Clientlibs versionnées.

  • Voir Documentation sur les règles Google PageSpeed pour plus d’informations sur l’optimisation de votre site.

  • Voir Session AEM Gems pour plus d’informations sur les optimisations du site.

Performances de modification de l’instance d’auteur

  1. Effectuer maintenance régulière.
  2. Réduire le total des composants sur la page : lorsqu’il existe des centaines de composants modifiables individuels chargés sur une page d’AEM dans une instance d’auteur, cela affecte considérablement les performances de l’interface utilisateur de l’éditeur. Lors de la conception de votre application, préférez les composants plus spécifiques au site et faciles à utiliser par les éditeurs par rapport aux composants génériques comportant de nombreux sous-composants.
  3. Évitez d’imbriquer de nombreux niveaux de composants de conteneur (système de paragraphes, grille réactive, fragments d’expérience) - Évitez d’imbriquer de nombreux niveaux de composants de conteneur. L’imbrication de systèmes de paragraphes ou de grilles réactives ralentit le chargement de la page /editor.html. C’est particulièrement le cas lorsque le système de paragraphes ou la grille réactive contient une longue liste de contenu. Au lieu d’imbriquer des systèmes de paragraphes, concevez l’application pour référencer du contenu à partir d’autres pages. Si vous optez pour l’utilisation de fragments d’expérience, évitez également de les imbriquer ou utilisez l’option blocs de création :text=Construction%20Blocks%20with%20Experience%20Fragments&text=Construction%20blocs%20enable%20content%20authors,différent%20variations%20of%20Experience%20Fragments.&text=The%20template%20used%20for%20Experience,to%20reset%20components%20over%20variations). Les fragments d’expérience imbriqués sont affectés par les mêmes limitations de performances.

Optimisation du cache

Dans une architecture de site AEM commune, la requête HTTP passe par plusieurs caches avant d’atteindre enfin les instances de publication AEM. L’une des méthodes les plus simples pour améliorer les performances du site consiste à optimiser la mise en cache de votre site.

Voir cet article pour obtenir des instructions détaillées sur la manière d’optimiser la mise en cache sur votre site.

Optimisation des index pour les requêtes JCR personnalisées

Une autre optimisation qui améliore les performances consiste à configurer et à optimiser les index Oak pour vos requêtes JCR personnalisées. Si vous utilisez des requêtes JCR dans votre application, il s’agit généralement d’une tâche obligatoire.

Consultez la documentation officielle (1 et 2) pour savoir comment implémenter des index Oak pour vos requêtes d’application personnalisées.:

  1. Bonnes pratiques en ce qui concerne les requêtes et l’indexation
  2. Résolution des problèmes de lenteur des requêtes

QueryBuilder guessTotal

Si vous utilisez l’AEM QueryBuilder et que vous prévoyez que la requête renvoie de nombreux résultats, veillez toujours à définir la propriété guessTotal sur le PredicateGroup racine, car cela réduira l’utilisation de la mémoire. Consultez la documentation officielle à ce sujet pour plus de détails : API Query Builder

Sur cette page