ネットワークの問題のトラブルシューティング

学習の目的

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

• Chrome DevTools を使って、Lightning Web コンポーネントのネットワークの問題を確認する。
• [Network (ネットワーク)] パネルで要求と応答を確認する。

Lightning Web コンポーネントのネットワークトラブルシューティング

パフォーマンス、つまりサイトの速度は、サーバーリソース、クライアントリソース、ブラウザーの速度など、さまざまな要因に左右されます。多くのサイトは、ページの読み込み時間のみをパフォーマンスの測定単位として使用しています。一方 Salesforce では、Lightning のパフォーマンスを測定するにあたり、ユーザーが体験するパフォーマンスに着目します。体験ページ時間 (EPT) は、Salesforce が定めるパフォーマンスメトリクスです。あるページを読み込んで、ユーザーが十分に操作できるようになるまでにかかる時間を測定します。

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

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

このモジュールでは、ネットワークパフォーマンスとブラウザーパフォーマンス、ブラウザーパフォーマンスの中では特にブラウザーメモリを取り上げます。

始める前に

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

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

このモジュールの大部分は、「Lightning Web コンポーネントのトラブルシューティング」トレイルの先行するモジュールで学習する Chrome DevTools の知識を前提としています。これらのバッジを獲得したばかりの皆さんは、このモジュールで必要なコードが、すでに GitHub から Playground に取得されているはずです。次の手順に従って、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_Net_Full_Access.permissionset-meta.xml ファイルがあることを確認します。
7. force-app/main の下にある default フォルダーを右クリックします。
8. [SFDX: Deploy Source to Org (SFDX: 組織にソースをリリース)] を選択します。
9. [View (表示)] | [Terminal (ターミナル)] をクリックします。
10. ターミナルで次のコマンドを実行して、[Bad Net Full Access (Bad Network フルアクセス)] 権限セットをデフォルトのユーザーに割り当てます。
    sf org assign permset --name Bad_Net_Full_Access
11. 下の「クリーンなブラウザーで始める」に進みます。

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

「Lightning Web コンポーネントのトラブルシューティング」モジュールをまだ受講していない場合は、まず Trailhead Playground にいくつかの Lightning Web コンポーネントを設定して、このモジュールでトラブルシューティングができるように準備する必要があります。

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

このモジュールにハンズオン Challenge はありませんが、以下の手順を Trailhead Playground で練習することができます。Playground へのアクセス方法は次のとおりです。まず、Trailhead にログインしていることを確認します。次に、このページの右上にあるユーザーアバターをクリックして、ドロップダウンから [Hands-on Orgs (ハンズオン組織)] をクリックします。開く組織の横にある [Launch (起動)] をクリックします。または、新しい 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 Net Full Access (Bad Nework フルアクセス)] 権限セットをデフォルトのユーザーに割り当てます。
   sf org assign permset --name Bad_Net_Full_Access

これで Chrome DevTools を使ったトラブルシューティングの準備ができました。

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

1. Chrome ブラウザーを開きます。
2. [Customize and control Google Chrome (Google Chrome のカスタマイズと制御)] アイコン () をクリックして、[New Incognito Window (新しいシークレットウィンドウ)] を選択します。そうすることで、拡張機能がインストールされていないクリーンな状態で Chrome が実行されます。拡張機能があると、パフォーマンス測定でノイズが発生する可能性があります。
3. Trailhead Playground を開きます。
4. ユーザーのデバッグモードが有効になっていて、デバッグモードバナーの下に EPT が表示されていることを確認します。
   
   

   URL 接尾辞 ?eptVisible=1 を使って EPT を表示することもできます。

応答が遅いコンポーネントをトラブルシューティングする

1. Trailhead Playground のアプリケーションランチャー () で、[Bad Network] を見つけて開きます。
2. Bad Network アプリケーションで [+1] を数回クリックして、数を増やします。
   1 ずつ増やすだけなのに、あまりに時間がかかり過ぎています。DevTools の [Performance (パフォーマンス)] タブを使ってトラブルシューティングしましょう。
3. ブラウザーウィンドウを右クリックして [Inspect (検証)] を選択 (または F12 をクリック) して DevTools を開きます。
4. [Customize and control DevTools (DevTools のカスタマイズと制御)] アイコン () をクリックして、ドックの表示位置を選択します。ドックの表示位置は、[Undock into separate window (ドッキングを解除して別のウィンドウで表示)]、[Dock to left (ドックを左に表示)]、[Dock to bottom (ドックを下に表示)]、[Dock to right (ドックを右に表示)] から選択できます。(このモジュールの画像は、DevTools のドッキングを解除して別のウィンドウで表示したものです。)

   

   DevTools を別のウィンドウに表示することで、トラブルシューティング中にあらゆるデータにアクセスしやすくなります。

5. DevTools メニューから [Performance (パフォーマンス)] タブを選択します。
6. [Performance (パフォーマンス)] メニューで [Record (記録)] アイコン () をクリックして、プロファイルの記録を開始します。
7. Bad Network アプリケーションで [+1] をクリックして、再び数を増やします。
   数が更新されるのを待ちます。
8. [Performance (パフォーマンス)] パネルで [Stop (停止)] をクリックして記録を停止し、データがコンパイルされ、[Performance (パフォーマンス)] パネルのタイムラインに表示されるのを待ちます。

