Utilisation du 'tachomètre' de Google pour mesurer les changements de performance JS dans Discourse

Documentation Guides pour les développeurs
1

Lorsque vous travaillez sur le code côté client dans Discourse core/plugins/themes, il est important de prendre en compte l’impact sur les performances. Le projet ‘Tachometer’ de Google fournit un outil d’évaluation comparative statistiquement rigoureux que nous pouvons utiliser pour mesurer de manière définitive l’effet des changements.

Essentiellement, cet outil prend une liste d’URL et les charge de manière ‘circulaire’. Pour chaque chargement de page, il effectue une mesure de performance. Après des centaines/milliers d’itérations, il produit un tableau comparatif.

La beauté de cette approche ‘circulaire’ est qu’elle permet de réduire l’impact des facteurs externes sur les mesures.

Étape 1 : Ajouter performance.measure()

L’approche variera en fonction de ce que vous testez. Mais fondamentalement : vous devez introduire une valeur performance.measure() que Tachometer pourra lire.

Si vous souhaitez mesurer le temps nécessaire au démarrage et au rendu de Discourse, vous pouvez utiliser la mesure intégrée “discourse-init-to-paint”. Pour tout le reste, vous pouvez introduire votre propre performance.measure et l’utiliser.

Vous pouvez vérifier que cela fonctionne en utilisant l’onglet des performances dans les outils de développement de votre navigateur :

SCR-20240529-rlhj
SCR-20240529-rlhj1234×176 9.92 KB

Si vous essayez de mesurer une activité qui nécessite une interaction utilisateur (par exemple, ouvrir un menu), vous pourriez y parvenir en ajoutant quelque chose comme ceci dans un initialiseur pour cliquer sur le bouton 1 seconde après le chargement de la page :

setTimeout(() => document.querySelector(".my-button").click(), 1000);

Étape 2 : Identifier les URL à tester

Tout d’abord, assurez-vous que vous compilez les assets Ember en mode production. Cela peut être réalisé en lançant le serveur avec EMBER_ENV=production.

Pour obtenir deux URL différentes, il existe deux approches principales :

Si votre modification est suffisamment petite pour être facilement activée/désactivée par un indicateur de fonctionnalité, vous pourriez ajouter une logique pour la basculer en fonction d’un paramètre de requête d’URL. Vos deux URL pourraient alors être :

http://localhost:4200?flag=before
http://localhost:4200?flag=after

Si la modification est trop importante pour cela, vous pourriez cloner Discourse dans un second répertoire et lancer une seconde copie d’ember-cli. Elle peut être proxifiée vers le même serveur Rails en utilisant une commande comme :

EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000

Et alors vos deux URL seraient :

http://localhost:4200
http://localhost:4201

Si vous adoptez cette approche, assurez-vous que les deux copies de l’application disposent de la télémétrie de performance que vous avez introduite à l’étape 1 de ce guide.

Étape 3 : Configurer Tachometer

Voici mon fichier bench.json, qui prendra 300 échantillons de chaque cible :

{
  "timeout": 5,
  "sampleSize": 300,
  "benchmarks": [
    {
      "measurement": {
        "mode": "performance",
        "entryName": "discourse-init-to-paint"
      },
      "expand": [
        {
          "url": "http://localhost:4200",
          "name": "before"
        },
        {
          "url": "http://localhost:4201",
          "name": "after"
        }
      ]
    }
  ]
}

Étape 4 : Exécuter l’évaluation comparative

Pour réduire le bruit, arrêtez toute activité non liée sur votre poste de travail, puis lancez l’évaluation comparative avec une commande comme :

npx tachometer@latest --config ./bench.json

Une fois terminé, vous devriez voir une comparaison des performances avant/après.

image
image1500×412 98.9 KB

Mises en garde

Comme pour toute expérience de ce type, il convient de tenir compte des limitations. Par exemple :

  • Les différences de performances sur votre poste de développement peuvent ne pas se refléter directement sur d’autres navigateurs/appareils.

  • Le processus de démarrage de Discourse via le proxy Ember-CLI n’est pas exactement le même qu’en production. Lors de modifications structurelles (par exemple, mises à jour de frameworks), cela peut être important.

  • Les performances varient souvent en fonction de l’état de l’application (par exemple, le nombre de sujets affichés), de sorte que vos résultats peuvent ne pas être exactement reproductibles dans d’autres environnements.

Ce document est contrôlé par version - suggérez des modifications sur github.

17 « J'aime »