トラブルシューティングの準備をする

学習の目的

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

• パフォーマンスプロファイルの記録を作成する。
  
• コールスタックを検証して問題を見つける。
  
• プロファイル記録の一部分を選択する方法を示す。
  
• Chrome のタスクマネージャーを使用してプロセスを終了する。
  

Lightning Web コンポーネントのパフォーマンスに関するトラブルシューティング

パフォーマンスは、サイトの速度という観点に基づきます。体験ページ時間 (EPT) は、ページの読み込み時間を測定するために Salesforce が Lightning で使用しているパフォーマンスメトリクスです。このメトリクスでは、あるページを読み込んでユーザーが意味のある操作を行える「使用可能状態」になるまでにかかる時間が測定されます。大半のページでは、3 秒未満が目標です。

Lightning Web コンポーネントのパフォーマンスに関するトラブルシューティングは、多方面にわたる場合があります。EPT は高次のページパフォーマンス指標です。パフォーマンスの問題を詳しく調査するにあたって、大きく 3 つの分野を考慮する必要があります。

• ネットワークパフォーマンス
  
• ブラウザーパフォーマンス
  
• ページの複雑さとカスタマイズ
  

始める前に

ほとんどのブラウザーの開発者ツールに類似の機能がありますが、このモジュールでは Chrome DevTools を取り上げます。

すでに Salesforce DX 開発環境が整っていて、その環境で Lightning Web コンポーネントを作成して組織にリリースできることを前提とします。まだこのプロセスに不慣れな場合は、このモジュールの前に「クイックスタート: Lightning Web コンポーネント」プロジェクトを修了してください。

このモジュールの大半は、このトレイルの前モジュール「Lightning Web コンポーネントのトラブルシューティング」で学習する Chrome DevTools の知識が基盤となります。そのバッジを修了したばかりなら、このモジュールで必要な GitHub からのコードをすぐに使用できる準備が Playground で整っているはずです。

「Lightning Web コンポーネントのトラブルシューティング」バッジを修了されている方は、GitHub から最新のコードが取得されているかを確認してください。

1. Visual Studio Code で troubleshoot-lwc プロジェクトを開きます。
   

• [File (ファイル)] > [Open (開く)] (macOS) または [File (ファイル)] > [Open Folder (フォルダーを開く)] (Windows) をクリックし、[troubleshoot-lwc] ディレクトリを選択します。
  

2. Ctrl+Shift+P (Windows) または Cmd+Shift+P (macOS) を押して、コマンドパレットを開きます。
   
3. git と入力します。
   
4. [Git: Pull] を選択します。
   
5. force-app/main/default ディレクトリ内の permissionsets ディレクトリを開きます。
   
6. Bad_Bunch_Full_Access.permissionset-meta.xml ファイルがあることを確認します。
   
7. force-app/main の下にある default フォルダーを右クリックします。
   
8. [SFDX: Deploy Source to Org (SFDX: 組織にソースをリリース)] を選択します。
   
9. [View (表示)] > [Terminal (ターミナル)] をクリックします。
   
10. ターミナルで次のコマンドを実行して、[Bad Bunch Full Access (Bad Bunch フルアクセス)] 権限セットをデフォルトのユーザーに割り当てます。
    sf org assign permset -n Bad_Bunch_Full_Access
    
11. 以下の「クリーンなブラウザーで始める」に進んでください。
    

トラブルシューティング環境を設定する

最初に、いくつかの Lightning Web コンポーネントで Trailhead Playground を設定し、トラブルシューティングの準備を行う必要があります。

Lightning Web コンポーネントを実際に使ってみる

このモジュールにハンズオン Challenge はありませんが、以下の手順を Trailhead Playground で練習することができます。Playground へのアクセス方法は次のとおりです。まず、Trailhead にログインしていることを確認します。次に、このページの右上にあるユーザーアバターをクリックして、ドロップダウンから [ハンズオン組織] をクリックします。開く組織の横にある [起動] をクリックします。または、新しい Playground を作成する場合は、[Create Playground (Playground を作成)] をクリックします。

デバッグモードを有効化

このステップによって、格段にトラブルシューティングしやすくなります。組織でデバッグモードを有効にすると、コードが縮小されません。したがって、変数名も変わらず、コード全体の構造もそのままなので、トラブルシューティングしやすくなります。

1. [Setup (設定)] の [Quick Find (クイック検索)] ボックスに Debug Mode (デバッグモード) と入力し、[Debug Mode (デバッグモード)] を選択します。
   
2. 該当するユーザーの横にあるチェックボックスをオンにします。
   
3. [Enable (有効化)] をクリックします。
   

GitHub から Lightning Web コンポーネントを入手する