パフォーマンスデータの確認

1. [FPS] と [CPU] グラフの下にある [NET] タイムライングラフに長い青のラインが表示されています。
   
2. 左側の [Network (ネットワーク)] セクションを展開します。2000 ミリ秒～ 2500 ミリ秒の間に、[NET] グラフセクションの青のラインと合致する aura コールが開始されているのが分かります。
   
3. aura コールにカーソルを置くと、要求の情報が表示されます。
   

   タイムスタンプ (ここでは 2.9 秒) と要求名が表示されています。

[Performance (パフォーマンス)] パネルを確認することで、長時間にわたって実行されているネットワーク要求があることが分かりました。さらに詳しく調べるため、次は [Network (ネットワーク)] パネルを使用します。

[Network (ネットワーク)] パネル

[Performance (パフォーマンス)] パネルと同様に、[Network (ネットワーク)] パネルにも調査やトラブルシューティングに使用できるさまざまなオプションがあります。ここでは、代表的なもののみ取り上げます。[Network (ネットワーク)] パネルの全容について詳しくは、「リソース」を参照してください。

[Network Log (ネットワークログ)]

ネットワークアクティビティはすべて、[Network (ネットワーク)] パネルの [Network Log (ネットワークログ)] に記録されます。

[Network Log (ネットワークログ)] の各行が 1 つのリソースに相当します。リソースは、デフォルトでは古いものから新しいものの順に時系列でリストされます。DevTools では、DevTools を開いている間のみ、ネットワークアクティビティがログに記録されます。

それぞれの列には、リソースに関する情報が含まれます。

• Name (名前): リソース名をクリックすると、リソースの詳細が表示されます。
• Status (ステータス): HTTP 応答コード。
• Type (種別): リソース種別。
• Initiator (イニシエーター): リソースが要求される原因となったコード。
  [Initiator (イニシエーター)] をクリックすると、対応するソースコードが開きます。
• Time (時間): 要求の実行にかかった時間。
• Waterfall (滝グラフ): 要求の異なる段階を示すグラフ。
  カーソルを置くと、要求の内訳が表示されます。

応答の詳細を調査する

1. [Network (ネットワーク)] タブを選択します。
   

   [Fetch/XHR (取得/XHR)] フィルターを選択して、XMLHttpRequest (XHR) 要求のみが表示されるようにします。

2. aura.ApexAction.execute=1 というリソース名をクリックして、このリソースの詳細を開きます。
   リソースの詳細が開き、前回選択したタブが表示されます。
3. [Response (応答)] タブをクリックして、サーバーから受信した応答を表示します。
   

   受信する応答の形式はいくつかあります。ここでの応答は、大規模 JSON (JavaScriptObjectNotation) 形式です。

4. [Timing (タイミング)] タブをクリックして、ネットワークアクティビティの内訳を表示します。
   

   [Waiting for server response (サーバーからの応答待機時間)] に長い緑のバーが表示されているのが分かります。これは、サーバーからの応答を待つ時間、すなわち、ブラウザーがページを要求してから、サーバーから情報の最初のバイトを受信するまでの時間です。ここでは、[Waiting for server response (サーバーからの応答待機時間)] は 3.83 秒です。

5. [Initiator (イニシエーター)] タブをクリックして、要求コールスタックを表示します。
   このとき、DevTools による絞り込みによって、最も重要な項目 (フレーム) や最も長いコールなどのみが表示されます。[Show more frames (その他のフレームを表示)] リンクをクリックして、コールスタックのすべての項目を表示します。
   
   スタックを見てみると、example1_IncreaseNumber.js ファイルで increaseNum が longAsyncFetch を呼び出しているのが分かります。
6. [Initiator (イニシエーター)] パネルで [example1_IncreaseNumber.js] リンクをクリックして、[Sources (ソース)] パネルで example1_IncreaseNumber.js ファイルを開きます。
   
   
   

   行番号はスクリーンショットを基準にしています。皆さんのコードは、これとは異なる行番号でコンパイルされている場合があります。

   コードの行番号の列で強調表示されている時間は、単にブラウザーがコールに関与した時間であり、コールの長さではありません。場合によっては、async longAsyncFetch メソッドが表示されるまで下にスクロールする必要があります。
   
   84 行目では、increaseNum(event) メソッドが await 演算子を使って longAsyncFetch() を呼び出しています。それが原因となって、javaScript に長い応答待機時間が生じます。同様に、longAsyncFetch() メソッド内にも await を使った apex_generateJSONRecords_default メソッドの呼び出しがあり、応答を待ってから続行されます。

以上のことから、数を増やすのに長い時間がかかる理由が、これらの await 演算子のいずれか (または両方) によって、応答があるまでコードが待機するからであることが分かりました。await 演算子を削除してプロセスをバックグラウンドで実行できるようにするか、Apex コードを修正して実行にかかる時間を短縮するかのいずれかの対応が必要です。

次は、クライアント側のブラウザーメモリの問題を見ていきます。

リソース

• Chrome Developers: ネットワークアクティビティを検査する
• MDN Web Docs: await
• MDN Web Docs: Time to first byte (最初のバイトまでの時間)