ブラウザの DevTools の [Network] パネルでは、読み込まれたリソースとそのタイミングを確認できます。[Network] パネルの各行は、ウェブアプリが読み込んだ特定の URL に対応しています。
何を読み込むかを知る
ウェブ アプリケーションに適切なキャッシュ戦略を考案するには、何を読み込むかを正確に把握する必要があります。信頼性の高いウェブ アプリケーションを構築する場合、ネットワークはあらゆる種類のダーク フォースの影響を受ける可能性があります。アプリで脆弱性に対処するには、ネットワークの脆弱性を理解する必要があります。
ウェブ アプリケーションが何を読み込むかについては、すでによく理解しているかもしれません。静的 HTML、JavaScript、CSS、画像ファイルを少しずつ分散させて使用しているだけであれば、問題ないでしょう。しかし、動的 API リクエストとサーバーで生成されたレスポンスを使用して、コンテンツ配信ネットワークでホストされているサードパーティのリソースを組み合わせると、すぐに状況は複雑になります。
たとえば、少数の小さな CSS ファイルでは理にかなったキャッシュ戦略は、たとえば何百もの大きな画像では意味がありません。
読み込みのタイミングを把握する
読み込み状況のもう 1 つの側面は、すべて読み込まれるタイミングです。
ネットワークに対する一部のリクエスト（最初の HTML のナビゲーション リクエストなど）は、ユーザーが特定の URL にアクセスすると無条件に行われます。この HTML には、インタラクティブなページを表示するために読み込みが必要な重要な CSS ファイルまたは JavaScript ファイルへの参照がハードコードされている場合があります。これらのリクエストはすべてクリティカルな読み込みパスに配置されます。確実に高速にするには、これらを積極的にキャッシュに保存する必要があります。
API リクエストや遅延読み込みアセットなど、その他のリソースは、初期読み込みがすべて完了してからしばらく経つまで読み込みが開始されない場合があります。これらのリクエストが特定の一連のユーザー操作の後にのみ発生する場合、同じページへの複数回の訪問でまったく異なるリソースセットがリクエストされる可能性があります。クリティカルな読み込みパスの外にあると判断されたコンテンツには、多くの場合、それほど積極的なキャッシュ戦略は適していません。
名前列とタイプ列は
Name 列と Type 列は、読み込まれる内容をわかりやすく示すのに役立ちます。上記の例の「何を読み込んでいますか？」に対する答えは、合計 4 つの URL です。それぞれの URL は一意のコンテンツ タイプを表します。
名前は、ブラウザがリクエストした URL を表しますが、URL のパスの最後の部分だけが表示されます。たとえば、https://example.com/main.css が読み込まれると、[Name] の下には main.css のみが表示されます。
URL のパスの最後の数文字（「css」など）に続くピリオドは、URL の拡張子と呼ばれます。通常、URL の拡張子はリクエストされているリソースの種類を示し、[Type] 列に表示される情報に直接マッピングされます。たとえば、v2.html はドキュメントで、main.css はスタイルシートです。
ウォーターフォール列は
[Waterfall] 列は、一番上から下に進んでいくところを見ることができる。各棒の長さは、各リソースの読み込みに費やした合計時間を表します。クリティカル読み込みパスの一部として行われるリクエストと、ページの初期読み込み完了後に動的に発生するリクエストの違いは、どのようにすればよいでしょうか。
ウォーターフォールの最初のリクエストは、常に HTML ドキュメントに対するものです（例: v2.html）。後続のリクエストはすべて、この最初のナビゲーション リクエストから、HTML ドキュメントが参照している画像、スクリプト、スタイルに基づいて（ウォーターフォールのように）流れます。
ウォーターフォールは、v2.html の読み込みが完了するとすぐに、参照するアセット（サブリソースとも呼ばれます）のリクエストが開始されることを示します。ブラウザは複数のサブリソースを同時にリクエストできます。これは、main.css と logo.svg の [Waterfall] 列に重なり合うバーで表されます。最後に、スクリーンショットを見ると、main.js が最後に読み込みを開始し、他の 3 つの URL も完了した後に読み込みが完了することがわかります。