Show Menu
SUJETS×

Déploiement asynchrone

Les performances et le déploiement sans blocage des bibliothèques JavaScript exigés par nos produits sont de plus en plus importants pour les utilisateurs d’Adobe Experience Cloud. Des outils tels que Google PageSpeed recommandent aux utilisateurs de modifier leur manière de déployer les bibliothèques Adobe sur leur site. Cet article explique comment utiliser les bibliothèques Adobe JavaScript de manière asynchrone.

Synchrone et asynchrone

Déploiement synchrone

Souvent, les bibliothèques sont chargées de manière synchrone dans la balise <head> d’une page. Par exemple :
<script src="example.js"></script>

Par défaut, le navigateur analyse le document et atteint cette ligne, puis commence à récupérer le fichier JavaScript à partir du serveur. Le navigateur attend que le fichier soit renvoyé, puis analyse et exécute le fichier JavaScript. Enfin, il continue d’analyser le reste du document HTML.
Si l’analyseur rencontre la balise <script> avant de rendre le contenu visible, l’affichage du contenu est retardé. Si le fichier JavaScript en cours de chargement n’est pas absolument nécessaire pour présenter le contenu à vos utilisateurs, vous exigez inutilement que vos visiteurs attendent le contenu. Plus la bibliothèque est grande, plus le retard est important. C’est la raison pour laquelle des outils de comparaison des performances de site web tels que Google PageSpeed ou Lighthouse marquent souvent des scripts chargés de manière synchrone.
Les bibliothèques de gestion des balises peuvent rapidement prendre de l’ampleur si vous disposez de nombreuses balises à gérer.

Déploiement asynchrone

Vous pouvez charger n’importe quelle bibliothèque de manière asynchrone en ajoutant un attribut async à la balise <script> . Par exemple :
<script src="example.js" async></script>

Cela indique au navigateur que, lorsque cette balise script est analysée, il doit commencer à charger le fichier JavaScript, mais au lieu d’attendre que la bibliothèque soit chargée et exécutée, il doit continuer à analyser et à effectuer le rendu du reste du document.

Considérations en matière de déploiement asynchrone

Comme décrit ci-dessus, dans le cas des déploiements synchrones, le navigateur suspend l’analyse et le rendu de la page pendant le chargement et l’exécution de la bibliothèque Launch. D’autre part, dans le cas des déploiements asynchrones, le navigateur poursuit l’analyse et le rendu de la page pendant le chargement de la bibliothèque. La variabilité du moment où le chargement de la bibliothèque Launch peut prendre fin par rapport à l’analyse et au rendu de la page doit être prise en compte.
Tout d’abord, puisque le chargement de la bibliothèque Launch peut prendre fin avant ou après l’analyse et l’exécution du bas de la page, vous ne devriez plus appeler _satellite.pageBottom() depuis votre code de page ( _satellite ne sera pas disponible avant le chargement de la bibliothèque). Cela est expliqué dans la section Chargement asynchrone du code intégré à Launch .
Ensuite, le chargement de la bibliothèque Launch peut se terminer avant ou après que l’événement de navigateur DOMContentLoaded (DOM Ready #) soit survenu.
Pour ces deux raisons, il est intéressant de montrer comment les types d’événements Library Loaded (Bibliothèque chargée), Page Bottom (Bas de page), DOM Ready (Prêt pour DOM) et Window Loaded (Fenêtre chargée) provenant de l’extension Core fonctionnent lors du chargement asynchrone d’une bibliothèque Launch.
Supposons que votre propriété Launch contienne les quatre règles suivantes :
  • Règle A : utilise le type d’événement Library Loaded (Bibliothèque chargée).
  • Règle B : utilise le type d’événement Page Bottom (Bas de page).
  • Règle C : utilise le type d’événement DOM Ready (Prêt pour DOM).
  • Règle D : utilise le type d’événement Window Loaded (Fenêtre chargée).
Quel que soit le moment auquel le chargement de la bibliothèque Launch se termine, l’exécution de toutes les règles est garantie, et ce dans l’ordre suivant :
Règle A → Règle B → Règle C → Règle D
Bien que la commande soit toujours appliquée, il se peut que certaines règles soient exécutées immédiatement lorsque le chargement de la bibliothèque Launch se termine, tandis que d’autres peuvent être exécutées ultérieurement. Les actions suivantes se produisent lorsque le chargement de la bibliothèque Launch se termine :
  1. La règle A est exécutée immédiatement.
  2. Si l’événement de navigateur DOMContentLoaded (DOM Ready (Prêt pour DOM)) est déjà survenu, la règle B et la règle C sont exécutées immédiatement. Dans le cas contraire, les règles B et C sont exécutées ultérieurement lorsque l’événement de navigateur DOMContentLoaded survient.
  3. Si l’événement de navigateur load (Window Loaded #) est déjà survenu, la règle D est exécutée immédiatement. Dans le cas contraire, la règle D est exécutée ultérieurement lorsque l’événement de navigateur load survient. Notez que si vous avez installé la bibliothèque Launch conformément aux instructions, le chargement de la bibliothèque Launch se termine toujours avant que l’événement de navigateur load ne se produise.
Lorsque vous appliquez ces principes à votre propre site web, tenez compte des points suivants :
  • Une règle utilisant le type d’événement Library Loaded (Bibliothèque chargée) peut s’exécuter avant que la couche de données ne soit complètement chargée. Cela peut entraîner l’exécution d’actions de règle avec des données manquantes, car les données n’étaient pas encore disponibles sur la page. Ces types de problèmes peuvent être atténués en ajustant la configuration de votre règle. À titre d’exemple, au lieu d’avoir une règle déclenchée par le type d’événement Library Loaded (Bibliothèque chargée), vous pouvez utiliser les types d’événements Custom Event (Événement personnalisé) ou Direct Call (Appel direct) qui sont déclenchés par votre code de page dès la fin du chargement de votre couche de données.
  • Le type d’événement Page Bottom (Bas de page) ne fournit pas spécialement de valeur lorsque la bibliothèque est chargée de manière asynchrone. Prenez plutôt en compte les types d’événements Library Loaded (Bibliothèque chargée), DOM Ready (Prêt pour DOM), Window Loaded (Fenêtre chargée) ou autres.
Si vous constatez que des actions se produisent dans le désordre, il est probable que vous deviez faire face à certains problèmes de délai. Les déploiements qui nécessitent un délai précis peuvent exiger le recours à des récepteurs d’événements ou à des types d’événements Custom Event (Événement personnalisé) ou Direct Call (Appel direct) pour rendre leurs mises en œuvre plus solides et cohérentes.

Chargement asynchrone du code intégré à Launch

Launch propose un bouton d’activation/désactivation permettant d’activer le chargement asynchrone lors de la création d’un code intégré au moment de la configuration d’un environnement . Vous pouvez également configurer vous-même le chargement asynchrone :
  1. Ajoutez un attribut asynchrone à la balise <script> pour charger le script de manière asynchrone.
    Pour le code intégré à Launch, cela revient à modifier ceci :
    <script src="//www.yoururl.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js"></script>
    
    
    en ceci :
    <script src="//www.yoururl.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js" async></script>
    
    
  2. Supprimez le code que vous avez précédemment ajouté au bas de votre balise :
    <script type="text/javascript">_satellite.pageBottom();</script>
    
    
    Ce code indique à Launch que l’analyseur du navigateur a atteint le bas de la page. Étant donné qu’il est probable que Launch n’ait pas été chargé et exécuté avant ce moment, l’invocation de _satellite.pageBottom() entraîne une erreur et un comportement inattendu du type d’événement Page Bottom (Bas de page).