不要なダウンロードを回避する

最速で最も最適化されたリソースは、送信されないリソースです。アプリケーションから不要なリソースを削除する必要があります。暗黙の仮定や明示的な仮定について疑問を投げかけ、定期的に見直すことをおすすめします。いくつか例を示します。

  • あなたは常にリソース X をページに含めていますが、リソース X をダウンロードして表示するコストは、そのリソースがユーザーに提供する価値に相殺されていますか。その価値を測定、証明できるか
  • そのリソース(特にサードパーティ リソースの場合)は一貫したパフォーマンスを実現しているか。このリソースはクリティカル パスにありますか、またはクリティカル パスにする必要がありますか?リソースがクリティカル パスにある場合、サイトの単一障害点になる可能性がありますか?つまり、リソースが利用できない場合、ページのパフォーマンスやユーザー エクスペリエンスに影響しますか?
  • このリソースには SLA が必要か、または適用されていますか?このリソースは、圧縮、キャッシュなどのパフォーマンスのベスト プラクティスに従っているか。

ページに不要なリソースが含まれているか、ひいてはページのパフォーマンスを低下させ、訪問者やホストされているサイトにあまり価値を提供できないリソースが含まれていることがよくあります。これは、ファースト パーティ製とサードパーティ製のリソースおよびウィジェットに同様に当てはまります。

  • サイト A では、ホームページに写真のカルーセルを表示し、訪問者が 1 回のクリックで複数の写真をプレビューできるようにすることにしました。ページが読み込まれるとすべての写真が読み込まれ、ユーザーは写真を読み進めます。
    • 質問: カルーセルに複数の写真を表示したユーザーの数を測定しましたか。ほとんどの訪問者が表示しないリソースをダウンロードすることで、オーバーヘッドが高くなる可能性があります。
  • サイト B では、関連コンテンツの表示、ソーシャル エンゲージメントの向上、その他のサービスの提供を目的として、サードパーティ製のウィジェットをインストールすることにしました。
    • 質問: ウィジェットを使用する訪問者数、またはウィジェットが提供するコンテンツのクリックスルー数を追跡しましたか。このウィジェットが生成するエンゲージメントは、そのオーバーヘッドを正当化するのに十分なものか?さらに、読み込み戦略を使用して、必要になるまでスクリプトが読み込まれないようにすることは現実的ですか?

不要なダウンロードを回避するかどうかを判断するには、多くの場合、慎重に検討し、測定する必要があります。最良の結果を得るには、ページ上のすべてのアセットについて定期的に確認を行い、以下の質問を再検討してください。

Core Web Vitals への影響

Core Web Vitals は、ウェブ利用時のユーザー エクスペリエンスを反映した一連の指標を提供することを目的とした Google のイニシアチブです。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)と First Input Delay(FID)

Interaction to Next Paint(INP)First Input Delay(FID)は、ユーザー入力への応答性を測定する指標です。FID は 2024 年 3 月に Core Web Vitals として INP に置き換わる予定ですが、FID の最適化戦略は INP にも適用される傾向があります。さらに、INP は一般的に FID よりも最適化が難しくなります。これは、FID が測定する最初のインタラクションの入力遅延だけでなく、すべてのページ インタラクションの完全なインタラクション レイテンシがトラッキングされるためです。

INP と FID は、JavaScript の影響を最も受ける傾向があります。JavaScript は、ウェブ全体でのインタラクティビティの大半を占めているからです。INP と FID のどちらも、ページ読み込み時にダウンロードされるスクリプト リソースの量に応じて、スクリプトの評価とコンパイルに関わるコストの高い作業が開始される可能性があります。起動時に読み込む JavaScript が少ないほど、ページ エクスペリエンスの重要なポイントでブラウザが行う作業は少なくなります。

コード分割やツリー シェイキングなど、起動時にダウンロードされる JavaScript リソースのサイズを縮小する戦略もありますが、プロジェクトで使用しているパッケージを監査して、それらが必要かどうかを確認することは価値があります。たとえば、lodash には現在でも有用なメソッドが多数ありますが、マッピング削減フィルタリングその他のための Array 固有の関数など、すぐにブラウザで提供されているメソッドも用意されています。

プログレッシブ エンハンスメントは、JavaScript の有用なアプローチでもあります。これは、より高性能なデバイスと高速なネットワーク接続を使用するユーザーに、ベースラインとなる(ただし機能的な)エクスペリエンスを提供できるからです。プログレッシブ エンハンスメントの原則に従うかどうかに関係なく、ポイントは変わりません。つまり、ダウンロードを回避できる JavaScript リソースはすべて、ウェブ パフォーマンスの重要な側面である、ユーザーの操作に迅速に反応するようになる可能性があるということです。

まとめ

ウェブサイトの不要なダウンロードを監査することは、高速なユーザー エクスペリエンスを提供するための 1 つの側面にすぎませんが、大きな影響を及ぼす可能性があります。まとめると次のようになります。

  • ページに独自のアセットとサードパーティのアセットを用意します。
  • 各アセットのパフォーマンス(価値と技術的なパフォーマンス)を測定します。
  • リソースが十分な価値を提供しているかどうかを判断する。
  • 不要なダウンロードが Core Web Vitals とサポート指標に及ぼす影響を把握する。

このようにコンテンツの効率を最適化することで、全体的なパフォーマンスが向上するだけでなく、ユーザーの帯域幅を無駄にしないように気を配ることができ、ユーザー中心の指標が改善され、ユーザー エクスペリエンスが向上する可能性があります。