ページの重さ
はじめに
インターネットは急速に成長しています。新しいページが作られるたびに、そのコンテンツをレンダリングするために必要なリソース一式がもたらされますが、より多くのコンピューティングリソースが必要とされるため、これは高価なものとなります。これらの帯域幅要求は、ジェネレーティブAIイニシアチブのコンピューティングリソースと競合しています。
米国では、急速に増大するAI需要により、データセンターのエネルギー消費量が2026年には国内総電力使用量の約6%に達すると予測されており、送電網インフラへのさらなる圧力がかかり、継続的なAIの進歩を支えるための持続可能なソリューションの緊急の必要性が浮き彫りになっています。これらのジェネレーティブAIイニシアチブは、ひいてはウェブの規模を急速に増大させるでしょう。Statistaは、2024年に149ゼタバイトのインターネットコンテンツが作成されたと推定しています。比較すると、2010年から2018年までの合計は127.5ゼタバイトでした。
要するに、リソースはますます希少になり、高価になっています。Googleが現在、ページ上の要素を優先しているため、ページの重さの問題に取り組むことが重要になっています。ウェブサイトの不必要な肥大化を減らすことは、ユーザー体験を向上させ、コンバージョンを高めるだけでなく、持続可能性への取り組みもサポートします。
2024年のウェブパフォーマンスに関する議論で強調されているように、重いウェブサイトは、とくにローエンドのデバイスでのユーザーアクセスと応答性の不平等の一因となり、「パフォーマンスの不平等ギャップ」を広げています。Alex Russelのシリーズ、パフォーマンスの不平等ギャップは、現在のデバイスのパフォーマンスと機能に関して行われているいくつかの仮定が真実ではないかもしれないこと、そしてデバイスがますます強力になっている一方で、それがすべての人に当てはまるわけではなく、ペイロードの大きいウェブページによって悪影響を受けるユーザーのロングテールが存在することを鋭く浮き彫りにしています。
この格差の拡大は、すべてのユーザーに公平なアクセスとエンゲージメントを確保するために、軽量で効率的なウェブデザインの重要性を強調しています。不適切なタイミングでネットワーク接続が弱くなった場合でも、インターネットへのアクセスがメガバイト単位で課金される市場に住んでいる場合でも、ページの重さは重要であり、ページの重さが増加すると情報の利用可能性が低下します。
ページの重さはアクセシビリティの問題です
ページの重さが大きいと、最高級のデバイスや高速でデータ使用量の上限が高い接続を利用できないユーザーに不釣り合いな影響を与えます。
肥大化したページは、これらにアクセスできない人々にとって、ウェブの体験がより高価でパフォーマンスの低いものになることを意味し、極端な場合にはページが実質的に使用できなくなることさえあります。
ページの重さとは？
ページの重さとは、ウェブページのバイトサイズのことです。ウェブはその誕生以来、大規模に進化しており、2024年のページの重さは、到着したURLのHTMLだけではありません。ほとんどすべての場合、そのページを読み込んで表示するために必要なアセットが含まれます。これらのアセットには、次のものが含まれます。
- サーバーからの最初のレスポンスで返されるHTML。
- ページに埋め込まれた画像やその他のメディア（動画、音声など）。
- ページをスタイリングするためのカスケーディングスタイルシート（CSS）。
- インタラクティビティと機能性を提供するためのJavaScript。
- 他のプロバイダーからの、上記のうちの1つまたは複数でありうるサードパーティのリソース。
ウェブページに追加されるすべての余分なものは、全体のページの重さを増加させ、すべてのビットは最終的に、ネットワークを介して送信し、処理し、解析し、最終的にユーザーが消費し対話するために画面にレンダリングし描画するという、ブラウザにとってより多くの作業とオーバーヘッドを意味します。
リソースのいくつかの形式は、さらに大きなオーバーヘッドを伴います。とくにJavaScriptは、コンパイルして実行する必要もあります。これは、持続可能性とコンバージョン率の両方に連鎖的な影響を及ぼします。ページが重ければ重いほど、より多くの二酸化炭素排出量が発生し、そのページでのコンバージョン率の可能性は低くなります。
ページの重さが二酸化炭素排出量に与える影響について詳しくは、サステナビリティの章をご覧ください。
ページの重さと、それが読み込み時間に与える全体的な影響を管理するのに役立つさまざまな緩和策がありますが、より重いものは常により多くの作業を伴うという厳しい現実があります。
重さの影響は、ストレージ、伝送、レンダリングの3つの主要なカテゴリに分けることができます。
ストレージ
ウェブページのすべてのバイトはどこかに保存される必要があり、ウェブの仕組みの性質上、それは通常、複数の場所に保存されることを意味します。
それはウェブサーバー自体から始まります。純粋なストレージスペースは、ストレージの種類にもよりますが、ギガバイトあたりのコストは比較的小さいままです。たとえば、Googleのクラウドストレージは、北米では月額0.02ドルから0.03ドル、ヨーロッパでは0.006ドルから0.025ドルです。ウェブサーバーのメモリに保存されたリソースは、ディスク上のリソースよりも高速にアクセスできますが、コストはディスク上のリソースよりもはるかに速く上昇します。
同じリソースの複数のコピーが、多数の中間キャッシュに分散され、エッジキャッシュが採用されている場合は複数のデータセンターに分散されることもあります。
方程式の2番目の部分は、これらのリソースがページにアクセスするときにユーザーのデバイスにも保存される必要があるということです。ローエンドのデバイス、とくにモバイルデバイスは、保持できる量にはるかに制限がある場合があります。大きなペイロードをプッシュすると、ストレージ容量が圧倒され、他の貴重なリソースがキャッシュからパージされる可能性があります。これにより、それらのリソースを再利用したであろう新しいページに移動するときに、追加のコストとパフォーマンスの低下につながる可能性があります。
送信
初めてサイトにアクセスするときは、すべてのリソースをインターネット経由でデバイスに配信する必要があります。同じURLへのその後のアクセス、あるいは同じサイト上の他のURLへのアクセスでさえ、リソースの一部はキャッシュから使用できるかもしれませんが、かなりの量がネットワーク経由で再度取得される必要があるかもしれません。
すべてのネットワーク接続がどこでも同じというわけではありません。非常に高速なブロードバンド接続でデータ制限が寛大である場合もあれば、従量制で上限のある低速なモバイル接続である場合もあります。
したがって、戦略的に考えるのが最善です。ページの重さが大きいほど、リソースの送信に時間がかかり、モバイル接続が遅い、またはデータ制限が低いユーザーがもっとも大きな打撃を受け、ビジネスにも影響を与える可能性があります。
リソースの送信を最適化する最善の方法は、小さなリソースを提供することです。それが難しい場合は、リソースヒント（プリコネクトやプリロードなど）やフェッチ優先度を使用して、ページでリソースが読み込まれる順序を管理できます。
レンダリング
ブラウザが要求されたURLを誰かの画面に描画する前に、それらのリソースを収集して処理する必要があります。
ページの重さが大きいほど、ブラウザが必要なすべての部分を取得して処理するのに時間がかかり、ユーザーがページを読んで対話できる時点が遅れます。
読み込み後でも、過度のページの重さは、ブラウザが大きなリソースをシャッフルするのに手間取っているため、ページの対話への応答が遅くなる可能性があります。
数字で見るページの重さ
インターネットは、裸のテキストの場所から、今日私たちが知っている豊かでインタラクティブな風景へと、新しいコンテンツタイプを導入することによって開花しました。画像は視覚的な深みをもたらし、Javascriptはインタラクティビティを可能にし、動画はストーリーテリングの新しい方法を導入しました。
これらの各テクノロジーは、ページにより多くの重みをもたらしました。1995年にHTML 2.0が導入される前は、重み付けされる唯一のアセットはHTMLでした。RFC 1866が<img>タグを導入したとき、ページの重さは劇的に増加しました。1996年には、JavaScriptがスケールに乗り、10年後にはJQueryのようなライブラリが続きました。2010年には、広く認識された最初の単一アプリケーションフレームワークが登場し、Angular、React、VueなどのJavaScriptフレームワークが市場に参入する道を開きました。
ページの機能が進化するたびに、機能を維持しながらパフォーマンスを向上させることを目的とした、より多くの重みとファイルタイプがもたらされます。
一般的なファイルタイプ、その出現頻度、および応答サイズを分析して、その適用をよりよく理解しました。これには、デバイスおよびページタイプ別の比較が含まれます。
中央値ページのファイルタイプリクエスト
ページの重さに関連するファイルタイプを理解するには、ページの50パーセンタイルのファイルタイプリクエストを見る必要があります。これにより、各ファイルタイプが全体に与える影響のベースラインが提供されます。
デスクトップページのリクエスト総数は9%減少し、2022年のページあたり76リクエストから71に減少しました。同様に、モバイルは70から66リクエストに減少しました。画像ファイルタイプの数は2024年に43%減少しました。
デスクトップページは2024年に18枚の画像をリクエストしましたが、2022年には25枚でした。
Javascriptは、もっともリクエストされたファイルタイプとして画像を追い抜きました。中央値のページは、デスクトップページで24のJavascriptリソースをリクエストしました。モバイルでは22のリクエストがありました。
ページの重さの行動パターンを分析し始めると、内部ページの影響に注意することが重要です。この章全体を通して、ホームページと内部ページを比較した場合にのみ表示される強い差異が見られます。
これは、新しいデータがデバイスタイプの比較を変更するため、注目に値します。これを念頭に置いて、2022年のデータセットに対してより正確な測定値を得るために、ホームページにフィルタリングされた比較も含まれています。
リクエスト量
ページが行う各リクエストは、意図したエクスペリエンスとコンテンツを作成するために必要なコンポーネントです。リクエストの総数、ビルドを完了するために必要なピースの数は、ページのパフォーマンスに影響します。
最新のブラウザはマルチスレッドおよびマルチプロセスです。これは、ネットワークリクエストを含むさまざまなタスクを処理するために複数のスレッドとプロセスを利用できることを意味します。各リクエストは実行にリソースを必要とし、技術的な制限により、同時に完了できるリクエストの数は限られています。人間と同様に、ブラウザも一度にできることは限られています。
この知識があれば、リクエストの数がページの重さと知覚されるパフォーマンスの両方に影響することがわかります。
中央値のページは、デスクトップで71件、モバイルで66件のリクエストを行います。これらの数値には、ホームページと内部ページの両方が含まれます。2022年の分布と比較すると、すべてのパーセンタイルでファイル総数が減少しています。
全体的に低い数値は、ホームページと比較して内部ページからのリクエスト数が一貫して少ないことによって影響を受けます。中央値のホームページは72のリソースを呼び出しますが、その内部の対応物は65しか必要としません。
データの整合性のためにホームページのみを分析した場合、2024年の総リクエスト数はわずかに減少しましたが、2022年のレートと一致していました。中央値のデスクトップホームページは2022年に76のリソースをリクエストし、現在は74をリクエストしています。モバイルの中央値は変更されていません。
画像
画像は、ウェブページを構築し表示するために不可欠な静的ファイルです。ウェブがますます視覚的になるにつれて、パフォーマンスを向上させるテクノロジーとアセットのバイトサイズのバランスをとる必要性を例示しています。
2022年には、中央値のページでデスクトップ用に25枚、モバイルページ用に22枚の画像がリクエストされました。これはデスクトップで18枚、モバイルで16枚に減少しています。
画像ファイルタイプの減少は、ウェブが視覚的でなくなったことを意味するわけではありません。代わりに、サイトはCSS効果（シャドウやグラデーションなど）やCSSアニメーションに切り替えている可能性があります。これらのアセットは、解像度に依存しないアセットを生成するために使用でき、すべての解像度とズームレベルで常にシャープに見え、多くの場合、画像ファイルに必要なバイト数のほんの一部で済みます。
デスクトップページは一貫してより多くの画像ファイルタイプを要求し、デスクトップとモバイルの間のギャップはパーセンタイル全体で着実に一貫して拡大しています。ホームページと内部ページの差は比較すると顕著でした。デバイスタイプが比較的一貫した数値を示したのに対し、中央値のホームページは20枚の画像を呼び出したのに対し、内部ページはわずか14枚でした。
CSS
CSS、またはカスケーディングスタイルシートは、HTMLのようなマークアップ言語で書かれたドキュメントのプレゼンテーションを記述するために使用されるスタイルシート言語です。言い換えれば、CSSはウェブページの視覚的なスタイリングとレイアウトを担当します。
開発者は、HTML要素の色、フォント、サイズ、間隔、その他多くの視覚的側面を制御できます。CSSはHTMLと連携して機能し、コンテンツとプレゼンテーションを分離します。
この分離により、ウェブページはより保守しやすく、柔軟で、応答性が高くなり、バイト数の多い画像アセットをCSS効果やアニメーションに置き換えることで、サイトのパフォーマンスを向上させるために使用できます。
CSSは、デバイスやページの種類を問わず、ウェブ開発者のツールキットに不可欠なツールです。中央値のデスクトップページとモバイルページはどちらも8つのCSSアセットを要求しました。パーセンタイルは、75番目の名目上の差異を除いて同一でした。
ホームページと内部ページを比較すると、90パーセンタイルまでホームページが一貫して1つ少ないカスケーディングスタイルシートを呼び出していることがわかりました。100パーセンタイルでは、内部ページが3,346件のリクエストに対して4,879件のリクエストで逸脱していることがわかりました。どちらも高いですが、内部ページは46%高くなっています。
JavaScript
JavaScriptは、高水準で動的なインタプリタ型プログラミング言語です。ウェブのコアテクノロジーの1つであり、インタラクティブなウェブページやウェブアプリケーションを可能にします。JavaScriptを使用すると、開発者はウェブページにインタラクティビティ、アニメーション、エフェクトを追加できます。これには、ドロップダウンメニュー、画像スライダー、パーソナライズされたコンテンツ、分析トラッキングなどの機能が含まれます。
すべてのモバイルホームページの97.8%、内部ページの98.5%でクライアントサイドのプログラミング言語として使用されています。
2024年には、JavaScriptが画像を抜いて主要なファイルタイプになりました。中央値のページでは、デスクトップ用に24個、モバイルページ用に22個のJSファイルがリクエストされました。これは、2022年と比較してデスクトップで8%、モバイルで4.5%増加しています。JavaScriptのリクエスト数は、90パーセンタイルまで内部ページとホームページで一貫していました。
100パーセンタイルでは、デスクトップページとホームページがリクエスト数で対応するものから離れました。デスクトップページは33%多くのリクエストを行い、ホームページは31%多くなりました。デスクトップホームページは12,676のJavaScriptリソースをリクエストしました。コメントを求めてページに連絡を試みましたが、公開時点でリクエストはまだ読み込み中でした。
2024年にJavaScriptがどのように使用されているかについて詳しくは、JavaScriptの章をご覧ください。
サードパーティサービス
サードパーティのリソースとは、ウェブページやアプリケーションに統合されているが、別のプロバイダーによってホストおよび維持されている外部のアセットやサービスのことです。これらのリソースには、JavaScript、CSS、フォント、分析ツールなどが含まれます。サードパーティの章によると、ページの92%に1つ以上のサードパーティリソースがありました。もっとも多く呼び出されたサードパーティリソースはスクリプトで、コンテンツタイプ別のリクエストの30.5%を占めていました。著者らはまた、下位ランクのウェブサイトではサードパーティの数が大幅に減少していることにも言及しています。
詳細については、サードパーティの章を参照してください。
その他のアセット
ウェブページは、コード、スタイル、画像だけでなく、さまざまな他のアセットやリソースを利用できます。これらの追加アセットは、ウェブページの全体的な機能性、インタラクティビティ、視覚的な魅力に貢献し、HTML、CSS、JavaScriptと調和して完全なユーザーエクスペリエンスを作成します。
HTML
HTML、またはハイパーテキストマークアップ言語は、ウェブページを作成および構造化するために使用される標準のマークアップ言語です。見出し、段落、リスト、リンク、画像などの要素を定義し、ウェブサイトのコンテンツとレイアウトの基盤を提供します。HTMLは、一連のタグと属性を使用して、ウェブページのコンテンツのセマンティックな意味と視覚的なプレゼンテーションを記述します。
1つのウェブページに複数のHTMLリクエストが含まれる理由はいくつかあります。
- 埋め込みリソース: ウェブページは通常、HTMLドキュメントだけでなく、画像、CSSファイル、JavaScriptファイル、フォントなどの追加リソースも読み込みます。これらの外部リソースはそれぞれ、そのコンテンツを取得するためにサーバーへの個別のHTTPリクエストをトリガーします。
- 動的に読み込まれるコンテンツ: 一部のウェブページでは、JavaScriptを使用して、最初のページ読み込み後に追加のコンテンツやデータを動的に読み込みます。これには、無限スクロール、AJAXを利用したコンテンツの更新、要素の遅延読み込みなどが含まれます。これらの動的リクエストは、最初のHTMLドキュメントリクエストに加えて行われます。
- プリロード/プリフェッチ: ウェブ開発者は、
rel="preload"またはrel="prefetch"を持つ<link>タグを含めて、ブラウザに特定のリソースを実際に必要になる前に事前に積極的に取得するように指示することがあります。これにより、知覚されるパフォーマンスが向上します。 - エラー処理: リソースの読み込み中にネットワークエラーやサーバーの問題が発生した場合、ブラウザはリクエストを再試行し、同じコンテンツに対して複数のリクエストが発生します。
中央値のページは2つのHTMLリクエストを行い、これはデバイスやページの種類を問わず一貫していました。90パーセンタイルでは、12のHTMLリクエストが見られました。100パーセンタイルでは、デスクトップのホームページが13,389件のリクエストを行い、その数は劇的に急増しました。
フォント
中央値のページは4つのフォントファイルを要求しました。90パーセンタイルまで、フォントリクエストはデバイスやページの種類を問わずかなり低く、一貫していました。100パーセンタイルでは、デスクトップのホームページが3,038個のフォントを要求していることがわかりました。この量のフォントリクエストから、このサイトはフォントリポジトリまたは身代金要求ジェネレーターであると推測されます。
リクエストバイト
中央値のページの重さを経時的に比較すると、残念ながらほぼ同じペースで増加し続けていることがわかります。中央値のページの重さは、経時的な比較で示されるように、依然としてほぼ同じペースで増加しています。
2024年10月に測定されたデスクトップページの中央値のページの重さは2,652 KBで、モバイルはそれよりわずかに低いものの、依然として重い2,311 KBです。
2022年の章と比較すると、両方の数値は高く、中央値のデスクトップページは2,312 KB、モバイルは2,037 KBでした。2024年のモバイルページは、2022年のデスクトップページよりわずか1 KB軽いです。2024年10月、デスクトップページの中央値のページの重さは2,652 KBでしたが、モバイルページの中央値のページの重さは2,311 KBでした。
これらの数値はどちらも2022年のものより高くなっています。2022年、デスクトップページの中央値のページの重さは2,312 KB、モバイルページの中央値のページの重さは2,037 KBでした。注目すべきは、2024年のモバイルページの重さは2022年のデスクトップページの重さよりわずか1 KB軽いだけであることです。
前年比で比較すると、2023年10月から2024年10月にかけて、デスクトップは8.6%（210 KB）、モバイルは6.4%（140 KB）増加しました。
中央値のデスクトップページは過去10年間で120%、つまり1.4 MB増加しました。中央値のモバイルページは同期間で357%、つまり1.8 MBというより大幅な増加を遂げています。これは、モバイルページに3.5インチフロッピーディスク1枚分以上のデータを追加することに相当します。
前年比では、2023年10月から2024年10月にかけて、デスクトップは8.6%（210 KB）、モバイルは6.4%（140 KB）増加しました。
ウェブデータの最終的なユーザーへのコストを計算するためのウェブベースのツールであるWhat Does My Site Cost?によると、中央値のデスクトップページはユーザーに最大0.32米ドルの費用がかかる可能性があり、一部の地域では国民総所得の最大1.7%に達する可能性があります。
コンテンツタイプとファイル形式
動画を除き、ホームページの主要なリソースタイプは画像です。画像を使用する中央値のデスクトップページは1,054 KBを要求し、モバイルページは900 KBを要求します。これは、デスクトップページが1,026 KB、モバイルページが900 KBを要求した2022年からわずかに増加しています。
JavaScriptはページの重さに2番目に大きく貢献しており、中央値のデスクトップページは613 KB、モバイルページは558 KBを提供しています。画像と同様に、これらは両方とも2022年の章からの成長を表しており、デスクトップページでは509 KB、モバイルページでは461 KBでした。
モバイルページとデスクトップページの両方で、内部ページは画像のバイト数が少なく、JavaScriptのバイト数がわずかに多い傾向があります。
この新しい分析はまた、以前考えられていたように、画像が常にページの重さの最大の構成要素であるとは限らないこと、そして内部ページではJavaScriptがその疑わしい名誉を代わりに得たことを示しています。
画像は全体としてページの重さに最大の貢献者かもしれませんが、リクエストごとのサイズを見ると、動画が先頭に立ち、次にフォント、そしてWebAssembly (wasm)ファイル（2022年には検出されなかった）が続きます。2022年の分析では、音声が2番目に重かったですが、今年は画像の背後に4番目に後退しました。
JavaScriptバイト
JavaScriptファイルの重さの増加は、パフォーマンスにさらなるペナルティをもたらします。純粋なサイズが考慮されるだけでなく、ブラウザはJavaScriptを解析して実行する必要があり、これはとくにローエンドのデバイスではコストのかかるプロセスになる可能性があります。
デスクトップページはモバイルページよりも多くのJavaScriptバイトを要求する傾向がありますが、中央値のデスクトップページは620 KBのJavaScriptを要求し、モバイルページは570 KBで、その差は大きくありません。
Alex Russellのパフォーマンスの不平等ギャップ、2024年の調査によると、これらはしかし、75パーセンタイルで3秒未満のページ読み込みという提案された目標である365 KBをはるかに上回っています。
75パーセンタイルでは、モバイルとデスクトップの両方が、5秒の読み込み時間を達成するための提案された650 KBの予算をはるかに超えており、それはJavaScriptの多いページであり、マークアップがそれに応じて小さいと仮定した場合です。
ホームページと内部ページのJavaScriptファイルの応答サイズには大きな違いはありません。内部ページは50パーセンタイルまで少し多くのJavaScriptを持っていますが、それ以上ではホームページの方が多くなる傾向があります。
これは、開発者がすべてのページですべて、またはほとんどのJavaScriptリソースを読み込んでいる機会があることを示している可能性があり、ツリーシェイキングによって全体的に必要なJavaScriptを削減する機会を表しています。これは、JavaScriptファイルをより具体的なものに分割し、必要なときにのみ読み込む方法であり、したがってダウンロードされる無駄なJavaScriptバイトを削減します。
CSSバイト
CSSのサイズは、すべてのパーセンタイルでデスクトップの方がモバイルよりもわずかに大きく、ホームページと内部ページの間にはほとんど差がありませんでした。
これは、一般的に採用されている方法が、すべてのデバイスとページタイプに対して1セットのCSSであることを示しています。これは、上記のJavaScriptと同様に、ツリーシェイキングによって全体的に必要なCSSを削減する機会を逃している可能性を指摘していますが、CSSではキャッシュとビルドツールの機能をバランスさせるという、常により微妙な問題があります。
全体として、76KBのCSSファイルは、期待するよりも少し大きいように見えますが、過度に大きいわけではありません。しかし、CSSファイルの最適なサイズは、可能な限り小さいものであることを覚えておいてください。うまくいけば、人々がそれをすべてヘッドにインラインで詰め込んでいるわけではないことを願っています。
画像バイト
過去のページの重さの章では、画像は常に全体のページの重さに最大の貢献者でしたが、2024年の新しい内部ページのデータは、それがホームページに特有の傾向であることを示していますが、それでも全体として大きな構成要素を表しています。
中央値のデスクトップホームページは1,054 KBの画像を読み込んでおり、モバイルは少し軽い900 KBです。前述のとおり、これは2022年のデスクトップページが1,026 KB、モバイルが900 KBだったのに比べて依然として増加しています。75パーセンタイルに達すると、事態はすぐに膨れ上がり、デスクトップでは2,822 KB、モバイルでは2,517 KBの画像になります。
実際、中央値以上では、すべてのパーセンタイルが2022年の章よりも大きかったですが、より肯定的な発見は、10番目と25番目では、画像のバイト数が前の章からほぼ安定しているか減少していることであり、これはすでに画像ファイルサイズの最適化を行っていた開発者がそれを継続しており、少しずつ上手になっている可能性があることを示しています。
また、開発者がページの重さへの影響を減らすことにもっとも集中しているように見えるのが、ページの重さがもっとも高いペナルティを伴う可能性があるモバイルユーザー向けであることも喜ばしいことです。これは、人々がレスポンシブ画像配信を使用しているためかもしれません。
ホームページと内部ページを見ると、デスクトップとモバイルの両方でホームページの方が画像バイト数が多いという明確な傾向があり、中央値のデスクトップページはホームページで1,054 KB、内部ページで442 KB、モバイルではホームページで900 KB、内部ページで348 KBです。デスクトップとモバイルの両方で、中央値の内部ページはホームページの半分の画像バイト数しかありません。
JPG、WebP、PNGファイル形式は、2022年の画像の重さのトップソースとしての地位を維持しています。ウェブでの画像形式の使用に関する詳細については、メディアの章をご覧ください。
動画バイト
動画には多くのデータが含まれており、動画の1秒ごとに多くの画像、つまりフレーム、そして多くの場合音声も含まれています。そのため、ページの重さを大幅に増加させる可能性があります。
最新のフォーマットはこれを圧縮して縮小するのに役立ちますが、ある時点でファイルサイズと品質の間にトレードオフが生じます。
そのトレードオフを正しく行い、動画やその他の埋め込み用のファサードなどの他のテクニックと組み合わせることで、影響を可能な限り減らすことができます。
中央値のページは、デスクトップユーザー向けに194 KBの動画を要求し、驚くべきことにモバイルユーザー向けにはより大きな299 KBを要求します。実際、その傾向は25パーセンタイル以降に存在しており、これはモバイルデバイスがページの重さの削減からもっとも恩恵を受ける可能性が高いことを考えると、残念な傾向です。
ホームページは内部ページよりも動画リソースのペイロードが大きいことがわかり、中央値のホームページはデスクトップで243 KB、モバイルデバイスで410 KBの動画リソースを要求しています。内部ページはデスクトップで144 KB、モバイルデバイスで188 KBと低くなっています。
これは、開発者がサイトやビジネス全体に焦点を当てる傾向があるホームページに動画の「ヒーロー」セクションを使用したり、そうでなければ動画を埋め込んだりすることを好むことを示している可能性があります。一方、内部ページは、おそらくカテゴリやリスティングページ、個々の記事や製品など、より焦点を絞ったページである可能性が高いです。
バイト節約技術の採用率
ページの重さを減らすためにできることはいくつかあります。最初の1つは、テクノロジーというよりはアプローチであり、表面的には非常に単純です。必要のないものを送らないでください。
これは、ページに追加するもの、出荷するものに注意を払うべきであることを意味します。要するに、追加しているものがページのユーザーとページが満たす必要のあるビジネスケースに本当に価値を付加しているかどうかを確認する必要があります。
しかし、目的はすべての機能を削除することではなく、むしろ、追加しているものが価値を付加していることを確認することです。
貴重なコンテンツをより効率的な方法で配信するのに役立つこれらのパターンとアプローチのいくつか、そしてそれらがどのくらいの頻度で実装されているかを見てみましょう。
動画やその他の埋め込み用のファサード
動画、ソーシャルメディアの投稿、その他のインタラクティブな埋め込みなどのサードパーティの埋め込みは、ページの重さを大幅に増加させる可能性があります。動画や投稿の共有ボタンをクリックして、コードをページに貼り付けるのは簡単ですが、それに伴う巨大なペイロードに完全に気づいていない場合があります。
動画にはかなりのバイト数があると予想されるかもしれませんが、ライブチャットウィジェットの埋め込みや、ツイートのようなソーシャルメディアの投稿でさえ、かなりのオーバーヘッドを伴う可能性があり、いいねボタンをクリックしたり再共有したりするなどのインタラクティビティを有効にするために驚くほどの量のJavaScriptを読み込みます。
良い妥協案となりうる1つのデザインパターンは、インタラクション時のインポートとしても知られるファサードを使用することです。この基本的な原則は、埋め込みのグラフィカルまたは単純な非インタラクティブな表現を使用し、ユーザーがそれをクリックした場合にインタラクティブな完全な埋め込みになるというものです。
動画の場合、それは多くの場合ポスター画像を表示し、クリックすると完全な埋め込みが読み込まれます。ソーシャルメディアの投稿の場合、スタイル設定されたHTML、または動画ソリューションのように、ユーザーが投稿をクリックすると完全なインタラクティビティが読み込まれる画像のいずれかになります。
最終的に、ユーザーが対話すると、より大きなペイロードを読み込む必要がありますが、多くのユーザーが対話したり、動画を視聴したり、カスタマーサービスや営業とライブチャットを開始したりしたくない場合に節約が生まれます。そのコストを支払うユーザーは、積極的に機能を使用したいユーザーです。
ファサードの使用にはいくつかの欠点があります。これらは、web.devのサードパーティファサードの記事で詳しく説明されています。しかし、最終的に、このアプローチは全体のページの重さを大幅に節約するのに役立ちます。
ファサードの採用状況を調べるには、Lighthouseに目を向けることができます。Lighthouseは、ファサードを使用してサードパーティのリソースを遅延読み込みする監査を提供しており、ページに埋め込まれている特定可能なリソースの中に、ファサードを使用する機会があるかどうかを確認できます。
採用を判断することは、全体として困難です。なぜなら、ファサードを実装しているサイトを確実にテストすることはできないからです。解決策には、ページが探しているリソースを読み込まなくなることが含まれるため、潜在的に利益を得られる可能性のあるサイトを見ることの方が有意義です。
デスクトップホームページの70%が、一部の埋め込みをファサードに置き換える機会があると検出されました。デスクトップの内部ページでは65%でした。モバイルクロールでは、状況はここでより良く、モバイルホームページの45%、モバイル内部ページの46%が潜在的に恩恵を受ける可能性があります。
データから、モバイルクライアントに提供されるページでの採用率が高いか、開発者やパブリッシャーがモバイルユーザー向けのサードパーティ埋め込みの種類を省略しているかのどちらかであるように思われます。
ファサードは2022年の前回のアルマナックページの重さの章で取り上げられましたが、テストは過去2年間でわずかに変更され、データを分析するために使用した方法論も変更されたため、直接比較はできません。
圧縮
圧縮を使用すると、リソースをネットワーク経由で要求元のクライアントに送信する前にサイズを縮小できます。クライアントでは、ウェブページの場合は通常ブラウザですが、使用前に解凍されます。理論上、そして通常は実際には、ペイロードが小さいほどページの読み込みが速くなります。
HTML、CSS、JavaScript、JSON、SVG、ico、ttfフォントファイルなどのテキストベースのファイルの場合、HTTP圧縮は送信されるページの重さを減らす強力な味方です。GZIPまたはBrotli圧縮を使用すると、テキストベースのリソースのサイズを大幅に削減できる場合があります。画像や動画などの他のファイルタイプは、すでに圧縮されているため、HTTP圧縮の恩恵を受けません。
デスクトップホームページの70%、および基本的に同様の71%の内部ページがテキスト圧縮を正しく使用していることを検出しました。ホームページの数値は、2022年の74%からの低下を表しています。
モバイルクロールでは、ホームページの71%と内部ページの72%がテキスト圧縮を正しく使用していました。ホームページを2022年と比較すると、これも73%からの低下を表しています。
使用率の低下は、おそらく小さいものの、残念です。圧縮を有効にすることが難しくなったわけではなく、おそらく簡単になりました。とくにCloudflareのようなCDNを使用している場合は、ダッシュボードでスイッチを切り替えるだけで済みます。
圧縮は完全に魔法ではなく、クライアントにとってこれらのリソースのページの重さの影響を完全になくすわけではないことに注意してください。最終的には、使用前に再度解凍する必要があります。
また、完全に無料のプロセスでもありません。サーバーでこれらのリソースを圧縮するには作業が必要であり、可能な場合は圧縮されたリソースをキャッシュすることで多少軽減できます。また、クライアントでそれらを解凍するにも作業が必要です。
しかし、トレードオフとして、通常は行う価値があります。圧縮技術は一般的に十分に最適化されており効率的であり、主要なボトルネックはネットワークです。
最小化
最小化は、スペース、リターン、コードコメントなど、ブラウザがリソースを使用するために必要のない不要な文字を削除することで、リソースの全体的なサイズを縮小できます。
圧縮とは異なり、クライアント側で追加の作業を行う必要はなく、リソースを解凍する必要はありません。リソースがオンザフライで最小化される場合、サーバー側で多少のオーバーヘッドと作業が発生する可能性がありますが、多くの場合、CSSリソースを事前に最小化するのが最善です。それらは本質的に静的である可能性が高く、多くの場合、ビルド時に実行できます。
2024年には、ホームページの62%がCSSを正しく最小化しており、Lighthouseによって検出されました。これは、2022年の84%から大幅に低下しています。モバイルホームページでは63%で、2022年の68%から低下し、内部ページはわずかに低い62%でした。
2024年には、デスクトップホームページの58%がJavaScriptを正しく最小化しており、Lighthouseによって検出されました。これは、2022年の77%から大幅に低下しています。内部ページはわずかに悪く、57%でした。モバイルでは、ホームページの59%がこのテストに合格し、2022年の64%から低下しました。デスクトップと同様に、内部ページはわずかに悪く、58%でした。
このテストに合格するサイトの方が多いことは依然として心強いですが、2024年にはCSSとJavascriptの両方の最小化が2022年よりも普及していないことは非常に残念です。
キャッシュとCDN
キャッシュとCDNの使用は、ユーザーへのリソース配信に必要な時間を最小限に抑えることでページの読み込み時間を短縮するのに役立つため、ページの重さを管理する上で役割を果たします。ただし、CDNはページの重さを減らすわけではないことに言及する価値があります。
リソースには、静的および動的の両方、ならびにパーソナライゼーション、サードパーティの統合、エッジコンピューティングが含まれます。
一方では、サーバーとブラウザの両方で使用されるキャッシュにより、リソースを再利用できます。キャッシュされたコンテンツは、地理的に分散された一連の相互接続されたサーバーであるCDNを介して送信され、リソースを要求するサーバーと提供されるリソースの間の距離を短縮します。これは、国際的なウェブサイトにとってとくに重要です。
CDNに関する詳細については、CDNの章を参照してください。
ページの重さとCore Web Vitals
Core Web Vitalsは、「パフォーマンス」という危険なほど曖昧な定義を人間中心の測定に洗練させるために設計された一連のパフォーマンスメトリックです。「良い」ページであるためには、ページはユーザーにとって重要な瞬間を測定する3つの評価に合格する必要があります。
- 読み込み中ですか？ (Largest Content Paint (LCP))
- ユーザーは対話できますか？ (Interaction to Next Paint (INP))
- 視覚的に安定していますか？ (Cumulative Layout Shift (CLS))
Core Web Vitalsは、進化する一連のメトリックとして設計されています。今年、インタラクティビティのメトリックがFirst Input Delay (FID) からInteraction to Next Paint (INP) に変更されました。この変更は、2つの重要な進歩をもたらしたためです。
- 1つ目は、単一のインタラクションからページのすべてのインタラクションを含むようにシフトすることです。言い換えれば、マウスでのクリック、タッチスクリーン付きデバイスでのタップ、物理キーボードまたは画面キーボードでのキーの押下です。
- 2つ目は、JavaScriptが主にインタラクティビティを駆動することが多いため、JavaScriptフレームワークを使用するサイトのインタラクティビティを正確に表現することです。
INPで測定された応答性が200ミリ秒未満の場合、それは良い体験と見なされ、INPパフォーマンス評価に合格します。Total Blocking Timeはラボデータの同等物として残り、INPの問題が検出された場合の診断用です。
2023年3月の切り替えでは、多くのJavaScriptフレームワークのオリジンが「良い」分類に合格しなくなりました。React、Next、Nuxt、Vueなどの著名なフレームワークを使用するサイトがもっとも大きな打撃を受けました。サイトは迅速に適応し、2024年9月までに、INPで評価された場合の合格オリジンの数は、FIDメトリックが使用された場合の数を上回りました。
データを収集するために、LCPとCLSをキャプチャするが、INPまたはFIDのインタラクションベースのメトリックはキャプチャしない、Lighthouseのラボテスト監査に頼らなければなりませんでした。ラボテストには欠点があり、web.devのラボデータとフィールドデータが異なる理由（およびそれについて何をするか）で詳述されているように、パフォーマンスを真に評価するには常に実際のユーザーメトリックを使用する必要があります。
2024年6月のデータを使用しました。各パーセンタイルとデバイスタイプのページの重さは次のとおりです。
| パーセンタイル | デスクトップページの重さ | モバイルページの重さ |
|---|---|---|
| 10番目 | 549 KB | 471 KB |
| 25番目 | 1,138 KB | 995 KB |
| 50番目 | 2,157 KB | 1,938 KB |
| 75番目 | 4,169 KB | 3,766 KB |
| 90番目 | 8,375 KB | 7,680 KB |
Largest Contentful Paint (LCP)
Largest Contentful Paintの良いスコアは2.5秒以下です。4秒を超えるLCPは不良と見なされます。
ページの重さとLargest Contentful Paintの間には明確な相関関係があり、ページの重さが高いほど、LCPまでの時間が長くなります。これは、はるかに急な曲線を持つモバイルデバイスにとくに当てはまります。
Cumulative Layout Shift (CLS)
Cumulative Layout Shiftの良いスコアは0.1以下です。0.25を超えるCLSは不良と見なされます。この特定のメトリックを見るときに留意すべき点の1つは、CLSがページの全期間にわたって効果的に測定されるため、ラボデータとフィールドデータの違いにくに影響を受けることです。これには、インタラクションやスクロールが含まれますが、ラボテストでは最初の読み込みしかキャプチャできません。
LCPと同様に、CLSもページの重さが増加するにつれて増加しましたが、デスクトップとモバイルの違いはより線形でした。CLSは直接的な読み込み時間の問題ではないため、これは最適化が不十分で広告の多いページがコンテンツに広告を挿入し、コンテンツを押し下げたり、寸法の定義されていない大きなファイルサイズの画像が原因である可能性があります。
合計ブロック時間
前述のように、Interaction to Next Paint、あるいは古いFirst Input Delayでさえ、ラボテストでは正確に測定できません。しかし、web.devの推奨どおり、Total Blocking Time（TBTと略されることが多い）は、インタラクティビティがどのように影響を受けるかを確認するための良い代理メトリックになります。
200ミリ秒以下の合計ブロック時間は、良い目標と見なされます。
合計ブロック時間で測定した、ページサイズが大きいほどパフォーマンスに悪影響を与えるという傾向は、モバイルとデスクトップの両方のエクスペリエンスで明らかです。しかし、その格差はモバイルユーザーにとってとくに大きいです。50パーセンタイルでは、Time to First Byte (TBT) はデスクトップで53ミリ秒、モバイルで1,235ミリ秒で、1.2秒の差があります。この格差は90パーセンタイルでさらに顕著になり、TBTはデスクトップで648ミリ秒、モバイルでは驚異的な5,786ミリ秒で、実に5.1秒もの差があります。
インタラクティビティは、過度のページの重さに関連するもっとも悪影響を受けるメトリックの1つであると結論付けるのは妥当です。
2024年のCore Web Vitalsに関する詳細データについては、パフォーマンスの章をご覧ください。
結論
ページの重さという増大する問題は、機能性とアクセシビリティのバランスの必要性を反映しています。
JavaScriptフレームワークやリッチメディアなどの進歩は、ウェブのインタラクティビティとストーリーテリングを強化しましたが、同時に重大な課題ももたらしました。肥大化したページは、限られたデバイスや低速な接続を持つユーザーに不釣り合いな影響を与え、ウェブ体験を包括的で公平なものではなくなります。
残念ながら、今年のデータは、モバイルとデスクトップの両方のユーザーでページの重さが増加し続けるという同じ傾向を示しています。
軽量で効率的な設計に焦点を当て、圧縮、キャッシュ、バイト節約技術などの慣行を採用することで、開発者は「パフォーマンスの不平等ギャップ」を埋め、ウェブがすべての人にアクセス可能であり続けることを保証できます。
最終的に、このアプローチはユーザーに利益をもたらすだけでなく、ウェブの持続可能性と長期的な成長もサポートします。
全体として、2024年のページの重さは「解決済みの問題」とはほど遠いですが、開発者がバイト節約の技術やテクノロジーを受け入れる機会はまだたくさんあり、ファサードや圧縮などの採用の余地は十分にあります。これにより、私たち全員にとってより軽く、より明るいウェブが実現します。
