パフォーマンス

エディターアプリケーションにとってパフォーマンスは重要な要素です。ブロックエディターも例外ではありません。

リリースと開発サイクルの中でブロックエディターのパフォーマンスを維持するため、後述する「パフォーマンスベンチマークジョブ」を実行して、いくつかの重要な指標を監視しています。

メインの重要な指標には次のようなものがあります。

• ロード時間: エディターページの読み込み時間。これにはサーバーが応答するまでの時間、最初の描画までの時間 (FP)、最初の DOM コンテンツの描画 (FCP)、DOM コンテンツのロード完了、ロード完了、最初のブロックのレンダーが含まれます (投稿とサイトの両方)。
• タイプ時間: エディター上で文字を入力した際にブラウザが応答するまでの時間
• ブロックの選択時間： ユーザーがブロックを選択してから、ブラウザが反応するまでの時間。ちなみにブロックの挿入はブロックの選択と同等のため、ブロックの選択時間を監視することで両方の指標をカバーできます。

データモジュールの非同期モード

WordPress パッケージのデータモジュールとブロックエディターは Redux をベースとしています。したがって、ステートはグローバルに保持され、変更があるたびに、ステートに依存するコンポーネント (UI) が更新される可能性があります。

長い投稿記事のように、レンダーされるコンポーネントの数が増えると、グローバルステートがすべてのコンポーネントへのイベントディスパッチャとして機能するため、パフォーマンスが低下します。これは Redux アプリケーションではよくある落とし穴で、Gutenberg ではデータモジュールの非同期モードを使用することで、この問題を解決しています。

非同期モードでは、React コンポーネントツリーの一部の更新や再レンダーを、同期的に実行するか、非同期的に実行するかを決定できます。

ここでいう非同期レンダリングとは、グローバルステートで変化が起きたた際、サブスクライバー（コンポーネント）が同期的に呼び出されるのではなく、ブラウザがアイドル状態になるのを待って、React ツリーの更新を実行することを意味します。

「あるブロックを編集している場合、そのブロックの更新が、コンテンツの他の部分に影響を与えることは非常にまれである」という考えに基づき、ブロックエディターキャンバスは、選択したブロックのみを同期モードでレンダリングし、残りのブロックはすべて非同期でレンダリングします。これにより、投稿記事が長くなってもエディターの応答パフォーマンスは保たれます。

複数のブランチ、タグ、コミット間のパフォーマンスを比較するツールが提供されています。これは以下のようにローカルで実行できます: ./bin/plugin/cli.js perf [branches]。たとえば、

./bin/plugin/cli.js perf trunk v8.1.0 v8.0.0

最も正確な結果を得るには、テストを実行する際に、まったく同じバージョンのテストと環境 (テーマ等) を使用することが重要です。ブラVンチ間で異なるのは、Gutenberg プラグインのバージョン (または、プラグインのビルドに使用するブランチ) だけであるべきです。

そのため、コマンドはまず次のようなフォルダ構造を用意します。

│
├── tests/packages/e2e-tests/specs/performance/*
|   実行される実際のパフォーマンステスト
│
├── tests/test/emptytheme
|   テスト環境で使用されるテーマ (サイトエディター)
│
│── envs/branch1/.wp-env.json
│   branch1 の wp-env 構成ファイル (すべての他のブランチと、プラグインフォルダを除いて、同じ)
│── envs/branch1/plugin
│   branch1 の Gutenberg プラグインの構築されたクローン (git checkout branch1)
│
└── envs/branchX
    perf-envs/branch1 の構造は、すべての他のブランチのために重複している。

上のディレクトリ構造ができたら、パフォーマンス測定用のコマンドは、パフォーマンステストスイート（投稿エディターとサイトエディター）をループし、以下を実行します。

1. branch1 の環境を開始
2. 現行のスイートでパフォーマンステストを実行
3. branch1 の環境を停止
4. 1〜3のステップをすべての他のブランチで繰り返す
5. 現行スイートのすべてのパフォーマンス指標の中央地を算出

すべてのテストスイートの実行が完了すると、サマリーレポートが出力されます。

各コミットのパフォーマンス結果は codevitals にプッシュされ、Gutenberg ダッシュボードで参照できます。表示されるグラフから、ある指標の時間的な変化を追跡できます。

したがって、計算される指標の安定性の確認は非常に重要です。つまり、同じコードと同じ環境で同じテストを2回実行すれば、近い結果が得られる必要があります。

私たちのパフォーマンスジョブは GitHub CI を実行しているため、同じジョブを2回実行したときに得られる数値の一貫性を信頼できません。GitHub CI は、例えば時間の経過とともに異なる CPU やメモリリソースを割り当てるためです。この問題の軽減のため、trunk ブランチでパフォーマンスジョブを実行するたびに、現在のコミットのパフォーマンスを固定した参照コミットハッシュと比較します。これにより、環境の変化によらず、現在のコミットと参照コミットの相対的な差を一貫して追跡できます。

Gutenberg は2つの WordPress バージョンしかサポートしていないため、以下の2点でパフォーマンスジョブに影響を与えます。

• パフォーマンスジョブの実行に使用されるベースの WordPress バージョンは、Gutenberg がサポートする最小バージョンが変更されたときに更新する必要があります。ここではプラグインの readme.txt ファイルの Tested up to フラグに依存します。このフラグが変更されるたびに、パフォーマンスジョブに使用するバージョンも変更されます。
• パフォーマンスジョブに使用される WordPress のバージョンを更新すると、パフォーマンステストの安定性のために使用される参照コミットと WordPress のバージョンとで互換性がなくなる可能性が高くなります。そのため、readme.txt の Tested up to フラグが更新されるたびに、.github/workflows/performance.yml で使用される参照コミットも更新する必要があります。

選択する新しい参照コミットハッシュは、以下の要件を満たす必要があります。

• “Tested up to” フラグで使用されている新しい WordPress バージョンと互換性があること
• 既存のすべてのメ指標について、”codevitals.run” で追跡済みであること

コミットを選択する簡単な方法は、trunk 上の最近のコミットで、パフォーマンスジョブに合格したものを選ぶことです。

• Journey towards a performant editor (高性能エディターへの道)

原文

最終更新日: 2024年7月14日