Utiliser le « tachymètre » de Google pour mesurer les variations de performance JS dans Discourse

Lors du développement côté client dans le cœur de Discourse, les plugins ou les thèmes, il est essentiel de prendre en compte l’impact sur les performances. Le projet « Tachometer » de Google fournit un outil de benchmarking statistiquement rigoureux que nous pouvons utiliser pour mesurer de manière définitive l’effet des modifications.

En substance, cet outil prend une liste d’URL et les charge selon une méthode « round-robin ». Pour chaque chargement de page, il effectue une mesure des performances. Après des centaines ou des milliers d’itérations, il génère un tableau comparatif.

La beauté de cette approche « round-robin » est qu’elle aide à 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() pour que Tachometer puisse la lire.

Si vous souhaitez mesurer le temps nécessaire pour que Discourse démarre et s’affiche, 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 Performance dans les outils de développement de votre navigateur :

Si vous essayez de mesurer une activité qui nécessite une interaction utilisateur (par exemple, l’ouverture d’un menu), vous pouvez 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 pour les tests

Tout d’abord, assurez-vous de construire 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 via un drapeau de fonctionnalité (feature flag), vous pouvez ajouter une logique pour la basculer en fonction d’un paramètre de requête d’URL. Ensuite, vos deux URL pourraient être :

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

Si la modification est trop importante pour cela, vous pouvez cloner Discourse dans un deuxième répertoire et lancer une deuxième copie de rails.

EMBER_ENV=production UNICORN_PORT=3001 bin/dev

Et ensuite, vos deux URL seraient :

http://localhost:3000
http://localhost:3001

Si vous suivez cette approche, assurez-vous que les deux copies de l’application ont 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:3000",
          "name": "before"
        },
        {
          "url": "http://localhost:3001",
          "name": "after"
        }
      ]
    }
  ]
}

Étape 4 : Lancer le benchmark

Pour réduire le bruit, arrêtez toutes les activités non liées sur votre poste de travail, puis lancez le benchmark avec une commande comme celle-ci :

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

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

Limites

Comme pour toute expérience de ce type, il est utile de considérer les limitations. Par exemple :

  • Les différences de performances sur votre poste de développement peuvent ne pas se traduire 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. Cela peut être important lors de modifications structurelles (par exemple, des mises à jour de framework).

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


Ce document est sous contrôle de version - suggérez des modifications sur github.

17 « J'aime »