パフォーマンス

Topics

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

指標

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

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

Top ↑

キーパフォーマンスの決定とソリューション

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

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

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

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

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

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

Top ↑

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

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

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

最も正確な結果を得るには、テストを実行する際に、全く同じバージョンのテストとテーマなどの環境を使用することが重要です。ブランチ間で異なるのは、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 の構造は、すべての他のブランチのために重複している。

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

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

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

Top ↑

さらに学習するには

原文

最終更新日: