Discourse のコア/プラグイン/テーマでクライアントサイドの作業を行う際は、パフォーマンスへの影響を考慮することが重要です。Google の「Tachometer」プロジェクトは、変更の影響を明確に測定するために使用できる、統計的に厳密なベンチマークツールを提供します。
本質的に、このツールは URL のリストを受け取り、「ラウンドロビン」方式でそれらを読み込みます。ページ読み込みごとに、パフォーマンス測定値をいくつか取得します。数百回/数千回のイテレーションの後、比較表が生成されます。
この「ラウンドロビン」アプローチの優れた点は、測定に対する外部要因の影響を低減するのに役立つことです。
ステップ 1: performance.measure() の追加
ここでのアプローチは、テスト対象によって異なります。しかし、基本的に、Tachometer が読み取るために performance.measure() 値を導入する必要があります。
Discourse の起動とレンダリングにかかる時間を測定したい場合は、組み込みの「discourse-init-to-paint」測定値を使用できます。それ以外の場合は、独自の performance.measure を導入して使用できます。
ブラウザの開発者ツールのパフォーマンスタブを使用して、機能していることを確認できます。
ユーザー操作を必要とするアクティビティ（例：メニューを開く）を測定しようとしている場合は、ページが読み込まれてから 1 秒後にボタンをクリックするように、イニシャライザに次のようなものを追加することで実現できます。
setTimeout(() => document.querySelector(".my-button").click(), 1000);
ステップ 2: テスト対象の URL の特定
まず、Ember アセットがプロダクションモードでビルドされていることを確認してください。これは、サーバーを EMBER_ENV=production で起動することで実現できます。
2 つの異なる URL を取得するには、主に 2 つのアプローチがあります。
変更がフィーチャーフラグで簡単に切り替えられるほど小さい場合は、URL クエリパラメーターに基づいて切り替えるロジックを追加できます。その場合、2 つの URL は次のようになります。
http://localhost:4200?flag=before
http://localhost:4200?flag=after
変更がそれには大きすぎる場合は、Discourse を 2 番目のディレクトリにクローンし、2 番目の Ember-CLI コピーを起動できます。これは、次のようなコマンドを使用して同じ Rails サーバーにプロキシできます。
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
その場合、2 つの URL は次のようになります。
http://localhost:4200
http://localhost:4201
このアプローチを採用する場合は、アプリの両方のコピーに、このガイドのステップ 1 で導入したパフォーマンステレメトリが含まれていることを確認してください。
ステップ 3: Tachometer の設定
これは私の bench.json ファイルで、各ターゲットの 300 サンプルを取得します。
{
"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"
}
]
}
]
}
ステップ 4: ベンチマークの実行
ノイズを減らすために、ワークステーションでの無関係なアクティビティをすべて停止してから、次のようなコマンドでベンチマークを開始します。
npx tachometer@latest --config ./bench.json
完了すると、before/after のパフォーマンスの比較が表示されるはずです。
注意事項
このような実験には常にそうであるように、制限事項を考慮する価値があります。例えば：
-
開発ワークステーションでのパフォーマンスの違いが、他のブラウザ/デバイスでの結果に直接対応するとは限りません
-
Ember-CLI プロキシを介した Discourse の起動プロセスは、プロダクション環境でのプロセスとまったく同じではありません。構造的な変更（例：フレームワークの更新）を行う場合、これは重要になる可能性があります
-
パフォーマンスはアプリケーションの状態（例：レンダリングされているトピックの数）によって変動することが多いため、結果が他の環境で正確に再現されるとは限りません
このドキュメントはバージョン管理されています - 変更の提案は github で行えます。