1. GitHub リポジトリの readme の手順を実行します。
   
2. Visual Studio Code のターミナルで次のコマンドを実行して、[Bad Bunch Full Access (Bad Bunch フルアクセス)] 権限セットをデフォルトのユーザーに割り当てます。
   sf org assign permset -n Bad_Bunch_Full_Access
   

ご使用の環境で、ブラウザーの DevTools を使用してトラブルシューティングを行う準備ができました。

クリーンなブラウザーで始める

1. シークレットモードかゲストモードで Chrome ブラウザーを開きます。
   そうすることで、拡張機能がインストールされていないクリーンな状態で Chrome が実行されます。拡張機能があると、パフォーマンス測定でノイズが発生する可能性があります。
   

• [Customize and control Google Chrome (Google Chrome のカスタマイズと制御)] () をクリックし、[New Incognito Window (新しいシークレットウィンドウ)] を選択します。
  

2. Playground を開きます。
   
3. ユーザーのデバッグモードが有効になっていることを確認します。
   有効になっていると、ブラウザーに EPT も表示されます。
   
   

EPT の表示は、「?eptVisible=1」という URL サフィックスを使用して行うこともできます。

Chrome ブラウザーのフリーズやクラッシュを修正する

このバッジで取り上げる Lightning Web コンポーネントの例が原因で、ブラウザーがフリーズしたり、Chrome がクラッシュしたりする可能性があります。応答しないタブを閉じることができる便利なツールがあります。見てみましょう。

1. Chrome ブラウザーのタブセクションの空白領域で右クリックし、[Task Manager (タスクマネージャー)] を選択します。
   
   
2. タスクマネージャーで項目をクリックすると、プロセスを終了するオプションが表示されます。
   
   

動かなくなったプロセスから抜け出せる方法がわかったところで、始めることにしましょう。 

DevTools の [Performance (パフォーマンス)] タブを開く

Chrome DevTools の [Performance (パフォーマンス)] タブを使用して、Bad Bunch アプリケーションを見てみましょう。

1. Playground のアプリケーションランチャー () で、[Bad Bunch] を見つけて開きます。
   
2. ブラウザーウィンドウを右クリックし、[Inspect (検証)] をクリックします。
   
3. [Customize and control DevTools (DevTools のカスタマイズと制御)] () をクリックし、使用するドッキングの場所を選択します。(このモジュールの画像は、DevTools のドッキングを解除して別のウィンドウで表示したものです。)
   
   DevTools を別のウィンドウに表示することで、トラブルシューティング中にあらゆるデータにアクセスしやすくなります。
   
4. [Performance (パフォーマンス)] タブを選択します。
   
   

パフォーマンスのオプション

[Performance (パフォーマンス)] 領域には、さまざまなオプションと収集可能な情報があります。以下にいくつか紹介します。

プロファイルを記録する

1. Bad Bunch アプリケーションを開いた状態で、DevTools の [Performance (パフォーマンス)] タブで [Record (記録)] () をクリックします。
   [Record (記録)] アイコンが赤色に変わり、ステータスウィンドウに「Profiling (プロファイルを作成しています)」というステータスと [Stop (停止)] ボタンが表示されます。
   
   
2. Bad Bunch アプリケーションで、[Do Something (何かする)] をクリックします。
   実行にかかった時間が表示されるのを待ちます。しばらく時間がかかるはずです。要求が実行されている間、ブラウザーは基本的にロックされます。
   
   
3. 次に、[Do Something Faster (より速く何かする)] をクリックします。
   より短い時間が表示されます。
   
   
4. [Performance (パフォーマンス)] パネルで、ステータスウィンドウの [Stop (停止)] をクリックします。
   記録が停止します。その後、データが処理され、結果が [Performance (パフォーマンス)] パネルに表示されます。
   
   相当な量の情報ですね。
   

[Performance (パフォーマンス)] セクション内の操作は、少しわかりづらいかもしれません。マウスでスクロールすると、上か下にスクロールするのではなく、ズームインまたはズームアウトします。基本的なコマンドは次のとおりです。

• ズームイン/ズームアウトするには、マウスホイールかトラックパッドでスクロールします。
  
• 上/下/左/右にスクロールするには、UI の任意の場所をクリック & ドラッグします。
  
• 上/下にスクロールするには、スクロールバーをクリック & ドラッグします。
  
• ズームイン/ズームアウトおよび左/右にスクロールするには、WASD キー (キーが異なる場合は使用しているキーボードの同等キー) を使用します。
  
• カテゴリ変更は上/下矢印キーを使用し、展開/折りたたむには左/右矢印キーを使用します。
  

