最も高速で最適化されたリソースは、送信されないリソースです。アプリケーションから不要なリソースを削除する必要があります。暗黙的および明示的な前提をチームで疑問視し、定期的に再検討することをおすすめします。いくつか例を挙げましょう。
- リソース X を常にページに含めてきましたが、ダウンロードと表示にかかる費用は、ユーザーに提供する価値に見合っていますか？その価値を測定して証明できますか？
- リソース（特にサードパーティ リソースの場合）は、一貫したパフォーマンスを提供していますか？このリソースはクリティカル パスに含まれていますか？含まれている必要があるか？リソースがクリティカル パスにある場合、サイトの単一障害点になる可能性がありますか？つまり、リソースが利用できない場合、ページのパフォーマンスとユーザー エクスペリエンスに影響しますか？
- このリソースに SLA は必要ですか？SLA はありますか？このリソースは、圧縮、キャッシュなど、パフォーマンスのベスト プラクティスに準拠していますか？
ページに不要なリソースが含まれていたり、訪問者やホストされているサイトにほとんど価値をもたらさずにページのパフォーマンスを低下させたりするケースは少なくありません。これは、ファーストパーティとサードパーティのリソースとウィジェットに同様に適用されます。
- サイト A は、ホームページに写真カルーセルを表示して、訪問者が簡単にクリックして複数の写真をプレビューできるようにすることにしました。ページの読み込み時にすべての写真が読み込まれ、ユーザーが写真を移動します。
- 質問: カルーセル内の複数の写真を確認したユーザーの数を測定しましたか？ほとんどの訪問者が表示しないリソースをダウンロードすることで、大きなオーバーヘッドが発生している可能性があります。
- サイト B は、関連コンテンツの表示、ソーシャル エンゲージメントの向上、その他のサービスの提供を目的として、サードパーティ製ウィジェットをインストールすることにしました。
- 質問: ウィジェットを使用した訪問者数や、ウィジェットから提供されるコンテンツのクリックスルー数をトラッキングしていますか？このウィジェットが生成するエンゲージメントは、オーバーヘッドを正当化するのに十分ですか？また、読み込み戦略を使用して、必要なときまでスクリプトが読み込まれないようにすることは可能ですか？
不要なダウンロードを排除するかどうかを判断するには、慎重な検討と測定が必要になる場合がよくあります。最適な結果を得るには、ページ上のすべてのアセットについて、これらの質問を定期的に確認し直してください。
Core Web Vitals への影響
ウェブに関する主な指標は、ウェブの使用時にユーザーがどのような体験をしているかを反映した一連の指標を提供する取り組みとして Google によって導入されました。Core Web Vitals の最適化戦略は数多くありますが、ページに特定のリソースを読み込むかどうかを検討することで、ウェブサイトのこれらの指標を改善するための道筋が開けるかもしれません。以下に、検討に値する例を、各 Core Web Vital ごとにグループ化して示します。これらは例の一部にすぎませんが（他にもたくさんあります）、ぜひ参考にしてください。
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 リソースを減らすほど、ユーザー インタラクションに迅速に応答できるエクスペリエンスが実現できます。これはウェブ パフォーマンスの重要な要素です。
まとめ
ウェブサイトの不要なダウンロードを監査することは、高速なユーザー エクスペリエンスを実現するための手段の 1 つに過ぎませんが、大きな影響を与える可能性があります。まとめると次のようになります。
- ページ上の独自のアセットとサードパーティのアセットをインベントリに登録します。
- 各アセットのパフォーマンス（価値と技術的なパフォーマンス）を測定します。
- リソースが十分な価値を提供しているかどうかを判断します。
- 不要なダウンロードが Core Web Vitals と関連指標に与える影響を理解する。
このようにコンテンツの効率を最適化することで、全体的なパフォーマンスを向上させるだけでなく、ユーザーの帯域幅を浪費しないように注意を払うことができます。また、ユーザー中心の指標を改善し、ユーザー エクスペリエンスを向上させる可能性もあります。