Skip to main content
Vous pouvez utiliser divers outils d’analyse de performance pour évaluer l’efficacité de votre site. Consultez les recommandations de Kameleoon ci-dessous pour identifier et mettre en œuvre les améliorations nécessaires en fonction de vos résultats.

​
Vérifier quand le snippet se charge

Vérifiez le timing du tag engine.js (précédemment appelé kameleoon.js) après le rechargement de la page, comme illustré dans la capture d’écran ci-dessous. Si la métrique started at est supérieure à 1 seconde, placez le script Kameleoon plus haut dans la balise <head> et définissez fetchpriority="high". Ces modifications garantissent que le script Kameleoon se charge en moins de 1 seconde.
Lorsque la page se charge pour la première fois, le script Kameleoon prend plus de temps, généralement moins de 60 millisecondes, car le navigateur le télécharge directement depuis le CDN. Lors des rechargements ultérieurs, le navigateur charge le script depuis le cache.
performance

​
Vérifier le score de performance via l’extension Chrome de Kameleoon

Selon le Score de performance affiché dans l’extension (voir capture d’écran ci-dessous), effectuez une ou plusieurs de ces actions :
  • Arrêtez toutes les expériences ou personnalisations qui sont en cours depuis plus de 2 mois et transférez le code dans le code source de votre site en fonction du résultat de l’expérience ou de la personnalisation.
  • Archivez toutes les expériences ou personnalisations que vous avez arrêtées.
  • Supprimez tous les objectifs inutilisés, y compris leur code s’il s’agit d’objectifs personnalisés.
  • Supprimez tous les segments inutilisés.
  • Supprimez toutes les données personnalisées inutilisées.
  • Optimisez le script personnalisé global pour supprimer tout le code inutilisé/déprécié.
Pour plus de détails, consultez cet article pour obtenir de l’aide sur l’extension Kameleoon Debug Assistant.
chrome

​
Suivre la performance avec PageSpeed insights

L’onglet Performance dans les outils de développement du navigateur aide à analyser les performances d’une page web en enregistrant et en visualisant des données clés telles que les temps de chargement de page, l’utilisation de la mémoire et la consommation des ressources. Il fournit des informations détaillées sur les processus de rendu, de scripting et de mise en page sous forme de chronologies et de diagrammes en flammes. Analyser ces informations peut aider à identifier les goulets d’étranglement, les scripts à chargement lent et autres facteurs affectant la vitesse. Google PageSpeed Insights analyse le contenu d’une page web et fournit des informations sur les performances ainsi que des suggestions d’améliorations. Il attribue un score et des suggestions basés sur les Core Web Vitals, tels que le temps de chargement, l’interactivité et la stabilité visuelle. Le rapport présente ses résultats avec des métriques telles que “FCP”, “LCP”, “INP” et “CLS”.
tab
tab2

​
First Contentful Paint

Le First Contentful Paint (FCP) mesure le temps entre le début du chargement de la page et le moment où le navigateur affiche le contenu de la page à l’écran.
  • Impact possible : L’anti-flicker pourrait avoir un impact sur le FCP puisqu’il retarde l’affichage du premier élément sur la page
  • Action : Dans la plupart des cas, supprimez le code anti-flicker et utilisez plutôt le tag asynchrone sans anti-flicker. Sans anti-flicker, les visiteurs peuvent voir la page d’origine avant l’apparition d’une variation, ce qui peut réduire la précision de vos résultats.

​
Largest Contentful Paint

Le Largest Contentful Paint (LCP) mesure la vitesse de chargement perçue. Il marque le moment dans la chronologie de chargement de la page où le contenu principal de la page a probablement été chargé.
  • Impact possible : L’anti-flicker pourrait avoir un impact sur le LCP puisqu’il retarde l’affichage du plus grand élément sur la page
  • Action : Identique au FCP.

​
Interaction to Next Paint

L’Interaction to Next Paint (INP) mesure la réactivité de la page. Pour offrir une expérience utilisateur positive, visez un INP inférieur à 200 millisecondes.
  • Impact possible : Si Kameleoon se charge tôt, il ne devrait pas y avoir d’impact négatif. Cependant, les tests qui modifient le comportement d’une interaction peuvent affecter cette métrique.
  • Action : Vous pouvez utiliser l’extension Chrome Kameleoon ou le code ci-dessous dans la console pour vérifier quelles sont les expériences / personnalisations actives sur la page concernée afin de trouver la source possible de l’impact. L’exemple de snippet de code suivant illustre comment y parvenir :

​
Cumulative Layout Shift

Le Cumulative Layout Shift (CLS) mesure le plus grand changement de position d’un élément au cours du cycle de vie de la page. Notez que les décalages de mise en page ne se produisent que lorsque des éléments existants modifient leur position de départ. Si un nouvel élément est ajouté au DOM, ou si un élément existant change de taille, cela ne compte pas comme un changement de mise en page, tant que le changement n’entraîne pas de modification de la position de départ d’autres éléments visibles.
  • Impact possible : Le tag Kameleoon n’a aucun impact sur cet indice. Les expériences / personnalisations, en revanche, peuvent avoir un impact négatif si elles entraînent un changement dans la position de départ d’un élément.
  • Action : Identique à l’INP.

