パフォーマンス

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

指標

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

ロード時間: エディターページの読み込み時間 タイプ時間: エディター上で文字を入力した際にブラウザが応答するまでの時間 **ブロックの選択時間:**ユーザーがブロックを選択してから、ブラウザが反応するまでの時間。ちなみに、ブロックの挿入はブロックの選択と同等のため、ブロックの選択時間を監視することで、両方の指標をカバーできます。

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

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

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

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

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

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

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

さらに学習するには

原文

最終更新日: