メトリクス

ブロックエディタがリリースや開発を通じてパフォーマンスを維持するために、パフォーマンスベンチマークジョブを使用していくつかの重要なメトリクスを監視しています。

主な重要なメトリクスは次のとおりです：

  • 読み込み時間： エディタページを読み込むのにかかる時間。これには、サーバーが応答するのにかかる時間、最初のペイント、最初のコンテンツペイント、DOMコンテンツの読み込み完了、読み込み完了、最初のブロックレンダリング（投稿とサイトの両方）が含まれます。
  • タイピング時間： エディタでタイピング中にブラウザが応答するのにかかる時間。
  • ブロック選択時間： ユーザーがブロックを選択した後、ブラウザが応答するのにかかる時間。（ブロックを挿入することはブロックを選択することと同等です。選択を監視することで、両方のメトリクスをカバーできます）。

主要なパフォーマンスの決定と解決策

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

WordPressパッケージとブロックエディタのデータモジュールはReduxに基づいています。これは、状態がグローバルに保持され、変更が発生するたびに、その状態に依存するコンポーネント（UI）が更新されることを意味します。

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

非同期モードは、Reactコンポーネントツリーの一部を同期的または非同期的に更新するかどうかを決定できるというアイデアです。

この文脈での非同期レンダリングは、グローバル状態で変更がトリガーされた場合、サブスクライバー（コンポーネント）が同期的に呼び出されず、代わりにブラウザがアイドル状態になるのを待ってReactツリーの更新を行うことを意味します。

特定のブロックを編集しているとき、そのブロックの更新がコンテンツの他の部分に影響を与えることは非常に稀であるという考えに基づいて、ブロックエディタキャンバスは選択されたブロックのみを同期モードでレンダリングし、残りのブロックは非同期でレンダリングされます。これにより、投稿が増えるにつれてエディタが応答性を保つことが保証されます。

パフォーマンスベンチマークジョブ

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

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

最も正確な結果を得るためには、テストを実行する際に、テストと環境（テーマなど）の正確に同じバージョンを使用することが重要です。ブランチ間で異なる必要があるのは、Gutenbergプラグインのバージョン（またはプラグインを構築するために使用されるブランチ）だけです。

これを達成するために、コマンドは最初に次のフォルダ構造を準備します： 

  1. │
  2. ├── tests/packages/e2e-tests/specs/performance/*
  3. |   The actual performance tests to run
  4. │
  5. ├── tests/test/emptytheme
  6. |   The theme used for the tests environment. (site editor)
  7. │
  8. │── envs/branch1/.wp-env.json
  9. │   The wp-env config file for branch1 (similar to all other branches except the plugin folder).
  10. │── envs/branch1/plugin
  11. │   A built clone of the Gutenberg plugin for branch1 (git checkout branch1)
  12. │
  13. └── envs/branchX
  14.    The structure of perf-envs/branch1 is duplicated for all other branches.

上記のディレクトリが整ったら、パフォーマンスコマンドはパフォーマンステストスイート（投稿エディタとサイトエディタ）をループし、次のことを行います：

  • 1. branch1 のために環境を開始
  • 2. 現在のスイートのパフォーマンステストを実行
  • 3. branch1 のために環境を停止
  • 4. 他のすべてのブランチに対して最初の3つのステップを繰り返す
  • 5. 現在のスイートのすべてのパフォーマンスメトリクスの中央値を計算します。

すべてのテストスイートが実行されると、要約レポートが印刷されます。

CodeVitalsを使用したパフォーマンスの追跡

各コミットのパフォーマンス結果はcodevitalsにプッシュされ、Gutenbergダッシュボードで見ることができます。グラフは、特定のメトリクスの時間経過に伴う進化を追跡することを可能にします。

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

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

参照コミットの更新

Gutenbergは2つのWPバージョンのみをサポートしており、これはパフォーマンスジョブに2つの方法で影響します：

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

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

  • 「テスト済みまで」フラグで使用される新しいWPバージョンと互換性があること。
  • すべての既存のメトリクスについて「codevitals.run」で既に追跡されていること。

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

さらに進む