> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/fonctionnalites/sources/sources-catalog/web/containers/best-practices/performance-optimization.md). # Optimisation des performances La performance sur site d’un site web est l’un des KPI les plus importants pour le SEO. C’est pourquoi de plus en plus d’entreprises s’intéressent à l’optimisation de la performance sur site via TagCommander. Cet article rassemble des sujets pour rendre TagCommander lui-même plus performant. ## Réduire la taille des fichiers des Web Containers Commanders Act ### **Supprimer les propriétés de Data Layer inutilisées** Chaque propriété de Data Layer configurée dans les options de l’interface crée un peu de code JavaScript dans le Container pour initialiser la variable au cas où elle n’était pas présente dans le Data Layer sur site `tc_vars`. La suppression des variables inutilisées/anciennes rendra donc le fichier du Container un peu plus petit (et, comme effet secondaire, améliorera aussi la transparence de la configuration du Container). ### **Supprimer les variables internes inutilisées** Chaque variable interne configurée dans les options de l’interface est un extrait de JavaScript, donc la suppression des variables internes permet de réduire la taille d’un fichier Container. Cela peut se faire en supprimant les variables internes inutilisées et aussi en spécifiant quelles variables sont utilisées dans quel Container. C’est particulièrement important pour les clients ayant un `` et `` Container et pour les clients qui ont plusieurs Containers pour différents sites web. ### **Ne vous répétez pas** Parfois, la même fonctionnalité d’un tag est dupliquée dans plusieurs tags. Dans ces cas, il est possible d’économiser une bonne quantité de code JavaScript et de réduire la taille du fichier Container en factorisant la fonctionnalité commune dans une variable interne ou dans un tag commun. Par exemple, de nombreux tags se composent de deux parties. Une partie charge une bibliothèque JavaScript externe du fournisseur et une partie envoie l’événement réel au fournisseur. Par défaut, le code qui charge la bibliothèque JavaScript est souvent dupliqué dans chaque événement. Donc extraire la première partie dans un *tag de base* permet de supprimer le JavaScript dupliqué. ### **Fractionner les grands fichiers Container** De nombreux Tags sont déployés sur chaque page d’un site web même s’ils ne sont pas déclenchés. Par exemple, de nombreux fournisseurs ont des Tags séparés pour collecter des informations et un seul Tag qui est diffusé sur la page de confirmation. Il peut donc être pertinent de scinder le Container en deux parties — une pour les pages catalogue et une pour les pages funnel. Les deux Containers sont ainsi plus petits, car ils n’incluent que les Tags pertinents pour leur partie du site web. Veillez également à n’implémenter des Tags que dans `` le Container si nécessaire, car ces Tags ont généralement un impact plus important sur la performance de la page que les Tags dans le Container \`\\`. ### **Mettre en place une configuration hybride du Web Container** Une configuration hybride permet de transférer l’impact sur la performance sur site vers l’infrastructure Server-Side de Commanders Act. {% hint style="danger" %} Pour éviter tout impact négatif sur les performances de votre site web, un Web Container ne devrait jamais dépasser 500 Mo. {% endhint %} ## Rendre Commanders Act asynchrone ### **Charger le Container de manière asynchrone** De nombreux crawlers de vitesse de page sur site mesurent le temps jusqu’à l’événement du navigateur *onload*. Donc, si l’équipe IT charge le Web Container de manière asynchrone sur l’ *onload* événement, il est possible de rendre le fichier du Web Container *invisible* pour certaines métriques de vitesse de page. Cela n’est généralement possible que pour `` des Containers `` Les Containers doivent être exécutés de manière synchrone pour les Tags d’A/B testing et de personnalisation qui ont un impact sur le contenu visuel du site web. {% hint style="danger" %} Tags dans un Container asynchrone `` qui utilisent un mode synchrone `document.write` (p. ex. certaines solutions publicitaires) casseront le site web si le Container est chargé de manière asynchrone. Ces Tags doivent être évités si un Container est installé de manière asynchrone. {% endhint %} ### **Charger les Tags de manière asynchrone** JavaScript est, pour l’essentiel, un langage mono-thread, ce qui signifie qu’un JavaScript de longue durée (comme un long processus dans une boucle) peut bloquer d’autres parties du JavaScript qui devraient être exécutées immédiatement. Il est possible de placer un JavaScript de longue durée sur une *pile d’exécution différée à priorité inférieure* en l’enveloppant dans un setTimeout avec un délai de 0 ms. ```javascript setTimeout(function() { // Mon code de tag }, 0); ``` Cela doit être testé avec chaque tag individuel, car certains pourraient ne pas être compatibles avec cette approche. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.commandersact.com/fr/fonctionnalites/sources/sources-catalog/web/containers/best-practices/performance-optimization.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.