​
Speed Index (métrique ContentSquare)

Le Speed Index mesure le moment où le navigateur affiche la majorité des éléments graphiques de la fenêtre d’affichage initiale.
  • Impact possible : L’anti-flicker pourrait avoir un impact sur le Speed Index puisqu’il peut retarder l’affichage des éléments de la fenêtre d’affichage initiale. De plus, si vous exécutez des expériences/personnalisations qui apportent des modifications en haut de la page, le Speed Index sera négativement impacté (il augmentera).
  • Actions : Identique au FCP et à l’INP.

​
Caractéristiques du script Kameleoon en un coup d’œil

  • Snippet asynchrone : Kameleoon charge son script de manière asynchrone depuis un CDN fiable (Cloudflare) pour garantir un premier chargement de page non bloquant et utilise la mise en cache du navigateur pour des chargements de page ultérieurs plus rapides. Kameleoon maintient un Service Level Agreement (SLA) supérieur à 99,99 %.
Assurez-vous d’avoir l’attribut async dans le script Kameleoon installé sur votre site. Consultez le snippet ci-dessous :
  • Petite taille du script : Le fichier d’application de Kameleoon, créé avec TypeScript, a une taille de seulement 29 Ko (compressé avec Brotli), ce qui minimise le temps de chargement à la première page.
  • Approche de prétraitement : Le script Kameleoon est généré uniquement à partir des composants nécessaires à votre configuration spécifique, en fonction des fonctionnalités et options que vous utilisez.
  • Moteur anti-clignotement unique : Le moteur de Kameleoon capture les événements du DOM en temps réel et modifie l’affichage des composants impliqués dans une variation d’expérience avant qu’ils ne soient entièrement rendus.
  • Appels réseau réduits : Kameleoon regroupe plusieurs événements de suivi dans un seul appel beacon, réduisant ainsi considérablement le nombre total d’appels réseau requis.
  • Chargement unique du script : Contrairement à d’autres plateformes qui nécessitent plusieurs fichiers, Kameleoon charge un seul script consolidé, ce qui réduit le nombre de requêtes HTTP.
  • Chargement différé des expériences : Kameleoon vous permet de sélectionner quelles expériences inclure dans le fichier d’application, engine.js (précédemment appelé kameleoon.js) au moment du premier chargement de page, au cas par cas, et de différer les expériences non essentielles après le premier chargement.
  • Mise à jour en temps réel : Pour fournir des mises à jour plus fréquentes sans être ralenti par la mise en cache du navigateur, la fonctionnalité Live Update Experiments de Kameleoon rafraîchit toute expérience taguée “LIVE-UPDATE” en moins d’une minute.

​
Bonnes pratiques pour la performance à long terme

Au-delà de l’analyse des performances, suivez les bonnes pratiques de Kameleoon pour garantir des expériences durables et scalables :

​
FAQ

Non. Le script Kameleoon utilise une technologie de pointe pour s’exécuter de manière asynchrone (lorsque le snippet d’installation asynchrone est utilisé) et reste entièrement mis en cache par le navigateur pendant 90 minutes. Il ne bloque jamais le chargement de la page, même lors de rares incidents CDN (disponibilité de 99,99 %). En moyenne, le script se charge en moins de 70 ms sur une connexion 4G ou des conditions réseau plus rapides.Kameleoon réduit encore l’impact grâce à des techniques de compression avancées, combinant TypeScript et Brotli, ce qui donne une taille de script de base de seulement 28,4 Ko.

​
Livraison CDN et évolutivité

Le script engine.js est servi via le CDN Cloudflare, ce qui signifie qu’il évolue automatiquement quel que soit le volume de trafic de votre site web. Il n’y a aucun problème de chargement ou de lenteur, quel que soit le niveau de trafic—le réseau mondial de Cloudflare gère la diffusion, de sorte que ni les pics ni un trafic élevé soutenu n’affectent les performances du script pour vos visiteurs.

​
Mise en cache

Par défaut, le navigateur met en cache engine.js pendant 90 minutes, ce qui minimise les temps de chargement répétés pour les visiteurs récurrents. Si votre cas d’usage nécessite une durée de cache plus courte, elle peut être réduite, jusqu’à seulement 1 minute, sur demande. Contactez le support Kameleoon pour ajuster ce paramètre pour votre compte.

​
Considérations importantes

