Bad Bunch アプリケーションのパフォーマンス問題を特定する

学習の目的

この単元を完了すると、次のことができるようになります。

パフォーマンスを調整するためのさまざまな方法を示す。
パフォーマンスモニターを使用して DOM ノードの問題を特定する。

過度に負荷の高いイベントコール

前の単元では、ループ内のコード配置が良くないためにパフォーマンスが悪くなっている Lightning Web コンポーネントをトラブルシューティングしました。ここでは、別の悪い例とそのトラブルシューティング方法を見てみましょう。

Bad Bunch アプリケーションを開いた状態で、[Example 2: Scroll List (例 2: リストをスクロール)] を選択し、ページが完全に読み込まれるのを待ちます。
DevTools の [Performance (パフォーマンス)] パネルで、をクリックしてプロファイルの記録を開始します。
次に、[Scroll This List! (このリストをスクロール!)] の下のリストをスクロールします。

動作が少し遅いか、ぎくしゃくしているように感じると思います。
[Performance (パフォーマンス)] パネルで、[Stop (停止)] をクリックして記録を終了し、データがまとめられるのを待ちます。

[Main (メイン)] セクションを見てください。すべての JavaScript イベントがコールされています。小さな赤い三角形が付いていることがわかります。

Chrome では、赤い三角形を使用して、時間が長くかかりすぎている可能性があることが示されます。
コールスタックを下に移動し、[onScroll] イベントの 1 つをクリックして [Summary (概要)] タブで詳細を取得します。

このイベントは、今回の例のコード、つまり example2_ScrollList.js ファイルにある onScroll メソッドから生じています。正確には行 87 にあります。
[Summary (概要)] パネルで、[example2_ScrollList.js] へのリンクをクリックすると、コードが表示されている [Sources (ソース)] パネルに移動します。

行 82 の li.style.background = ‘#edede’; を見てください。

スクロールするたびにコードでスタイル設定を追加します。これは違う方法で処理するべきです。大きなオーバーヘッドがイベントに発生します。まさにこのような問題に対処するために、tr:nth-child(even)、tr:nth-child(odd) のような CSS (カスケードスタイルシート) 疑似クラスが存在します。CSS アプローチの方が、JavaScript を使用するより常に速くなります。

ここでのもう 1 つの問題は、イベントの起動頻度が多くなりすぎないようにするデバウンス機能がないことです。リスナーをスクロールイベントに追加すると、起動回数がとてつもなく多くなります。そのイベントが負荷の大きい処理を行っている場合、影響はさらに大きくなります。この問題についての詳細は、「リソース」を参照してください。

Chrome では、スクロール中、スクロールイベントがフレームごとに 1 回起動します (60FPS 画面では 16.7ms ごとに 1 回)。Safari では、より速く起動します (ただし、これは実際には仕様違反です)。

再計算されたスタイルの表示

Bad Bunch アプリケーションを開いた状態で、[Example 3: Input Fields (例 3: 項目を入力)] を選択します。
この例では、CPU の調整が必要になる場合があります。
[Capture Settings (キャプチャの設定)] () の [CPU] で [4x slowdown (4 x 減速)] を選択して低速のブラウザーをデモンストレーションします。

