最も高速で最適化されたリソースは、送信されないリソースです。アプリから不要なリソースを削除する必要があります。暗黙的および明示的な前提条件について、チームで疑問を投げかけ、定期的に見直すことをおすすめします。いくつか例を挙げましょう。
- ページにリソース X を常に含めている場合、そのリソースをダウンロードして表示するコストは、ユーザーに提供する価値に見合っているでしょうか。その価値を測定し、証明できますか？
- リソース（特にサードパーティのリソース）は一貫したパフォーマンスを提供しているか。このリソースはクリティカル パスにありますか？または、クリティカル パスに含める必要がありますか？リソースがクリティカル パスにある場合、サイトの単一障害点になる可能性があります。つまり、リソースが利用できない場合、ページのパフォーマンスとユーザー エクスペリエンスに影響するかどうかです。
- このリソースに SLA は必要ですか？または SLA がありますか？このリソースは、圧縮、キャッシュ保存などのパフォーマンスのベスト プラクティスに沿っていますか？
ページに不要なリソースが含まれていることがよくあります。さらに悪いことに、訪問者やホストされているサイトにあまり価値をもたらさずに、ページのパフォーマンスを低下させるリソースが含まれていることもあります。これは、ファーストパーティとサードパーティのリソースとウィジェットに同様に適用されます。
- サイト A は、ホームページに写真カルーセルを表示して、訪問者がクリックするだけで複数の写真をプレビューできるようにしました。ページが読み込まれるとすべての写真が読み込まれ、ユーザーは写真を順番に表示できます。
- 質問: カルーセルで複数の写真を表示したユーザーの数を測定したことはありますか？ほとんどの訪問者が閲覧しないリソースをダウンロードすることで、高いオーバーヘッドが発生している可能性があります。
- サイト B は、関連コンテンツの表示、ソーシャル エンゲージメントの向上、その他のサービスの提供を目的として、サードパーティのウィジェットをインストールすることにしました。
- 質問: ウィジェットを使用している訪問者の数や、ウィジェットが提供するコンテンツのクリックスルー数をトラッキングしていますか。このウィジェットが生成するエンゲージメントは、オーバーヘッドを正当化するのに十分なものですか？さらに、読み込み戦略を使用して、スクリプトが必要になるまで読み込まれないようにすることは可能ですか？
不要なダウンロードを排除するかどうかを判断するには、多くの場合、慎重な検討と測定が必要です。最良の結果を得るには、ページ上のすべてのアセットについて、定期的にインベントリを作成し、これらの質問を再確認してください。
Core Web Vitals への影響
Core Web Vitals イニシアチブは、ユーザーがウェブを使用する際のエクスペリエンスを反映する一連の指標を提供するために Google が導入したものです。Core Web Vitals の最適化戦略は数多くありますが、ページに特定のリソースを読み込むかどうかを検討することで、ウェブサイトでこれらの指標を改善する道が開けるかもしれません。以下に、Core Web Vitals の各指標別に、検討に値する例をいくつか示します。これはすべての例を網羅したリストではありませんが（他にもたくさんあります）、一読することで、考えるきっかけになるかもしれません。
Largest Contentful Paint（LCP）
Largest Contentful Paint（LCP）は、最大のコンテンツ（ヒーロー画像や見出しなど）が読み込まれるタイミングを測定します。これは、サイトの読み込みが速いという印象をユーザーに与える重要な知覚指標と考えられています。
一般的に、ダウンロードするリソースが少ないということは、ユーザーが持つ帯域幅がより少ないリソースに割り当てられることを意味し、LCP の改善につながる可能性があります。典型的な例は遅延読み込みです。ページ読み込み時にビューポート外にある画像は、ユーザーがそれらを見る可能性が高いとブラウザが判断するまでダウンロードされません。たとえば、50 枚の画像を含む大きなサムネイル ギャラリーがある場合、上位 10 枚以外のすべての画像を遅延読み込みすると、ブラウザは利用可能な帯域幅をより効率的に使用でき、ユーザーが最初に目にする画像がより速く読み込まれます。
ただし、必ずしも読み込む画像を減らすことだけが重要なのではありません。ブラウザには、各リソースに割り当てる帯域幅を決定する内部優先度設定スキームがあります。ただし、この場合でも、すべてのリソース（特に優先度が高いリソース）が、潜在的な LCP 要素の依存リソースを奪う可能性があります。これは、ネットワーク接続が遅い場合に特に当てはまります。この依存リソースは、ページの LCP 要素を表す画像ファイルである可能性がありますが、ブラウザがテキストノードをレンダリングするために必要なウェブフォント リソースである可能性もあります。このテキストノードは、ページの LCP 要素として決定される可能性があります。
ウェブサイトにテキストが多い場合、ページの LCP 要素がテキストノードになることがあります。フォントの最適化と読み込みの戦略は数多くありますが、ウェブサイトのニーズにシステム フォントで十分かどうかを検討する価値はあります。テキストノードである LCP 要素をウェブフォント リソースに依存せずに読み込み、CSS と HTML がサーバーから届くとほぼ同時にペイントできるからです。
Cumulative Layout Shift（CLS）
読み込むすべてのリソースは、ページの Cumulative Layout Shift（CLS）に影響する可能性があります。特に、最初の描画までにダウンロードが完了していない場合は、その可能性が高くなります。画像の場合、CLS を回避するには、明示的なサイズを設定するなどの方法があります。フォントについては、フォントの読み込みと、場合によっては代替フォントのマッチングを管理することで、ウェブフォントのスワップ期間中のずれを最小限に抑えることができます。JavaScript の場合は、スクリプトが DOM を操作する方法を管理して、レイアウト シフトを許容可能な量に減らすことができます。
ページの CLS に影響するすべてのリソースについて、ページ レイアウトを十分に安定させるための作業が必要になります。特定のリソースが必要かどうかを検討することで、ページの読み込みを高速化するだけでなく、レイアウトの安定性を維持するために必要な認知的労力を軽減できます。これにより、ユーザー エクスペリエンスが大幅に向上するだけでなく、デベロッパー エクスペリエンスも向上し、プロジェクトの他の目標を追求する時間を増やすことができます。
Interaction to Next Paint（INP）
Interaction to Next Paint（INP）は、ページのライフサイクル全体にわたってユーザー入力に対する応答性を測定します。ページの INP は、読み込まれる JavaScript の影響を大きく受ける可能性があります。JavaScript は、ウェブ全体でユーザーが体験するインタラクティビティのほとんどを駆動するものであるためです。特に、ページの読み込み中にダウンロードされるスクリプト リソースの量によっては、スクリプトの評価とコンパイルに関連する負荷の高い作業が開始される可能性があります。起動時に読み込む JavaScript が少ないほど、ページ エクスペリエンスの重要なポイント（ユーザーが操作しようとしている可能性があるポイント）でブラウザが行う作業が少なくなります。
起動時にダウンロードされる JavaScript リソースのサイズを削減する戦略（コード分割やツリー シェイキングなど）はありますが、プロジェクトで使用するパッケージを監査して、それらが本当に必要かどうかを確認することをおすすめします。たとえば、lodash には、現在でも有用なメソッドが多数ありますが、マッピング、削減、フィルタリング用の Array 固有の関数やその他多数の関数など、ブラウザが標準で提供するメソッドも含まれています。
プログレッシブ エンハンスメントは、JavaScript にとっても有用なアプローチです。ベースライン（ただし機能はする）のエクスペリエンスをユーザーに提供し、より強力なデバイスと高速なネットワーク接続を使用するユーザー向けに機能を追加できるためです。プログレッシブ エンハンスメントの原則に準拠しているかどうかにかかわらず、ダウンロードを回避できる JavaScript リソースはすべて、ユーザー インタラクションに迅速に応答するエクスペリエンスにつながります。これは、ウェブ パフォーマンスの重要な側面です。
まとめ
ウェブサイトを監査して不要なダウンロードを特定することは、高速なユーザー エクスペリエンスを提供するための一側面にすぎませんが、大きな効果が期待できる側面でもあります。まとめると次のようになります。
- ページ上の独自のアセットとサードパーティのアセットをインベントリに登録します。
- 各アセットのパフォーマンス（価値と技術的パフォーマンス）を測定します。
- リソースが十分な価値を提供しているかどうかを判断する。
- 不要なダウンロードが Core Web Vitals とサポート指標に与える影響を理解する。
このようにコンテンツの効率を最適化することで、全体的なパフォーマンスが向上するだけでなく、ユーザーの帯域幅を無駄にしないように配慮することもできます。また、ユーザー中心の指標を改善し、より優れたユーザー エクスペリエンスを提供できる可能性もあります。