La taille du script peut augmenter en fonction du nombre d’expériences que vous exécutez et de leur contenu (CSS/JavaScript).Pour les expériences ou campagnes de personnalisation qui n’ont pas besoin de se charger immédiatement, utilisez le tag « DELAYED ». Ce tag retarde le chargement des expériences non essentielles après le premier chargement de la page. Kameleoon gère ces expériences intelligemment : il ne télécharge la configuration qu’après 10 secondes d’inactivité ou lorsqu’un visiteur est ciblé et alloué à une variation autre que la version de contrôle. Cette approche garantit un impact minimal sur les performances de chargement tout en offrant une fonctionnalité complète pour les expériences prioritaires.

​
Suivi des requêtes et limites de débit

Kameleoon regroupe les événements de suivi dans une seule requête au lieu d’envoyer une requête par événement, ce qui limite le nombre d’appels réseau. Pour savoir comment engine.js met en file d’attente et envoie les événements, consultez Flux de code : suivi. Pour savoir comment les SDK regroupent les requêtes et comment la Data API applique ses limites de débit, consultez Limites de débit.

​
Limites de débit de la Data API

Kameleoon applique des limites de débit à la Data API pour protéger la fiabilité du service. Les limites sont basées sur votre nombre contractuel de visiteurs uniques mensuels (MUV) et l’adresse IP du demandeur. Si vous dépassez ces limites, l’API renvoie HTTP 429.Ces limites s’appliquent à toutes les requêtes qui atteignent la Data API, notamment les appels de suivi qu’engine.js envoie automatiquement et les requêtes de suivi regroupées que les SDK Feature Experimentation envoient. Dans les environnements où de nombreux visiteurs partagent une seule adresse IP (comme les bureaux ou les réseaux d’entreprise), les limites basées sur l’IP peuvent s’appliquer même si vos MUV totaux restent dans les limites du contrat.Kameleoon détecte automatiquement le trafic de bots connus et l’exclut du calcul de ces limites de débit. Les requêtes identifiées comme provenant de bots ne comptent pas dans les limites décrites ci-dessus.Pour les intégrations côté serveur, vous pouvez lever les limites basées sur l’IP en authentifiant vos requêtes. Si votre cas d’utilisation nécessite des limites plus élevées, contactez le support Kameleoon pour discuter des options.Les limites de débit s’appliquent à l’ensemble de votre compte client, et non à des projets individuels. Si un projet génère un nombre excessif de requêtes (par exemple parce qu’une implémentation défectueuse crée une boucle qui envoie des événements de données personnalisées de manière répétée), ce projet consomme la limite partagée du compte et peut provoquer des erreurs HTTP 429 dans tous vos autres projets.Pour identifier le projet qui génère un trafic inattendu, utilisez la page Live events (Insights > Live events). Sélectionnez chaque projet tour à tour et comparez le nombre d’événements de la dernière heure ou des dernières 24 heures avec le volume attendu. Un projet générant beaucoup plus d’événements que ne le justifie son volume de visiteurs (par exemple, des dizaines de millions d’événements pour un contrat de 100 000 MUV) est probablement la source du problème. Filtrez les événements par type pour identifier la cause : les événements de données personnalisées sont les plus souvent responsables, souvent parce qu’une boucle mal configurée envoie la même variable de données personnalisées, ou toutes les variables de données personnalisées, à chaque chargement de page.

​
Évolutivité de la plateforme

La plateforme Kameleoon utilise la mise à l’échelle horizontale, une infrastructure à mise à l’échelle automatique, la répartition de charge, et des tests de charge et de stress réguliers. Pour plus de détails, voir Comment la plateforme Kameleoon prend-elle en charge l’évolutivité et l’élasticité ?.
Oui, vous pouvez différer les expériences non essentielles après le premier chargement de page. Pour différer une expérience, ajoutez le tag DELAYED aux expériences que vous souhaitez reporter. Pour plus d’informations, consultez la documentation sur la gestion des tags.Kameleoon gère intelligemment les expériences taguées « DELAYED ». Il ne télécharge la configuration qu’après 10 secondes d’inactivité ou lorsque le visiteur est ciblé et alloué à une variation autre que la version de contrôle. Concentrez-vous sur la fourniture de la meilleure expérience utilisateur en différant les tests gourmands en ressources.
La plateforme Kameleoon offre une évolutivité et une élasticité élevées, garantissant des performances optimales à mesure que les volumes de données augmentent. La plateforme gère une charge moyenne de 20 000 requêtes par seconde avec des pics jusqu’à 100 000 requêtes. Les facteurs clés incluent :
  • Architecture évolutive : L’architecture distribuée et modulaire permet un dimensionnement horizontal.
  • Infrastructure à mise à l’échelle automatique : L’infrastructure basée sur le cloud met à l’échelle automatiquement les ressources de calcul.
  • Répartition de charge : Des techniques avancées répartissent uniformément le trafic entre les serveurs.
  • Ingestion et traitement des données : Des API robustes et un broker de données gèrent efficacement de grands volumes de données.
  • Tests d’évolutivité : Les tests réguliers de charge et de stress garantissent que le système gère des conditions extrêmes.
  • Stockage de données élastique : Le stockage à plusieurs niveaux permet un accès rapide aux données et une évolutivité à long terme.