[Performance (パフォーマンス)] の横にある警告アイコンと赤色の [Capture Settings (キャプチャの設定)] アイコンは、画面が調整されていることのリマインダーとして設定されています。調整は、コンピューターの能力に関係します。たとえば、[4x slowdown (4 x 減速)] オプションを選択すると、CPU の処理能力が通常より 4 倍遅くなります。
DevTools の [Performance (パフォーマンス)] パネルで、をクリックします。
[Input #1 (入力 #1)] に入力します。

不快なほどにスムーズ感が欠けています。
[Input #2 (入力 #1)] に入力します。よりスムーズです。
[Performance (パフォーマンス)] パネルで、[Stop (停止)] をクリックして記録を終了し、データがまとめられるのを待ちます。

CPU グラフに多数の紫色が表示されています。[Summary (概要)] タブを確認すると、紫色は [Rendering (レンダリング)] を表していることがわかります。大半の時間はレンダリング (表示) に費やされています。赤い三角形もたくさんあります。
小さなセクションのみを詳しく見てみましょう。その前にまず、CPU スロットリングを無効にします。
[Capture Settings (キャプチャの設定)] () で、CPU のスロットリングを無効化します。
記録が停止されても調整は継続するため、スロットリングの使用を終えたらすぐに無効化することをお勧めします。
CPU グラフの小さなセクション上でマウスをクリックしてドラッグします。

大きな [Recalculate Style (スタイルを再計算)] ブロックを見てください。何かが負荷の大きい CSS スタイルの再計算を引き起こしています。
[onSlowInput] イベントの 1 つをクリックして、[Summary (概要)] パネルで詳細を取得します。
[Summary (概要)] パネルで、[example3_InputFields.js] リンクをクリックして [Sources (ソース)] パネルで開きます。

onSlowInput メソッドによって、ブロックメソッドへのコールが行われます。ブロックメソッドでは、スタイルの再計算を引き起こすランダムなサイズの多数の div を表示します。これが問題です。
行 166 の onFastInput メソッドは、[Input #2 (入力 #2)] 項目からコールされます。ブロックコールへのコールも行いますが、デバウンスされた後でのみ行います。このことから、デバウンスが役立つ理由がわかります。再計算が生じないように、デバウンスを使用してブロックメソッドを更新することをお勧めします。

DOM ノードの急増

次の例を実行すると、ブラウザーがフリーズする場合があります。最初の単元で説明したタスクマネージャーを使用して、やり直すことができます。

Bad Bunch アプリケーションを開いた状態で、[Example 4: Table (例 4: テーブル)] タブを選択します。
ブラウザーがフリーズしたら、Chrome のタスクマネージャーを使用してプロセスを終了し、やり直してください。

大量のデータですが、読み込みは速いはずです。ページが読み込まれるときにプロファイルを記録しましょう。
[Example 3: Input Fields (例 3: 項目を入力)] をクリックして、このタブから移動します。
DevTools の [Performance (パフォーマンス)] パネルで、をクリックします。
次に [Example 4: Table (例 4: テーブル)] をクリックします。
読み込まれるのを待ちます。
[Performance (パフォーマンス)] パネルで、[Stop (停止)] をクリックして記録を終了し、データがまとめられるのを待ちます。

複数のプロファイル記録を行う場合、[Performance (パフォーマンス)] メニューで記録間を切り替えます。

[Main (メイン)] セクションのコールスタックを下にスクロールすると、renderedCallback イベントがあります。このイベントは、複数回実行されたように見えますが、実際には 1 回しか実行されていません。
[renderedCallback] イベントをクリックして、[Summary (概要)] パネルで詳細を取得します。
[Summary (概要)] パネルで、[example4_Table.js] リンクをクリックして、[Sources (ソース)] パネルで開きます。

このメソッドでは多くのことが起こっています。詳しく見てみると、多数の div が作成されていることがわかります。別の方法で見てみましょう。
[Example 4: Table (例 4: テーブル)] タブに戻り、表のセルの 1 つを右クリックして [Inspect (検証)] を選択します。
DevTools の [Elements (要素)] パネルが開き、テーブルのセルの HTML マークアップが表示されます。

実に多くの div タグがあります。しかも、これはテーブルの 1 つのセルにすぎません。
より詳しく確認できるように、パフォーマンスモニターを使用してみましょう。
DevTools で、をクリックしてメニューを展開します。次に、[More tools (その他のツール)]、[Performance monitor (パフォーマンスモニター)] の順にクリックします

パフォーマンスモニターが DevTools の下部に表示されます。パフォーマンスモニターには、CPU 使用状況、JavaScript のヒープサイズ、DOM ノードの総数など、ページの読み込みやランタイムのパフォーマンスに関するさまざまな側面を示すリアルタイムビューが表示されます。

DOM ノードを見てみましょう。ノード数が 40 万個を超えています。これがページの読み込みでどのようになるのかを見てみましょう。
パフォーマンスモニターで、[JS heap size (JS ヒープサイズ)] と [JS event listeners (JS イベントリスナー)] を選択解除します。
ページを再読み込みし、DOM ノードが増えるのを確認します。

この問題は、情報が多いページで発生する可能性があります。データテーブルだけではありません。Lightning Web コンポーネントを作成し、結び付ける方法で問題になる場合があります。コンポーネントの中にコンポーネントを配置し、その中にまた別のコンポーネントを配置したり、コンポーネントによって他のコンポーネントや大量の HTML タグを動的に生成したりすると、レイアウトに多数の DOM ノードが追加される場合があります。

Lightning Web コンポーネントや Lightning ページ全般のパフォーマンス問題を確認する方法をいくつか見てきました。新しいツールを身に付け、より適切にパフォーマンス問題に対応できるようになりました。

ヘルプをお探しですか?

もっと探す

Bad Bunch アプリケーションのパフォーマンス問題を特定する

学習の目的

過度に負荷の高いイベントコール

再計算されたスタイルの表示

DOM ノードの急増

リソース