パフォーマンス
はじめに
ウェブパフォーマンスとは、ウェブページがどれだけ速くスムーズに読み込まれ、ユーザーの操作に反応するかを指します。パフォーマンスは、特にさまざまなデバイスやネットワーク環境でウェブが使用される中で、エンゲージメント、リテンション、全体的な信頼感を形成する上で重要な役割を果たします。速くレスポンシブに感じられるページは探索や継続的な利用を促す一方、遅かったり予測不可能な体験はフローを妨げ、信頼感を低下させます。したがって、パフォーマンスに影響する要因を理解することは、エンドユーザーにとって信頼できると感じるウェブ体験を構築するために不可欠です。
ウェブパフォーマンスの計測には、実際の環境でページがどのように読み込まれ、レンダリングされ、ユーザー入力に反応するかを表す広範な指標が含まれます。デバイス、ネットワーク、実行の制約により、ウェブが常に瞬時に感じられるとは限りません。そのため、パフォーマンスは速度だけでなく、処理が進んでいる間の体験の感触にも関係します。コンテンツが読み込まれる間に明確なフィードバックを提供し、レイアウトを視覚的に安定させることで、ユーザーはページの動作を理解し、ウェブサイトを操作する際にコントロールしている感覚を得られます。
これらの考慮事項が、Core Web Vitalsと呼ばれるユーザー中心のパフォーマンス指標の開発と採用に影響を与えました。具体的には、読み込みパフォーマンス、応答性、視覚的安定性の主要な側面を捉えるLargest Contentful Paint（LCP）、Interaction to Next Paint（INP）、Cumulative Layout Shift（CLS）です。過去1年間で、Core Web VitalsのうちLCPとINPの2つについて、報告のサポートがChrome以外のブラウザにも拡大され、ブラウザエンジン間でユーザー体験をより一貫して計測できるようになりました。
これらの指標は、Time to First Byte（TTFB）やFirst Contentful Paint（FCP）などの従来の指標、およびページリソースの読み込み動作の計測によって補完されています。これらの広範なシグナルの集合は、パフォーマンスのボトルネックがどこで発生しやすいか、そしてそれが全体的なページ動作とどのように関係するかを説明するのに役立ちます。最新のウェブパフォーマンス指標のより包括的な概要はweb.devで確認できます。
このパフォーマンスチャプターでは、デバイスとネットワーク環境をまたいで大規模にこれらのシグナルを調査し、ウェブパフォーマンスの現状をデータに基づいた視点で提供します。実際のデータを分析することで、ウェブが改善されている箇所、課題が残る箇所、そしてより良いユーザー体験と関連するパターンを明らかにします。今年の分析には、Early HintsやSpeculation Rulesなどの新興パフォーマンス機能も含まれています。
データソースと方法論
この章は、HTTP ArchiveとChrome UX Report（CrUX）のデータをもとに、ラボベースの計測と実ユーザーのパフォーマンスデータを組み合わせています。HTTP ArchiveはWebPageTest経由でChromeベースのページ読み込みデータを収集し、制御された条件下でのページ動作についての詳細な洞察を提供します。一方CrUXは、Chromeユーザーから収集した実際のユーザー体験を反映しています。主な分析は2025年7月の計測に基づいており、ウェブ上の数百万のウェブサイトと大量のページ読み込みを対象としています。データ収集と方法論の詳細は方法論で確認できます。
Core Web Vitalsの概要
Core Web VitalsはGoogleが実際のユーザーにウェブページがどのように感じられるかを理解するための主要な指標です。以下の条件を満たすページが「良好」と見なされます：
- Largest Contentful Paint（LCP）: メインコンテンツが素早く表示される（2.5秒以内）ため、ページが有用に感じられる。
- Interaction to Next Paint（INP）: クリックやタップへのページの反応がほぼ即時（200ミリ秒以内）。
- Cumulative Layout Shift（CLS）: レイアウトがほぼ安定しており、予期しない移動がほとんどない（スコア ≤ 0.1）。
ほとんどのユーザーに対してこれらのしきい値を満たすページは、「良好」な全体的なページ体験を提供していると分類されます。
もちろん、これらはウェブ全体の推定的な分類を目的とした大まかな指標です。個々のウェブサイトでは、ユーザーにとっての「良好」の期待値が異なる場合があります。
モバイルのCore Web Vitalsは継続的な前年比改善を示しており、2023年の36%から2024年の44%に増加し、2025年には48%に達しました。この上昇はサイトの最適化に加え、ブラウザ、デバイス、ネットワークの改善を反映している可能性があります。
デスクトップのパフォーマンスも、2023年の48%から2024年の55%へとポジティブなトレンドを示しました。ただし、2025年の改善は僅かで、56%への増加にとどまりました。
これらのトレンドをより深く理解するために、次のセクションではCore Web Vitalsがページの人気度によってどのように異なるかを調べます。より人気のあるページはランク値が低く表示されます。
モバイルでは、最も人気のあるサイトと最も人気のないサイトが、人気分布の中間に位置するサイトよりも優れたパフォーマンスを示す傾向があります。最も人気のあるサイトはCore Web Vitalsの結果が良好な一方、中程度の人気のサイトではパフォーマンスが低下し、最も人気のないサイトでは再び改善されます。
- 最も人気のある1,000のモバイルサイトの51%が良好なCore Web Vitals（CWV）を持つ。
- CWVは次の10,000サイトで42%、次の100,000サイトで37%に低下する。
- しかし、次の1,000,000サイトで42%、次の10,000,000サイトで48%に改善する。
このパターンは、人気ティア間のページの複雑さとパフォーマンスへの投資の違いを反映している可能性があります。
- 人気の高いサイトはパフォーマンスを優先事項として扱い、ユーザーエンゲージメントとビジネス成果との密接な相関関係から継続的な最適化に投資する可能性が高い。
- 中程度の人気のサイトは、追加機能やサードパーティスクリプトなど高い複雑さとパフォーマンスへの継続的な焦点の欠如を組み合わせ、結果の低下につながる場合がある。
- 人気の低いサイトは多くの場合よりシンプルで、機能が少なく軽量なページを持ち、プラットフォームのデフォルト設定の恩恵を受けて比較的優れたパフォーマンスを提供できる。
このU字型のパターンはモバイルでより顕著で、より遅いデバイスと不安定なネットワーク状況がページの複雑さと最適化の限界の影響を増幅させる傾向があります。デスクトップでは、より強力なハードウェアと安定したネットワークにより、これらの違いの目に見える影響を軽減できます。
パフォーマンスはプライマリナビゲーションとセカンダリナビゲーション間でも大きく異なる場合があります。プライマリナビゲーションは通常、ユーザーがホームページのサイトにアクセスするときに発生し、より多くのリソースをフェッチして実行する必要があります。一方、セカンダリナビゲーションは、ユーザーが同じサイト内のページ間を移動する際に発生し、以前に読み込まれてキャッシュされたリソースの恩恵を受けることができます。
この章のほとんどのCrUXデータはオリジン単位ですが、クローラーはクロール時に利用可能な場合はページレベルのCrUXデータも収集しており、ホームページとセカンダリページナビゲーション間のCore Web Vitalsの違いを調べることができます。
セカンダリページはホームページよりも高いCWV合格率を示しており、デスクトップで14%、モバイルで11%のリードがあります。このパフォーマンスの差は、セカンダリページがキャッシュされた情報の恩恵を受けることが多く、それがより速いページ読み込みに貢献していることを示唆しています。ホームページはより頻繁に更新され、より動的でさまざまなコンポーネントを含む傾向がある一方、セカンダリページはよりテンプレート化されて一貫性があり、より安定して最適化しやすい場合があります。
現代のシングルページウェブサイトは、フルページリロードなしにコンテンツが変わるJavaScriptベースのナビゲーションを使用することが多いです。これらのナビゲーションはユーザーにとってページ間の移動のように感じられますが、現在のWeb Vitalsの計測では常に完全に捕捉されるわけではありません。ソフトナビゲーションのサポートにより、これらのページ内遷移でのCore Web Vitalsの捕捉が改善され、最初のページ読み込みを超えた実際のユーザー体験のより正確なビューが提供されることが期待されています。
読み込み速度
ユーザーの品質と信頼性の認識に影響を与える主要な要因の1つが、ウェブサイトの初期読み込み速度です。しかし、「速度」はウェブサイトの文脈において本質的に相対的であり、単一の値で定義するのは難しいです。パフォーマンスはユーザーのデバイス能力とネットワーク環境によって異なるため、ユーザー体験を捉えるために単一の「読み込み時間」に頼ることはできません。そのため、サイトがどれだけ速く読み込まれるかだけでなく、どれだけ速く 感じられる かを計測する複数のユーザー中心の指標を見ていきます。
以下のセクションでは、First Contentful Paint（FCP）とLargest Contentful Paint（LCP）の2つの主要な読み込み指標に焦点を当てます。
First Contentful Paint
ウェブページの速度に対するユーザーの第一印象を理解するために、First Contentful Paint（FCP）を見ていきます。この指標は、ユーザーが最初にページをリクエストした時点から計測して、ページが あらゆる コンテンツを表示し始めるまでにかかる正確な時間を捉えます。FCPスコアが1.8秒未満のページは「良好」と見なされ、1.8〜3.0秒のスコアはページが「改善が必要」であることを示し、3.0秒を超えるスコアは「不良」なパフォーマンスと見なされます。
FCPパフォーマンスは2024年以降、デスクトップとモバイルの両方で改善されました。「良好」なFCPを達成するデスクトップサイトの割合が2%増加し、モバイルサイトはより大きな4%の改善を見せました。FCPは大まかに2つの主要な部分から構成されていると理解でき、それぞれが読み込みプロセスの異なる側面によって影響を受けます：
- 1つ目は、Time to First Byte（TTFB）で捉えられるネットワークとサーバーのオーバーヘッドです。これには接続セットアップ、リダイレクト、サーバー処理時間が含まれ、主にネットワークインフラとプロトコル効率によって影響を受けます。Service Workerがキャッシュからレスポンスを提供する場合、ネットワークのラウンドトリップを回避でき、再訪問時のTTFBを改善できます。ただし、Service Workerの起動も遅延を加える可能性があり、Navigation Preloadは初期化中にネットワークリクエストを並行して開始することでこれを軽減するのに役立ちます。
- 2つ目はクライアントサイドレンダリングで、最初のバイトを受信した後に始まります。これはブラウザがリソースを解析してページの最初の可視コンテンツをレンダリングするために必要な時間を反映しており、ブラウザの動作、レンダリングブロックリソース、ユーザーハードウェア能力などの要因によって影響を受けます。
2024年以降、「良好」なTTFBを達成するサイトの割合はデスクトップで1%、モバイルで2%増加しました。
同期間、「レンダリングブロックリソース監査」に合格したページの割合はデスクトップで横ばい、モバイルで1%増加しました。
まとめると、2024年から2025年にかけてのFCPの改善は、サーバーレスポンスタイムのわずかな改善とレンダリングブロック作業のわずかな削減と一致しています。これは、ネットワーク配信とクライアントサイドレンダリングの両方での段階的な改善が、より早い最初の描画に貢献しており、モバイルデバイスへの影響がわずかに大きいことを示唆しています。
FCPが最初の視覚的反応を捉えるのに対し、LCPはページの主要なコンテンツがいつ表示されるかを反映し、通常より長く複雑なクリティカルパスを伴います。FCPと同様に、LCPはいくつかの連続したフェーズの合計として理解できます：サーバーから最初のバイトを受信するまでの時間（TTFB）、ブラウザがLCPリソースのフェッチを開始するまでの遅延（リソース読み込み遅延）、そのリソースの読み込みに費やされる時間（リソース読み込み時間）、および要素がレンダリングされる前の遅延（要素レンダリング遅延）。これらのフェーズ全体で時間がどこに費やされているかを理解することが、LCP、ひいては全体的なCore Web Vitalsパフォーマンスの改善に重要です。
Largest Contentful Paint
ページがいつ意味のある形で読み込まれたと感じるかを理解するために、Largest Contentful Paint（LCP）を見ていきます。この指標は、ユーザーが最初にページをリクエストした時点から、最大の可視要素（通常はヒーロー画像、見出し、または目立つテキストブロック）が画面上でレンダリングを終了するまでの時間を計測します。LCPスコアが2.5秒未満のページは「良好」と見なされ、2.5〜4.0秒のスコアはページが「改善が必要」であることを示し、4.0秒を超えるスコアは「不良」なパフォーマンスと見なされます。
現在、デスクトップページの74%が「良好」なLCPスコアを達成しているのに対し、モバイルは62%で、モバイルは「不良」な体験の率もほぼ2倍（13%対7%）を示しています。このギャップは、モバイルにおけるより遅いネットワークとより低性能なデバイスの複合的な影響と一致しています。
LCPコンテンツタイプ
LCPを効果的に最適化するには、まずどのタイプのコンテンツが通常LCP要素になるかを理解する必要があります。
LCPコンテンツタイプのトレンドは過去の年と同様です（2022年および2024年のデータも参照）。画像は両デバイスタイプのLCP要素として引き続き支配的で、デスクトップページの85.3%とモバイルページの76%が画像をLCP要素として持っています。テキストベースのLCP要素が残りの多くを占めており、デスクトップで14.4%、モバイルで23.7%です。このギャップは、狭いビューポートでヒーロー画像がリサイズされ、より小さなビジュアルに置き換えられるか、または完全に削除されるレスポンシブデザインの慣行を反映している可能性が高く、代わりに見出しテキストが最大の可視要素になります。
インライン画像（HTMLに直接埋め込まれたデータURI）はページの約0.5%でまれなままで、より大きなHTMLペイロードとキャッシュ効率に関するトレードオフについての限定的で慎重な採用と意識を示しています。
LCP画像フォーマット
LCP要素としての画像のこの継続的な支配を考慮すると、LCPのリソース読み込み時間フェーズに直接影響するため、使用されている画像フォーマットを見ることが重要になります。2024年のチャプターではこのフェーズが他と比べて最適化の可能性が低いことが示されましたが、画像フォーマットの効率性は依然として全体的なパフォーマンスに貢献します。
WebPやAVIFなどの最新フォーマットはレガシーフォーマットよりも優れた圧縮を提供し、ファイルサイズが小さく転送が速くなります。しかし、レガシーのJPGとPNGは依然として多く使用されています（JPGがLCP画像の57%、PNGが26%を占めています）。
ただし、JPGの使用が2024年以降4%減少し、WebPが4%増加しているなど、いくつかの前向きな兆候があります。
PNGやその他のフォーマットが2024年の割合と同じである（AVIFが0.7%に達したことを除いて）ことから、ウェブページはゆっくりとではありますが、JPGからWebPに移行しているようです。この遅い採用は、最新フォーマットが広いサポートを持っているにもかかわらず、既存の画像パイプラインとコンテンツライブラリを移行するコストを反映しているかもしれません。
クロスオリジンLCP画像
LCP画像のオリジンは、ブラウザがダウンロードを開始できる速さに影響し、リソース読み込み遅延フェーズに影響します。画像がページと同じドメインでホストされている場合、ブラウザは既存の接続を再利用できます。クロスオリジン画像は、特にオリジンがまだ接続されていない場合、追加の接続セットアップ（DNS/TCP/TLS）を生じさせる可能性があり、ダウンロードが開始できるまでの時間が増加します。
デスクトップページの51%とモバイルページの44%は、ドキュメントと同じホストからLCP画像を提供しています。クロスホストのLCP画像はページの16〜18%を占めており、preconnectヒントで軽減されない限り、接続オーバーヘッドのコストを支払っている可能性がある意味のある割合です。
「その他のコンテンツ」カテゴリ（デスクトップ32%、モバイル40%）は、LCP要素が画像でないページ、おそらくテキストブロックや背景要素を表しています。「その他のコンテンツ」のモバイルの割合が高いのは、狭いビューポートでヒーロー画像が優先度を下げられるレスポンシブデザインパターンを反映しているかもしれませんが、このデータだけでは確定的にはわかりません。
LCPリソースの優先度設定
リソース読み込み遅延フェーズはLCP時間の大部分を占めることが多いため、ブラウザはクリティカルリソースを加速するためのツールを提供しています。fetchpriority="high" 属性は、ブラウザが通常よりも高い優先度でリソースを優先するよう指示します。これは画像がLCP要素であっても通常は高優先度と見なされないため有用です。一方、<link rel="preload"> はブラウザがHTMLで自然に発見する前にリソースをフェッチするよう指示します。
fetchpriority="high" の採用は成長を続けており、現在LCP画像を持つモバイルページの17%に登場しています（2024年の15%から増加）。preloadの使用は2.1〜2.2%と低いままです。
両技術は比較的実装が簡単ですが、preloadはリソースがHTMLドキュメントで素早く発見できない場合にのみ必要であることに注意すべきです。また、preloadを使用する場合は、fetchpriority="high" と組み合わせて画像が高優先度でフェッチされることを確保すべきです（preloadだけを使用しても保証されません）。
LCP画像に fetchpriority="low" を使用しているページの0.3%は意図的でない可能性があります。開発時にどの画像がLCP要素になるかを特定することは、開発者にとってトリッキーな場合があるためです（ビューポートとコンテンツによって異なります）。
LCP遅延読み込み
画像の遅延読み込みとは、画像が必要になるまで読み込みを遅らせることを意味します。例えば、ページ読み込み時にすべての画像を読み込むデフォルトの代わりに、フォールドより下の画像をユーザーのビューポートに近づいたときにのみ読み込みます。これは重要なフォールドより上のコンテンツを優先するのに役立ちます。遅延読み込みは一般的に有用な最適化ですが、LCP画像に適用するとユーザーが待っているメインコンテンツの表示が遅れるため、有害になる可能性があります。
全体として、約16〜17%のページがLCP画像を遅延読み込みしており、この数字は2024年以降変わらず安定しています。ただし、構成は変化しています：ネイティブの loading="lazy" の使用がわずかに増加し（モバイルで9.5%から10.4%、デスクトップで10.2%から11.5%）、data-src 属性の背後にソースを隠すカスタムアプローチは減少しています（モバイルで6.7%から5.9%）。ネイティブの loading="lazy" はカスタムアプローチよりもLCP遅延読み込みの大きなシェアを占めており、標準化されたブラウザ機能への移行を示しています。
読み込み速度の結論
まとめると、読み込み指標は以下の主要なトレンドを浮き彫りにしています：
- FCPとLCPはともに2024年以降改善されており、デスクトップは一貫してモバイルを上回っています。
- 新しい画像フォーマットの採用は、JPGからWebPへの緩やかな移行にもかかわらず、依然として限られています。
- 約16%のウェブページがまだLCP画像を遅延読み込みしており、プライマリコンテンツの表示を遅らせています。
インタラクティビティ
歴史的にウェブパフォーマンスの計測は読み込み速度に集中してきましたが、INPのような指標のおかげで、ページが読み込まれた後のインタラクティビティを計測することが同等、あるいはそれ以上に重要であるという認識が高まっています。
Interaction to Next Paint（INP）
Interaction to Next Paint（INP）は、セッション中にページと行われたすべてのインタラクションを観察し、最悪の遅延を報告することで計算されます（ほとんどのサイトでは、多くのインタラクションを持つページが外れ値を無視するための追加の余裕があります）。インタラクションの遅延は、ユーザーがインタラクションを開始した時点から、ブラウザが次にフレームを描画できる瞬間まで、インタラクションを駆動するイベントハンドラーのグループの単一の最長期間で構成されます。
オリジンが「良好」なINPスコアを受け取るには、すべてのセッションの少なくとも75%が200ミリ秒以下のINPスコアを必要とします。INPスコアは、ページ上のすべてのインタラクションの中で最も遅い、またはほぼ最も遅いインタラクション時間です。詳細については、INPの計算方法の詳細を参照してください。
2025年、モバイルのINPパフォーマンスは前向きな改善を示し、77%のウェブサイトが良好なスコアを達成しました（2024年の74%から上昇）。この3パーセントポイントの向上は、何百万ものウェブサイトが今やモバイルユーザーにより応答性の高い体験を提供していることから、意味のある進歩を表しています。デスクトップのパフォーマンスは97%と引き続き模範的で、過去数年に確立された高い水準を維持しています。
注目すべきことに、モバイルとデスクトップのパフォーマンスギャップは縮小し始めており、2024年の23パーセントポイントから2025年の20パーセントポイントに縮小しました。20パーセントポイントのギャップはまだ大きいですが、これはギャップを縮める方向への最初の測定可能な一歩です。このトレンドは、モバイル最適化の取り組みがウェブ全体で勢いを増していることを示しています。
最も人気のあるウェブサイトは2025年に目覚ましいINPの改善を示し、上位1,000サイトは良好なスコアが53%から63%に急増しました。これは10パーセントポイントの向上で、他のすべてのカテゴリを上回りました。これは、高トラフィックのウェブサイトがインタラクティビティの最適化を優先していることを示しており、ユーザーエンゲージメントとビジネス指標への直接的な影響によって促進されている可能性が高いです。
人気サイトは全体平均の77%をまだ下回っていますが、ギャップは大幅に縮まりました。上位1,000サイトは2024年に平均より21パーセントポイント下でしたが、2025年には14パーセントポイント下にとどまっており、どのカテゴリでも観察された最速の改善率です。
このパターンは、高トラフィックウェブサイトが直面する独自の課題を反映しています：より複雑な機能、より豊かなインタラクティブ機能、より重いサードパーティ統合、および多様なユーザーインタラクションパターン。Eコマースプラットフォーム、ソーシャルメディアサイト、ニュースポータルは本質的により多くのJavaScript実行を必要とし、良好なINPスコアの達成をより困難にしています。
大幅な前年比改善は、主要なウェブサイトがコード分割、インタラクション最適化、選択的機能読み込みを通じてこれらの課題を成功裏に解決していることを示唆しています。最も訪問されるサイトがパフォーマンスを向上させ続けるにつれて、より高い基準を設定し、より広いウェブエコシステムに価値ある最適化パターンを提供しています。
ページレベルのCrUXデータを見ると、2024年からの注目すべき変化として、ホームページが今やモバイルデバイスでセカンダリページよりも大幅に良好なINPパフォーマンスを示しています。モバイルホームページは80%の良好なINPスコアを達成し、2024年より7パーセントポイント改善されました。セカンダリページは69%に低下し、11パーセントポイントのギャップを生じさせました。この乖離は、ホームとセカンダリページがほぼ同一のパフォーマンスを示した2024年（モバイルで73%対72%）からの変化を表しています。デスクトップのパフォーマンスは両ページタイプでそれぞれ97%と95%と堅調を維持しました。
ホームページのINPの改善は、第一印象が重要なランディングページへの最適化の注力が増加したことを反映している可能性があります。しかし、セカンダリページのパフォーマンス低下は注意が必要で、これらのページはフィルター、カルーセル、フォーム検証などのより複雑なインタラクションを含むことが多く、またユーザージャーニーの深いところで活性化するサードパーティウィジェットと分析からのJavaScriptも蓄積するためです。
Total Blocking Time（TBT）
Total Blocking Time（TBT）は、First Contentful Paint（FCP）後にメインスレッドが入力応答性を防ぐほど長くブロックされた合計時間を計測します。
TBTはラボ指標であり、実ユーザーモニタリングを使用してのみ収集できるINPのようなフィールドベースの応答性指標のプロキシとしてよく使用されます。ラボベースのTBTとフィールドベースのINPは相関しており、TBTの結果は一般的にINPのトレンドを反映しています。200ミリ秒未満のTBTは良好と見なされますが、ほとんどのモバイルウェブサイトはこの目標を大幅に超えています。
モバイルの中央値TBTは2025年に1,916ミリ秒に増加し、2024年の1,209ミリ秒から58%上昇しました。デスクトップのTBTも67ミリ秒から92ミリ秒に上昇しました。90パーセンタイルでは、モバイルユーザーはページが完全にインタラクティブになる前に7.5秒以上のブロック時間に直面しています。
これは明らかな矛盾を提示しています：フィールドベースのINPスコアが改善されたにもかかわらず、ラボベースのTBTは大幅に悪化しました。この乖離の背後にはいくつかの要因が考えられます。
- 現実世界のデバイスがより強力になり、ラボテストが一貫したエミュレートデバイスを使用して明らかにするコードの複雑さの増加を隠しています。
- 一部のサイトはINPを支配するインタラクションを最適化しながら、TBTに表れる大量のバックグラウンド作業を実行し続けている可能性があります。
- INP指標は進化し続けており、ChromiumのINP指標の変更履歴に記載されているように、計測の安定化と現実世界のインタラクション動作のより良い捕捉に焦点を当てた今後の改善が予定されています。
デスクトップ（中央値92ms）とモバイル（中央値1,916ms）のギャップの拡大は、デバイスクラス間の持続的なパフォーマンスの不平等を強調しており、INPの改善にもかかわらず、メインスレッドブロッキングの根本的な課題が激化していることを示唆しています。
インタラクティビティの結論
インタラクティビティの結果の主なポイントは以下の通りです：
- モバイルINPは77%に改善し（74%から上昇）、モバイルとデスクトップのギャップを20パーセントポイントに縮小しました。
- 上位1,000のウェブサイトが最も大きな改善を達成し、良好なINPが53%から63%に向上しました。
- ホームページはセカンダリページを大幅に上回るようになりました（モバイルで80%対69%）。
- INPの改善にもかかわらず、TBTは58%増加し、全体的なJavaScript実行の重さが増していることを示しています。
視覚的安定性
視覚的安定性はCumulative Layout Shift（CLS）によって計測され、ページがユーザーにとってどれだけ予測可能でスムーズに感じられるかの指標です。このセクションでは、最近の数年間の進歩、デバイスの違い、および変化に焦点を当てます。
Cumulative Layout Shift（CLS）
Cumulative Layout Shift（CLS）は、ページの読み込みとインタラクション中の予期しないレイアウトの動きを計測し、スコアが高いほど視覚的なシフトが多くなります。CLSスコアは3つのしきい値に分類されます：「良好」（≤ 0.1）、「改善が必要」（> 0.1かつ ≤ 0.25）、「不良」（> 0.25）。これにより、ウェブサイト間の視覚的安定性を評価・比較するための標準化された方法が提供されます。
2025年、デスクトップページの72%とモバイルページの81%が「良好」なCumulative Layout Shift（CLS）スコアを達成しています。デスクトップページはモバイル（10%）に比べてCLSが「改善が必要」な割合が高く（17%）、「不良」なCLSのページの割合はデバイス間でほぼ同じで約9〜10%です。これは、ほとんどのページがCLSのしきい値を満たすのに近く、深刻なレイアウト不安定性を経験するページが少ないことを示しています。
2024年と比較して、「不良」なCLSを持つデスクトップページの割合が1%減少し、「改善が必要」と分類されるページの割合が同様に増加しました。
過去の年を振り返ると、「良好」なCLSのしきい値を満たすウェブサイトの割合はデスクトップとモバイルの両方で毎年増加しています。デスクトップのCLSは2021年の62%から2025年の72%へと徐々に改善し、モバイルは同期間に81%と、より大きな改善を見せました。ただし、昨年と比較した増加はわずかで、デスクトップで「良好」なCLSのしきい値を満たすサイトの割合は変わらず、モバイルは2%しか改善されていません。
ページレベルのCrUXデータを見ると、ホームページ以外のページはデスクトップとモバイルの両デバイスでホームページよりもわずかに良好な視覚的安定性を示しています。2025年、デスクトップのセカンダリページの73%が「良好」なCLSを達成しており、デスクトップホームページの71%と比較されます。モバイルでは、セカンダリページの81%が「良好」なCLSのしきい値を満たしており、モバイルホームページの79%と比較されます。これは、ヒーローメディア、バナー、プロモーション要素などのより動的なコンテンツを含むことが多いホームページが、セカンダリページよりもレイアウトシフトを起こしやすいことを示唆しています。
2023年から2025年にかけて、「良好」なCLSを持つサイトの割合は両デバイスタイプで着実に増加しており、モバイルが一貫してデスクトップを上回っています。時間の経過とともに若干の変動がありますが、両トレンドとも急激な変曲点なしに緩やかな上昇軌跡を示しており、突然の変化ではなく継続的な改善を示しています。
CLSのベストプラクティス
サイトがCLSの可能性を低減するために従えるベストプラクティスが多数あります。
バック/フォワードキャッシュ（bfcache）
バック/フォワードキャッシュ（bfcache）は、ユーザーがブラウザの戻るまたは進むボタンを使用してナビゲートするときに、ブラウザがページをメモリから即座に復元できるようにします。ページをリロードしてJavaScriptを再実行するのではなく、ブラウザはページの状態を保持し、ほぼ瞬時のナビゲーションと改善されたユーザー体験をもたらします。ページが以前の状態に復元されるため、bfcacheは再ナビゲーション中に発生する可能性のあるレイアウトシフトを回避するのにも役立ちます。
ただし、すべてのページがbfcacheの対象ではありません。対象資格はページライフサイクル要件のセットに依存しており、これらの制約に違反するページは完全なリロードにフォールバックします。対象外の理由のリストはHTML仕様で確認できます。bfcacheの動作は最終的にブラウザによって処理されますが、開発者はChrome DevToolsを使用してページの適格性を評価できます。
ページは既知のライフサイクルの動作によってbfcacheから除外される場合があります。これには、unloadまたは beforeunload イベントハンドラーの使用、アクティブな接続や管理されていないタイマーなどの復元できない副作用、および安全なページの復元に干渉する特定のサードパーティスクリプトが含まれます。そのため、unloadイベントはパフォーマンスへの負の影響とバック/フォワードキャッシュとの非互換性のために非推奨とされ、推奨されていません。
Chromeチームは、最近の使用パターンに反映されているように、visibilitychange や pagehide などの代替手段を支持して unload の回避を推奨しています。2024年と比較して、2025年にはすべてのランクと両デバイスでアンロードハンドラーの使用が減少しました。この削減は、より多くのページがbfcacheの動作の対象になったことを示唆しています。この進歩にもかかわらず、アンロードハンドラーは依然として上位ランクのサイトとデスクトップでより一般的で、以下のグラフに示すように、ウェブのかなりの部分のbfcacheの適格性を制限し続けています。
サイトの人気が下がるにつれてアンロードハンドラーの使用が一貫して減少するのは興味深いです。高トラフィックのウェブサイト（上位1,000サイト）では、アンロードハンドラーがデスクトップページの28%とモバイルページの20%に存在し、この割合は下位ランクのサイトに向かって着実に低下し、デスクトップで11%、モバイルで10%に達します。すべてのランクで、デスクトップページはモバイルよりも高いアンロードハンドラーの使用を示しており、アンロードハンドラーがウェブの長尾全体よりも大規模で複雑なサイトでより一般的であることを示唆しています。これは上位サイトがアナリティクス、広告、およびアンロードハンドラーを登録するレガシーライフサイクルパターンに大きく依存しているためと考えられます。
ウェブサイトがbfcacheの対象外カテゴリに入る別の一般的な理由は、Cache-Control: no-store ディレクティブの使用です。このキャッシュ制御ヘッダーは、ブラウザ（および中間キャッシュ）にリソースのコピーを保存しないよう指示し、コンテンツがリクエストのたびにサーバーからフェッチされることを保証します。
Cache-Control: no-store を使用しているサイトの割合。
現在23%のサイトが Cache-Control: no-store を使用しており、2024年の21%から増加しました。この増加は、認証済みおよびパーソナライズされた体験の増加、より厳格なセキュリティまたはコンプライアンス要件、特にbfcacheの適格性に関して Cache-Control: no-store のパフォーマンスへの影響を低減したブラウザの動作の進化を反映している可能性があります。
歴史的にすべてのブラウザが Cache-Control: no-store をbfcacheを避ける理由として扱ってきましたが、Chromeは安全な場合に一部の no-store ページのbfcacheを許可する場合があることに注意してください。FirefoxとSafariを含む他のブラウザは一般的に Cache-Control: no-store をbfcacheブロッカーとして扱い続けています。
固定画像サイズ
画像はCumulative Layout Shift（CLS）の最も一般的な原因の1つで、ブラウザが事前にどれだけのスペースを確保すべきか分からない場合に発生します。画像が明示的な寸法なしに読み込まれると、ブラウザは最初に画像の高さがゼロであるかのようにページをレイアウトし、画像の読み込みが完了した後に周囲のコンテンツをシフトします。
これを防ぐには、画像は常に width と height 属性を介して、またはCSSの aspect-ratio を使用して本質的な寸法を定義する必要があり、ブラウザは画像がフェッチされる前に正しい量のスペースを割り当てることができます。
2025年、明示的な寸法がない画像によるレイアウト不安定性のリスクを抱えたページが依然として大きな割合を占めています。モバイルでは62%のページが少なくとも1つの画像に寸法を設定しておらず、2024年の66%から改善されており、CLS対応の画像慣行の漸進的な採用を示しています。
デスクトップページは同様だがわずかに悪いパターンを示しており、2025年に65%が影響を受けており、2024年の69%から低下しています。下降傾向は前向きですが、大多数のページはまだブラウザがレイアウト時に画像サイズを推測する必要があり、画像をCLSへの最も持続的で防止可能な貢献者の1つにしています。
ウェブページあたりの寸法未指定画像の中央値は2枚です。90パーセンタイルでは、この数字はデスクトップで26枚、モバイルで23枚に急増します。寸法未指定の画像はレイアウトシフトのリスクを高めます。ただし、CLSへの実際の影響は、画像のサイズと、特にシフトがビューポートに影響する場合に読み込まれたときにコンテンツがどれだけシフトするかの両方に依存します。CLSは影響フラクション（ビューポートのどれだけが影響を受けるか）と距離フラクション（要素がどれだけ動くか）に基づいて計算されるため、大きな画像やページの上部に近いシフトほどCLSへの貢献が大きくなる傾向があります。
寸法未指定の画像は高いパーセンタイルでははるかに高くなります。中央値では、寸法未指定画像はデスクトップとモバイルの両方で約100pxの高さですが、90パーセンタイルではデスクトップで約413px、モバイルで300pxに成長します。高い寸法未指定画像がビューポートに表示される場合、特にCLSを増加させます。これは読み込まれたときにより大きな縦方向のレイアウトシフトを引き起こすためです。ウェブページは縦方向にスクロールするため、画像の高さがないことは幅がないことよりもCLSへの影響がはるかに大きいです。
フォント
ブラウザは、カスタムウェブフォントがまだダウンロード中の間、フォールバック（システム）フォントを使用してテキストを最初に表示することがよくあります。この一時的なレンダリングは、Cumulative Layout Shift（CLS）スコアに悪影響を与える可能性があります。カスタムフォントが最終的に読み込まれると、ブラウザはフォールバックフォントを置き換えます。これによりテキストのサイズと間隔が変わり、コンテンツのシフトが起こります。
モバイルページの大多数87%が少なくとも1つのウェブフォントを使用しています。このカスタムタイポグラフィの広範な使用は、ダウンロードと適用を必要とし、レイアウトシフトの可能性を大幅に高めます。
フォントによるレイアウトシフトを効果的に最小化するには、理想的にはリソースヒントを使用して、できるだけ早く重要なフォントを読み込むことが重要です。フォントが最初のレンダリングの前または非常に近くに読み込まれると、ブラウザはすぐに正しいフォントでテキストを表示できます。これにより、レイアウトシフトの一般的な原因であるデフォルトフォントからのスワップが防止されます。現在のデータは、この機会がしばしば見逃されていることを示しています。
dns-prefetch は最も一般的に使用されるヒントで、desktop と mobile の両方でページの24%に登場し、次いで各デバイスで22%の preconnect が続く。preload は desktop で15%、mobile で16%とやや少なく使用され、prefetch は両プラットフォームで約5%とまれなまま。フォントリソースヒントの使用状況はデスクトップとモバイルでほぼ同様です。約24%のページがdns-prefetchを使用し、22%がpreconnectを使用しており、これは主に接続セットアップ時間の削減に役立ちます。Preloadはレンダリング中にフォントを早期に利用可能にする良い方法ですが、ページの15〜16%でしか使用されていません。さらに少ないページ（約5%）がprefetchを使用していますが、これは一般的に初期ページ読み込み中に必要なフォントにはあまり役立ちません。これは、リソースヒントのより的を絞った使用によってフォントのパフォーマンスを改善する大きな機会があることを示唆しています。
非コンポジットアニメーション
非コンポジットアニメーションは、レイアウトに影響するプロパティを変更し、レンダリングが始まった後に周囲のコンテンツを動かすリフローを引き起こすため、レイアウトシフトに貢献します。transform や opacity などのコンポジットプロパティを使用したアニメーションは、レイアウトを変更せずに視覚的な外観を更新することでこれを回避し、視覚的安定性においてより安全です。
非コンポジットアニメーションは依然として一般的で、モバイルページの40%とデスクトップページの44%に登場しています。
非コンポジットアニメーションの影響は主に高いパーセンタイルで現れ、75パーセンタイルで使用率が増加し、90パーセンタイルではデスクトップで13アニメーション、モバイルで11アニメーションに急増します。
視覚的安定性の結論
ウェブ全体の視覚的安定性は特にモバイルデバイスで年々大幅に進歩しています。ほとんどのページは今や最小限の予期しない動きで安定した体験を提供しており、ベストプラクティスの採用が改善されていることを反映しています。ただし、特にデスクトップで約20〜30%のページがまだ「良好」なCLSを達成していないことから、継続的な改善と最適化の余地があります。
漸進的な改善にもかかわらず、寸法未指定の画像は依然として一般的で、フォントの読み込みパターンはまだレイアウトシフトの機会を生み出しており、多くのサイトが既知のCLS軽減策を完全に実装していないことを示唆しています。明示的な画像サイズ設定、重要なフォントのプリロード、コンポジットアニメーションの使用などのシンプルなベストプラクティスを採用することで、ページは視覚的安定性の改善に役立てることができます。
Early Hints
Early Hintsは、リクエストされたページを読み込むために必要なリソースについてブラウザに早期シグナルを提供します。
Early Hintsは、リクエストされたページがまだ準備中の間にサーバーからブラウザに送信されます。これにより、ブラウザはリクエストされたページが返される前に、楽観的に他のドメインへのプリコネクトやアセットのプリロードを開始できます。
これにより、Early Hintsは現在リクエストされているページの読み込みパフォーマンスに絶対的な影響を与えることができます。HTMLがブラウザに返るのを待ち、パーサーがメインCSSファイルやLCPアセットのリンク（またはプリロードリンク）を見つけるのではなく、HTMLがブラウザに返される前にそれらのアセットのフェッチを開始できると考えてみてください。これにより、単一の描画でほぼ完璧にレンダリングされたFCPが可能になります。
Early Hintsは crossorigin 属性とCSPヘッダー情報も含むことができるため、セキュリティ上の理由からHTTP/2以上でのみ使用することが推奨されます。
Early Hintsの使用状況
採用はまだ本格化していないことがわかります。すべてのグループで使用率は非常に低く、上位1,000,000サイトのデスクトップでやっと6%を超える程度で、他のほとんどのグループは5%をはるかに下回っています。
これはおそらくEarly Hintsのセットアップと設定の複雑さに関連しています。特定のページのアセットは、ページが完成して送信準備ができる前にサーバーに関連付けられている必要があります。ほとんどのCMSにとってこれは課題となるでしょう。
モバイル/デスクトップの同等性も非常に顕著です。差は1%を超えることはなく、通常は0.5%に近いです。つまり、Early Hintsが実装されている場合、すべてのデバイスタイプで同様に実装されている可能性が高いです。
2025年も使用率は低いままですが、過去3年間で顕著な増加が見られます。
Early Hintsのサポート
ほとんどのウェブパフォーマンス機能とは異なり、Early Hintsはブラウザだけでなくサーバーのサポートにも依存しています。この公開時点では、preconnect はすべてのブラウザでサポートされており、preload はSafariを除くすべてのブラウザでサポートされています。
サーバーに関しては、Early HintsはNode、H2O、NGINXで完全にサポートされており、Apacheでは mod_http2 を使用している場合にサポートされます。
Early HintsはCDNを通じて利用可能で、Fastlyは2020年から、Cloudflareは2021年から、Akamaiは2023年から対応しています。
Speculation Rules
Speculation Rulesは、ユーザーが現在のページを表示した後にいずれかのページに移動することを期待して、完全なページを楽観的にプリフェッチまたはプリレンダリングする実験的なブラウザAPIです。これらのアクションはユーザーが現在表示しているページのバックグラウンドで実行されます。現在は主にChromiumベースのブラウザに実装されていますが、SafariはフラグによるプリフェッチのPartial実装があります。
Speculation Rulesは現在のページのパフォーマンスには役立ちませんが、後続ページの読み込みパフォーマンスを大幅に改善し、しばしばほぼ瞬時のページ読み込みに近づけることができます。
このAPIは、より高度な設定オプションでページ向けの <link rel="prefetch"> と <link rel="prerender"> を置き換えることを意図しています。なお、Speculation Rules APIはフルページ専用です。個別のアセットに対しては、引き続き <link rel="prefetch"> を使用する必要があります。
Speculation Rulesの使用状況
以下のチャートはSpeculation Rulesを含むホームページの割合を示しており、興味深いことがわかります。上位1,000サイトでのSpeculation Rulesの使用率は非常に低く、デスクトップで3%、モバイルで5%に過ぎません。各グループが増えるにつれて使用率は上昇しますが、上位1,000,000サイトでもモバイルとデスクトップ合わせて15%にとどまります。最後のグループ、上位10,000,000サイトになってようやく、デスクトップ24%、モバイル25%へと急激に上昇します：
これはSpeculation Rulesの設定の複雑さに関連している可能性があります。ユーザーの正確な意図は決してわからないため、サイトはページをプリフェッチまたはプリレンダリングする際に慎重である必要があります。フェッチされたが使用されないものはすべて無駄になります。そのため、eコマースサイトのような大規模サイト、特に多数のカテゴリやメニューオプションが直接ジャンプできる大規模サイトでは、Speculation Rulesを適切に設定するのが難しい場合があります。レガシーまたは独自CMSへの実装も複雑になる可能性があります。
逆に、Speculation Rulesはインターネットの大きなシェアを持つ WordPress に組み込まれるようになり、これがロングテールでの高い採用率を説明するかもしれません。
また、モバイルとデスクトップの使用率の同等性も注目に値します。差は1%を超えることはほとんどありません。つまり、Speculation Rulesが実装されている場合、すべてのデバイスタイプで同様に実装されている可能性が高いです。
結論
今年のデータの分析は、よりレスポンシブになりつつあるが、最適化がまだ複雑なウェブの姿を描き出しています。ウェブの使用感における明確な進歩が見られます。モバイルのインタラクティビティは大幅に改善され、スマートフォンとデスクトップコンピュータ間のパフォーマンスギャップがついに縮まり始めています。これは、Interaction to Next Paint（INP）のような新しい指標への業界の注力が功を奏しており、開発者がユーザーにとって最も重要なインタラクションを優先しようとしていることを示しています。
しかし、ウェブの異なるセグメントが新しい標準を採用する方法における「パフォーマンスの分断」も観察されます。例えば、最も人気のあるサイトが複雑なJavaScriptの手動最適化によってインタラクティビティ（INP）の改善をリードしていることがわかりました。これに対して、Speculation Rulesのような新しい標準は、トップではなく、WordPressのような人気CMSのプラットフォームレベルの統合によって推進されるウェブの「ロングテール」で最高の採用率を示しています。これは、パフォーマンスの将来が個々の手動作業への依存を減らし、ウェブを構築するツールに組み込まれたスマートなデフォルトへの依存を増やす可能性があることを示唆しています。
これらの進歩にもかかわらず、ウェブパフォーマンスの基本は依然として課題を突きつけています。高度な指標が改善される一方で、根本的な問題は依然として残っています。モバイルページの約40%が依然として視覚的不安定性のリスクのある非コンポジットアニメーションを使用しており、大多数のページが画像の正しいサイズ指定や重要なフォントをスムーズに読み込むために必要なリソースヒントを欠いています。これは、フレームワークが複雑なJavaScriptの管理を助けてくれる一方で、良好なウェブパフォーマンスを確保するためのより単純なベストプラクティスを見落としがちであることを示唆しています。
最後に、測定そのものの状況が成熟しています。より多くのブラウザがINPのような現代的な指標のサポートを拡大するにつれ、クロスブラウザ比較がより一貫したものになります。今後を見据えると、開発者の目標はトップレベルのスコアを超えて、可能性と実践のギャップを埋め、トップサイトが使用する手動最適化と現代のウェブの自動化ツールの両方を活用して、すべてのユーザーに信頼できる体験を提供することです。
