Lors du développement côté client dans le cœur de Discourse, les plugins ou les thèmes, il est important 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 de performance. 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 selon 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 à Discourse pour démarrer et s’afficher, vous pouvez utiliser la mesure intégrée « discourse-init-to-paint ». Pour tout autre cas, 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 une seconde après le chargement de la page :
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Étape 2 : Identifier les URL pour le test
D’abord, assurez-vous que vous construisez 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 par un drapeau fonctionnel (feature flag), vous pouvez 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:3000?flag=before
http://localhost:3000?flag=after
Si la modification est trop importante pour cela, vous pouvez créer un worktree git et lancer une deuxième copie de rails à partir de celui-ci sur un autre port :
git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
Les deux copies partagent la même base de données et le même Redis, assurez-vous donc qu’aucune des branches n’a de migrations que l’autre n’a pas.
Et vos deux URL seraient alors :
http://localhost:3000
http://localhost:3001
Si vous adoptez 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 toute activité non liée sur votre poste de travail, puis lancez le benchmark avec une commande comme :
pnpx tachometer --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 ne se traduisent pas nécessairement directement sur d’autres navigateurs/appareils.
-
Le processus de démarrage de Discourse en mode développement 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 ne sont peut-être pas exactement reproductibles dans d’autres environnements.
Ce document est sous contrôle de version - suggérez des modifications sur github.