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
完了すると、変更前後のパフォーマンスの比較が表示されるはずです。
注意事項
このような実験には、限界を考慮する価値があります。たとえば、次のとおりです。
-
開発ワークステーションでのパフォーマンスの違いは、他のブラウザ/デバイスに直接マッピングされない場合があります。
-
Ember-CLI プロキシを介した Discourse の起動プロセスは、本番環境とは正確には同じではありません。構造的な変更（例: フレームワークの更新）を行う場合、これは重要になる可能性があります。
-
パフォーマンスは、アプリケーションの状態（例: レンダリングされるトピックの数）によって変動することが多いため、結果が他の環境で正確に再現可能ではない場合があります。
このドキュメントはバージョン管理されています。変更は GitHub で提案してください。