5. CPU グラフで使用されている色は、グラフの下の [Summary (概要)] パネルで使用されています。
   
   CPU グラフに、最大値に達している色があります。これは、問題がある可能性を強く示しています。[Summary (概要)] パネルの対応する色を見ると、[Scripting (スクリプト)] が最大値に達していることがわかります。
   
6. [Main (メイン)] セクションを開くと、イベントがコールされたときの JavaScript のコールスタックが表示されます。
   
   バーはイベントを表し、サイズは実行にかかった時間を示しています。イベントが互いに重なって表示されている場合は、上位のイベントが下位のイベントの原因となっています。LWC のパフォーマンスをトラブルシューティングする場合、JavaScript のシングルスレッドという性質を理解することが不可欠です。
   
7. イベントの 1 つを選択して、[Summary (概要)] パネルに詳細を表示します。
   
   この特定のイベントは、invokeListenersByPlacement Aura イベントです (aura_proddebug.js ファイルの行 516 にあります)。これは、Lightning のベースコードの一部であり、トラブルシューティングの対象ではありません。
   
8. いずれかの runExpensiveLoop イベントを選択します。
   
   何回も実行されたように見えますが、これは誤解を招くことがあります。DevTools ではヒューリスティックを使用して、結果の表示方法を決定します。とはいえ、これが今回の例のコードです。Aura イベントではありません。
   
9. [Summary (概要)] パネルで [example1_Loop.js] ファイルへのリンクをクリックすると、強調表示されたコードと実行時間が示されている [Sources (ソース)] パネルに移動します。
   
   行 99 から、ループ内の JSON 文字列の解析で時間がかかりすぎていることがわかります。
   
10. [Performance (パフォーマンス)] タブに戻り、必ず [Main (メイン)] セクションの余白をクリックして runExpensiveLoop セクションをクリアします。
    
11. [Summary (概要)] タブの横にある [Bottom-Up (ボトムアップ)] を選択します
    
    この方法でも、実行時間が最も長くかかっているものがわかります。[Bottom-Up (ボトムアップ)] パネルには、選択した記録部分のイベントのみが表示されます。[Do Something Faster (より速く何かする)] ボタンのクリックを見てみましょう。
    

使用する記録部分を選択する

1. [Overview (概要)] セクション (FPS、CPU、NET の各グラフがある領域) でマウスを左または右に動かすと、記録のその時間のスクリーンショットが表示されます。
   
   
2. 選択する記録部分上をマウスでクリックしてドラッグします。
   [Do Something Faster (より速く何かする)] ボタンのクリックの領域を選択します。
   
   より小さい記録セクションを確認できます。
   

コンピューターの能力が違うため、各自の記録はこの例と異なります。

3. [runOptimalLoop] イベントをクリックして、[Summary (概要)] パネルで詳細を表示します。[Bottom-Up (ボトムアップ)] パネルがまだ表示されている場合は、[Summary (概要)] タブを選択する必要があります。
   
4. [example1_Loop.js] リンクをクリックし、再び [Sources (ソース)] パネルに切り替えます。
   
   runOptimalLoop は runExpensiveLoop に類似していますが、行 112 で JSON 解析が for ループの外側で発生しています。行 112 で解析を for ループの外側で 1 回のみ実行した場合、横の列に表示されているように ~0.1s しかかかりません。ループ内で何度も解析が実行された行 99 では、合わせて ~4,343.3ms かかっています。メソッド内の解析の配置を比較すると、400 万パーセントもの増加になります。各自で記録された時間は、この結果とは異なる可能性があります。
   
5. このプロファイルをダウンロードしてコピーを保存するには、[Save pofile (プロファイルを保存します)] () をクリックし、JSON ファイルの保存場所を選択し、[Save (保存)] をクリックします。
   後で、[Load profile (プロファイルを読み込みます)] () を使用してアップロードできます。
   

参照用に、コピーされた GitHub リポジトリに記録済みプロファイルがあります。

• [Load profile (プロファイルを読み込みます)] をクリックして、DX プロジェクトに移動します。
  
• [Profiles (プロファイル)] フォルダーを開き、[Example-1-Loop-profile.json] を選択します。
  

次の単元では、Lightning Web コンポーネントの他の例をいくつか見てみましょう。

リソース

• Salesforce 開発者ブログ: Understanding Experienced Page Time (体験ページ時間について理解する)
• Salesforce 開発者ブログ: Lightning Web Components Performance Best Practices (Lightning Web コンポーネントのパフォーマンスのベストプラクティス)
• Trailhead: Lightning Experience のパフォーマンスの最適化
• Chrome Developers: ランタイムパフォーマンスを分析する
• Chrome Developers: パフォーマンス機能のリファレンス