パフォーマンス
はじめに
高速なウェブサイトに文句を言う人はいませんが、読み込みが遅くてもたつくウェブサイトはユーザーをすぐにイライラさせます。ウェブサイトの速度と全体的なパフォーマンスは、ユーザーエクスペリエンスとウェブサイトの成功に直接影響します。さらに、ウェブサイトが遅い場合、ユーザーにとってアクセスしにくくなり、これは情報の宇宙への普遍的なアクセスを提供するというウェブの根本的な目標に反します。
近年、Core Web Vitalsパフォーマンスメトリクスは改善し、多くのパフォーマンスメトリクスにわたって積極的な傾向を示しています。しかし、いくつかの不整合が観察できます。たとえば、ハイエンドデバイスとローエンドデバイスの間のギャップが拡大しており、とくにモバイルウェブパフォーマンスにおいて、Alex Russellの研究The Performance Inequality Gapで強調されています。ウェブパフォーマンスは、人々が購入できるデバイスとネットワークに結びついています。幸い、より多くの開発者がこれらの課題を認識し、パフォーマンスの改善に積極的に取り組んでいます。
パフォーマンス章では、ウェブパフォーマンスを評価するための重要なユーザー中心のメトリクスであるCore Web Vitalsに焦点を当てています。しかし、読み込み、インタラクティビティ、視覚的安定性というより広い視点からウェブパフォーマンスを分析し、First Contentful Paintのような補助的なメトリクスを追加します。これにより、2024年にウェブサイトがどのように機能したかをより包括的に把握するために、他のパフォーマンスとユーザーエクスペリエンス関連のメトリクスを探ることができます。
今年の新機能は何ですか？
- Interaction to Next Paint (INP)がFirst Input Delay (FID)を正式に置き換え、Core Web Vitalsの一部となりました。INPは全体的なインタラクティビティパフォーマンスをより正確に評価するのに役立ちます。
- Long Animation Frames (LoAF)データが初めて利用可能になり、INPが低い理由についての新しい洞察を提供します。
- 今年の時点で、パフォーマンス章にはホームページに加えて、セカンダリページのデータ分析も含まれています。これにより、ホームページとセカンダリページのパフォーマンスを比較できます。
データソースに関する注記
HTTP Archiveにはラボパフォーマンスデータのみが含まれています。言い換えれば、単一のウェブサイト読み込みイベントからのデータです。これは有用ですが、ユーザーがパフォーマンスをどのように体験するかを理解したい場合には限定的です。
したがって、HTTP Archiveデータに加えて、このレポートの大部分はChrome User Experience Report (CrUX)からの実際のユーザーデータに基づいています。Chromeは世界でもっとも広く使用されているブラウザですが、すべてのブラウザや世界のすべての地域でのパフォーマンスを反映していないことに注意してください。
CrUXは優れたデータソースですが、LCPやINPのサブパーツ、Long Animation Framesなどの特定のメトリクスは含まれていません。幸い、パフォーマンス監視プラットフォームRUMvisionが、2024年1月1日から10月6日までの期間のこのデータを提供してくれました。HTTP Archiveと比較すると、RUMvisionはより少ない数のウェブサイトをテストするため、同じメトリクスの結果がわずかに異なる可能性があります。
Core Web Vitals
Core Web Vitals（CWV）は、ウェブパフォーマンスのさまざまな側面を測定するために設計されたユーザー中心のメトリクスです。これには、読み込みパフォーマンスを追跡するLargest Contentful Paint（LCP）、インタラクティビティを測定するInteraction to Next Paint（INP）、視覚的安定性を評価するCumulative Layout Shift（CLS）が含まれます。
今年から、INPが正式にFirst Input Delay（FID）を置き換えて、CWVの一部となりました。INPがユーザーが経験するすべてのインタラクションの完全な遅延を測定するのに対し、FIDは最初のインタラクションの入力遅延のみに焦点を当てています。この幅広いスコープにより、INPは完全なユーザーエクスペリエンスをよりよく反映します。
FIDからINPメトリクスへの置き換えは、モバイルでCWVが良好なウェブサイトの割合に大きな影響を与えました。これはユーザーエクスペリエンスが悪化したということではなく、メトリクスの更新により現在はより正確に反映されているだけです。もしインタラクティビティの測定にまだFIDを使用していたとすると、モバイルデバイスでCWVが良好なウェブサイトは48％となります。しかし、INPメトリクスでは、この数字は43％に低下します。興味深いことに、どの応答性メトリクスを使用しても、デスクトップデバイスのパフォーマンスは54％で同じままです。
2020年から2022年の期間、FIDを用いたCWVで測定されたモバイルウェブパフォーマンスはデスクトップよりも速く改善され、両者のギャップは縮まり、2022年にはわずか5％まで達しました。INPを用いたCWVチャートが示すように、2024年にはデスクトップのウェブサイトがモバイルよりも11％良好なパフォーマンスを示しており、INPの導入はギャップがはるかに大きいことを示しています。
INPを用いたCWVは、ランク別にウェブサイトを分析する際に新しい傾向を示しています。以前は、もっとも人気のあるウェブサイトが最適なCWVエクスペリエンスを持つ傾向にありましたが、今年の統計は逆を示しています：モバイルでもっとも人気のある1000のウェブサイトの40％が良好なCWVを持っており、これは全ウェブサイトのCWV 43％よりも低い数値です。
前述のように、INPメトリクスの切り替えによりCWVスコアは低下しました。このシフトがさまざまな技術にどのような影響を与えたかを調査しました。上の図は、INPが導入された後のさまざまな技術にわたるCWVが良好なウェブサイトの割合のパーセントポイント低下を示しています。
いくつかの技術が大きな影響を受けました。1C-Bitrix（中央アジアで人気のCMS）で19％の低下、Next.js（Reactベースのフレームワーク）で10％の低下、Emotion（CSS-in-JSツール）で8％の低下が含まれます。CWVスコアの低下が使用されている技術のみによるものであると完全に確信することはできません。Next.jsはサーバーサイドレンダリング（SSR）と静的サイト生成（SSG）機能を持っており、理論的にはINPを向上させるはずですが、それでも大幅な低下を見ています。Next.jsがReactに基づいているため、多くのウェブサイトがクライアントサイドレンダリングに依存しており、これがINPに悪影響を与える可能性があります。これは、開発者が使用するフレームワークのSSRとSSG機能を活用することを思い出させるものかもしれません。
今年の時点で、ホームページデータと比較できるセカンダリページが利用可能です。
セカンダリページは、ホームページよりも大幅に良好なCWV結果を示しています。デスクトップセカンダリページでCWVが良好な割合は、ホームページよりも14パーセントポイント良好です。モバイルウェブサイトでは、その差は13パーセントポイントです。CWVデータのみを見ることで、どのような種類のパフォーマンスエクスペリエンスが良いかを特定するのは困難です。これらの側面（レイアウトシフト、読み込み、インタラクティビティ）を対応するセクションで探ります。
読み込み速度
人々はしばしばウェブサイトの読み込み速度を単一のメトリクスとして言及しますが、実際には読み込みエクスペリエンスは多段階のプロセスです。読み込み速度を構成するすべての側面を完全に捉える単一のメトリクスはありません。すべての段階がウェブサイトの速度に影響を与えます。
Time to First Byte（TTFB）
Time to First Byte（TTFB）は、ユーザーがページの読み込みを開始してから、ブラウザが応答の最初のバイトを受信するまでの時間を測定します。これには、リダイレクト時間、DNS検索、接続とTLSネゴシエーション、リクエスト処理などのフェーズが含まれます。接続とサーバー応答時間の遅延を短縮することで、TTFBを改善できます。800ミリ秒が良好なTTFBの閾値とされています—ただし、いくつかの注意点があります！
過去5年間、良好なTTFBを持つモバイルウェブページの割合は安定しており、2021年の41％から2024年の42％となりました。TTFB改善が必要なページの割合は1％減少し、残念ながら、TTFBが悪いページの割合は同じままです。このメトリクスが大幅に変化していないため、接続速度やバックエンド遅延に大きな改善がなかったと結論できます。
First Contentful Paint（FCP）
First Contentful Paint（FCP）は、ユーザーがコンテンツを見始める速さを示すのに役立つパフォーマンスメトリクスです。ユーザーが最初にページをリクエストしてから、最初のコンテンツが画面にレンダリングされるまでの時間を測定します。良好なFCPは1.8秒未満であるべきです。
FCPは過去数年間で改善を示しています。2023年にわずかな低下がありましたが、2024年にメトリクスが回復し、デスクトップウェブサイトで68％、モバイルウェブサイトで51％に達しました。全体的に、これは最初のコンテンツが読み込まれる速さの積極的な傾向を反映しています。TTFBメトリクスがほとんど変わらなかったことを考慮すると、FCPの改善はサーバーサイド最適化よりもクライアントサイドレンダリングによって推進されている可能性があります。
興味深いことに、ウェブサイトのパフォーマンスはFCPに影響する唯一の要因ではありません。研究How Do Chrome Extensions Impact Browser Performance?で、Matt Zeunertはブラウザ拡張機能がページ読み込み時間に大きく影響することを発見しました。多くの拡張機能は、ページが読み込みを開始するとすぐにコードの実行を開始し、first contentful paintを遅延させます。たとえば、一部の拡張機能はFCPを100ミリ秒から250ミリ秒に増加させることができます。
Largest Contentful Paint（LCP）
Largest Contentful Paint（LCP）は、ビューポート内でもっとも大きな要素がどれだけ速く読み込まれるかを示すため、重要なメトリクスです。ベストプラクティスは、LCPリソースができるだけ早く読み込みを開始するようにすることです。良好なLCPは2.5秒未満であるべきです。
LCPは近年改善しており（2022年にLCPが良好なページが44％から2024年に54％へ）、CWVの全体的な積極的傾向に従っています。2024年、モバイルページの59％が良好なLCPスコアを達成しました。しかし、74％が良好なLCPを持つデスクトップサイトと比較すると、まだ大きなギャップがあります。この確立された傾向は、デバイス処理能力とネットワーク品質の違いによって説明されます。しかし、多くのウェブページがまだモバイル使用に最適化されていないことも強調されます。
ホームページとセカンダリページの比較は興味深い傾向を明らかにします：すべてのセカンダリページの72％が良好なLCPを持っており、これはホームページの結果よりも20％高いです。これは、ユーザーが通常最初にホームページをナビゲートし、初期読み込みがホームページで発生するためと考えられます。セカンダリページにナビゲートした後、多くのリソースはすでに読み込まれ、キャッシュされており、LCP要素のレンダリングが速くなります。もう1つの可能な理由は、ホームページがセカンダリページと比較して、ビデオや画像などのよりメディアリッチなコンテンツを含むことが多いことです。
LCPコンテンツタイプ
LCP要素のほとんど、つまりモバイルページの73％が画像です。興味深いことに、この割合はデスクトップページで10％高くなっています。テキストコンテンツでは状況が逆転しています。デスクトップと比較して、10％多くのモバイルウェブページがテキストをLCP要素として使用しています。この違いは、デスクトップウェブサイトがより大きなビューポートサイズと一般的により高いパフォーマンスにより、より多くの視覚的コンテンツに対応できるためと考えられます。
LCPサブパーツ
LCP要素が完全にレンダリングされる前に、処理のいくつかの段階が発生する必要があります：
- Time to First Byte（TTFB）、これはサーバーが最初のリクエストへの応答を開始するのにかかる時間です。
- Resource Load Delay、これはTTFB後にブラウザがLCPリソースの読み込みを開始するまでの時間です。テキストベースの要素やインライン画像（data URI）などのインラインリソースとして発生するLCP要素は、0ミリ秒の読み込み遅延を持ちます。外部画像のように別のアセットをダウンロードする必要があるものは、読み込み遅延を経験する可能性があります。
- Resource Load Duration、これはLCPリソースの読み込みにかかる時間を測定します；リソースが不要な場合、この段階も0ミリ秒です。
- Element Render Delay、これはリソースの読み込みが完了してからLCP要素のレンダリングが完了するまでの時間です。
記事Common Misconceptions About How to Optimize LCPで、Brendan Kennyは最近のCrUXデータを使用してLCPサブパーツの内訳を分析しました。
研究では、画像読み込み期間がLCP時間に与える影響がもっとも少なく、LCPが悪いウェブサイトの75パーセンタイルでわずか350ミリ秒であることが示されました。画像サイズ削減などのリソース読み込み期間最適化技術がしばしば推奨されますが、LCPが悪いサイトでも、他のLCPサブパーツほど多くの時間節約を提供しません。
TTFBは外部リソースへのネットワークリクエストのため、すべてのLCPサブパーツの中でもっとも大きな部分です。LCPが悪いウェブサイトはTTFBだけで2.27秒を費やしており、これは良好なLCPの閾値（2.5秒）とほぼ同じ長さです。TTFBセクションで見たように、良好なTTFBを持つウェブサイトの割合にはあまり改善がなく、このメトリクスがLCP最適化の大きな機会を提供することを示しています。
驚くことに、ウェブサイトはLCPステータスに関係なく、読み込み期間よりもリソース読み込み遅延により多くの時間を費やしています。これにより、読み込み遅延は最適化努力の良い候補となります。読み込み遅延を改善する1つの方法は、LCP要素ができるだけ早く読み込みを開始するようにすることで、これはLCP静的発見可能性のセクションで詳しく探ります。
今年、別のリアルユーザーモニタリングソースからのLCPサブパーツデータを分析しました：RUMvision。RUMvisionは異なるウェブサイト集団を持っていますが、より大きなCrUXウェブサイト集団と比較することは興味深いです。RUMvisionのようなパフォーマンス監視ツールを使用するウェブサイトは、CrUXで表される平均的なウェブサイトよりもパフォーマンス最適化の機会について多くの洞察を持つべきであると仮定します。当然、2つの異なるデータセットからのLCPサブパーツ結果はいくつかの違いを示します。
RUMvisionデータによると、TTFBは他のLCPサブパーツと比較してLCP時間へのもっとも大きな貢献者でもあります。しかし、他のサブパーツの結果は異なります。レンダリング遅延はLCPへの2番目に大きな貢献者で、184ミリ秒かかります。75パーセンタイルで、レンダリング遅延は443ミリ秒に成長します。これは、LCP読み込み遅延が2番目に大きなサブパーツであるCrUXデータセットとは異なる傾向を反映しています。
通常、LCP要素がまだDOMに追加されていない場合、LCP要素のレンダリングには長時間かかります—これは次のセクションで探るクライアントサイド生成コンテンツの一般的な問題です。また、長いタスクによってブロックされたメインスレッドも遅延に貢献する可能性があります。さらに、<head>内のスタイルシートや同期スクリプトなどのレンダリングブロッキングリソースがレンダリングを遅延させる可能性があります。
さまざまなデータセットにわたるウェブサイトが直面する異なるLCP課題を観察することは興味深いです。CrUXデータセットからの平均的なウェブサイトが画像読み込み遅延に苦労する一方で、RUMvisionデータセットからのウェブサイトはしばしばレンダリング遅延の問題に直面します。それにもかかわらず、すべてのウェブサイトはReal User Monitoring（RUM）を持つパフォーマンス監視ツールの使用から恩恵を受けることができます。これらのツールは、実際のユーザーが経験するパフォーマンス問題へのより深い洞察を提供するためです。
LCP静的発見可能性
LCPリソース読み込み遅延を最適化するもっとも効果的な方法の1つは、リソースができるだけ早く発見できるようにすることです。初期HTMLドキュメントでリソースを発見可能にすると、LCPリソースがより早くダウンロードを開始できます。
残念ながら、モバイルウェブサイトの35％はドキュメント内で静的に発見可能なLCP要素を持っていません。これは2022年に見た39％からのわずかな改善ですが、まだLCPパフォーマンスの重要な阻害要因です。
以下のセクションで探るように、ウェブサイトがLCPリソースを静的に発見可能でなくする主な方法は3つあります：遅延読み込み、CSS背景画像、クライアントサイドレンダリングです。
LCP遅延読み込み
LCPリソース発見可能性への主要な障害は、LCPリソースの遅延読み込みです。全体的に、遅延読み込み画像は、重要でないリソースの読み込みをビューポートの近くまで延期するために使用されるべき有用なパフォーマンス技術です。しかし、LCP画像で遅延読み込みを使用すると、ブラウザが素早く読み込むのを遅らせてしまいます。そのため、LCP要素には遅延読み込みを使用すべきではありません。
良いニュースは、2024年により少ないウェブサイトがこのパフォーマンスアンチパターンを使用していることです。2022年、モバイルウェブサイトの18％がLCP画像を遅延読み込みしていました。2024年までに、これは16％に減少しました。
使用される特定の遅延読み込み技術について、モバイルウェブサイトの9.5％がloading=lazy属性でLCP画像をネイティブ遅延読み込みしています。これは2022年に見た9.8％のサイトと非常に似ています。しかし、最大の改善はカスタムアプローチから来ました。今年、モバイルウェブサイトの6.7％がカスタムアプローチを使用しており、たとえばdata-src属性の背後にLCP画像ソースを隠すものがあり、これは2022年の8.8％から減少しています。
loading=lazyでのLCP画像のsrc属性は技術的に設定されており、したがって静的HTMLで発見可能であるため、前のセクションの静的発見可能性の数値には含めていないことに注意してください。しかし、ネイティブ遅延読み込み画像は確実にリソース読み込み遅延に貢献しており、次に探るように、ソースがCSSやJavaScriptによって設定される画像とは多少異なる方法でですが。
CSS背景画像
また、LCP要素をCSS背景画像として開始するウェブサイトは、CSSファイルが処理されるまでLCP静的発見を遅らせます。データは、モバイルページの9％がCSSからLCPリソースを初期化することを示しています。2022年と比較して、このメトリクスは変わっていません。
動的に追加された画像
発見不可能なLCP要素のもう1つの一般的な理由は、動的に追加された画像です。これらの画像は、初期HTMLが読み込まれた後にJavaScriptを通じてページに追加され、HTMLドキュメントスキャン中に発見不可能になります。
以下のチャートはクライアントサイド生成コンテンツの分布を示しています。初期HTMLと最終HTML（JavaScript実行後）を比較し、違いを測定します。クライアントサイド生成コンテンツの割合が増加するにつれて、良好なLCPを持つウェブサイトの割合がどう変化するかを表示します。
クライアントサイド生成コンテンツの量が70％に達するまで、良好なLCPを持つページの割合はモバイルデバイスで約60％にとどまります。この閾値の後、良好なLCPを持つウェブサイトの割合は40％で終わるまで、より速い速度で低下し始めます。これは、サーバーサイドとクライアントサイド生成コンテンツの組み合わせがLCP要素がレンダリングされる速さに大きく影響しないことを示唆しています。しかし、ウェブサイトを完全にクライアントサイドでレンダリングすることは、LCPに大きな悪影響を与えます。
LCP優先順位付け
LCP画像の読み込み遅延を最適化するもっとも効果的な方法の1つは、fetchpriority=high属性を使用して宣言的に優先順位付けすることです。LCPリソースがブラウザのプリロードスキャナーによって静的に発見可能であっても、列に他のより高い優先度のリソースがある場合、まだ即座に読み込みを開始しない可能性があります。画像は通常高優先度リソースとは見なされないため、ブラウザにこのヒントを提供することで、LCPリソースの優先度を適切に調整し、より早く読み込んで読み込み遅延フェーズを短縮できます。
fetchpriority=highを使用するモバイルページの割合。
LCP画像優先順位付けの採用は2024年にモバイルウェブサイトの15％に急上昇し、2022年のわずか0.03％から上昇しました！この大きな飛躍は、WordPressが2023年にfetchpriorityのコアサポートを実装したことに大部分起因しています。
このような急速な成長を見ることは素晴らしいことですが、この影響力のある1行最適化を活用できるより多くのサイトにはまだ大きな余地があります。
LCPサイズ
LCPサブパーツに関するCrUXとRUMvisionのデータは、リソース読み込み期間が遅いLCPの主なボトルネックになることが稀であることを示しました。しかし、LCPリソースのサイズや形式などの主要な最適化要因を分析することは依然として価値があります。
2024年、モバイルウェブサイトの48％が100KB以下のLCP画像を使用しました。ただし、モバイルページの8％についてはLCP要素サイズが1000KBを超えています。
これは、画像最適化によって節約できる無駄なキロバイト数も報告するLighthouse audit on unoptimized imagesと一致しています。
監査結果は、中央値のウェブサイトがLCP画像で0KBを無駄にしている、つまり最適化された画像を提供していることを示しています。これにより、多くのサイトがLCPリソースを効果的に最適化している一方で、一部はまだ改善が必要であるという結論に至ります。
寸法のリサイズと圧縮の増加によって画像サイズを削減できます。画像サイズを削減するもう1つの方法は、より良い圧縮アルゴリズムを持つWebPやAVIFなどの新しい画像形式を使用することです。
JPGとPNGは依然として合計87％ともっとも高い採用割合を持っていますが、WebPとAVIF形式の両方が採用率を増加させています。2022年と比較して、WebP画像形式の使用は4%から7％に増加しました。また、AVIF使用は0.1％から0.3％にわずかに増加しました。Baselineによると、AVIF形式は主要ブラウザで新しく利用可能になったため、将来的により高い採用を見ることを期待しています。
読み込み速度の結論
- 良好なFCPとLCPを持つウェブサイトの割合は改善しましたが、TTFBは大きな変化を示しませんでした。
- 遅いLCPの1つの原因は、LCP要素の遅延読み込みです。このアンチパターンの使用は減少しましたが、15％のウェブサイトがまだこのテストに失敗しており、LCP要素の遅延読み込み除去から恩恵を受けることができます。
- LCP要素について、AVIFやWebPなどの現代的な画像形式の採用が成長しています。
インタラクティビティ
ウェブサイトのインタラクティビティとは、ユーザーがページ上のコンテンツ、機能、または要素とどの程度関わり、反応できるかの度合いを指します。インタラクティビティの測定には、クリック、タップ、スクロールなどのさまざまなユーザーインタラクション、およびフォーム送信、ビデオ再生、ドラッグアンドドロップ機能などのより複雑なアクションのパフォーマンス評価が含まれます。
Interaction to Next Paint（INP）
Interaction to Next Paint（INP）は、セッション中にページで行われたすべてのインタラクションを観察し、（ほとんどのサイトで）最悪の遅延を報告することによって計算されます。インタラクションの遅延は、ユーザーがインタラクションを開始してから、ブラウザが次にフレームをペイントできる瞬間まで、インタラクションを駆動するイベントハンドラーのグループの最長の単一期間で構成されます。
オリジンが「良好な」INPスコアを受けるには、すべてのセッションの少なくとも75％が200ミリ秒以下のINPスコアを必要とします。INPスコアは、ページ上のすべてのインタラクションでもっとも遅い、またはもっとも遅いに近いインタラクション時間です。詳細については、INPの計算方法の詳細を参照してください。
2024年、モバイルの74％とデスクトップの97％のウェブサイトが良好なINPを持っていました。興味深いことに、モバイルとデスクトップの間のギャップは巨大で、つまり20％以上です。
モバイルでパフォーマンスが弱い主な理由は、その低い処理能力としばしば悪いネットワーク接続です。Alex Russellの記事「The Performance Inequality Gap」（2023年）は、ハイエンド対ローエンドデバイスの余裕によって引き起こされる拡大するパフォーマンス不平等ギャップの問題を提起します。ハイエンドデバイスの価格が上昇するにつれて、それらを買える余裕のあるユーザーが少なくなり、不平等ギャップが拡大します。
INPメトリクスはFIDよりも悪い結果を表示しますが、過去3年間にわたって積極的な傾向がありました。良好なINPを持つモバイルページの割合は、2022年の55％から2024年の74％に増加しました。これは大幅な増加であり、何に起因するかを正確に確信できませんが、この変化のいくつかの潜在的な推進要因を考えることができます。
最初のものは認識かもしれません。INPの導入とそれがFIDを置き換えるという発表により、多くのチームが全体的なCWVスコアと検索ランキングに与える影響を実感しました。それが、低いINPスコアに貢献したサイトの部分を修正する方向に積極的に取り組むことを促したかもしれません。2番目の推進要因は技術の通常の進歩かもしれません。上記に表示されたINPデータが実際のユーザーから来ているため、ユーザーのデバイスとネットワーク接続が年月とともにわずかに改善し、より良いサイトインタラクティビティを提供した可能性もあります。3番目の（そして恐らく最大の？）推進要因は、ブラウザ自体への改善です（特に我々の洞察を提供するChromeに）。Chromeチームは過去2年間でINPに影響する多くの改善を行いました。
ランク別のモバイルINPメトリクスは興味深い傾向を明らかにします。2022年の章では、ウェブサイトの人気が高いほど、パフォーマンス最適化が多く施されており、より良いパフォーマンスにつながるだろうと推測していました。しかし、INPに関しては、逆のことが当てはまるようです。
上位1,000ランクのウェブサイトで良好なINPを持つサイトは、全ウェブサイトの結果と比較して少なくなっています。たとえば、上位1,000のウェブサイトの53％が良好なINPスコアを持っているのに対し、全ウェブサイトのはるかに大きな割合、つまり74％がこの閾値を満たしています。
これは、もっとも訪問されるウェブサイトがしばしばより多くのユーザーインタラクションと複雑な機能を持っているためかもしれません。論理的に、インタラクティブなeコマースサイトのINPは、シンプルで静的なブログとは異なるでしょう。
FCPやLCPなどの他のパフォーマンスメトリクスとは異なり、良好なINPを持つセカンダリページの割合はホームページの結果と差がありません。これは、INPが読み込み速度ほどキャッシュの影響を受けないためと考えられます。
INPサブパーツ
Interaction to Next Paintメトリクスは、3つの主要なサブパーツに分解できます：
- Input Delay：インタラクションが発生した時点でキューにすでにあったタスクの処理を完了するために費やされた時間
- Processing Time：ユーザーがインタラクションした要素に添付されたイベントハンドラーの処理に費やされた時間
- Presentation Delay：変更された場合の新しいレイアウトの計算と画面での新しいピクセルのペイントに費やされた時間
ウェブサイトのインタラクティビティを最適化するには、すべてのサブパーツの期間を特定することが重要です。
RUMvisionからのINPサブパーツ期間分布データは、プレゼンテーション遅延（36ミリ秒）が中央値INPへの貢献がもっとも大きいことを示しています。パーセンタイルが増加するにつれて、入力遅延と処理時間が長くなります。75パーセンタイルでは、入力遅延が37ミリ秒、処理遅延が56ミリ秒に達します。90パーセンタイルまでには、入力遅延が155ミリ秒まで跳ね上がり、これが悪いINPへの最大の貢献要因となります。入力遅延を最適化する1つの方法は、ロングタスクを避けることで、これについてはロングタスクセクションで探ります。
ロングタスク
INPのサブパーツの1つは入力遅延で、ロングタスクを含むさまざまな要因により本来よりも長くなる可能性があります。タスクは、ブラウザが実行する個別の作業単位で、JavaScriptがしばしばタスクの最大のソースです。タスクが50ミリ秒を超えると、ロングタスクと見なされます。これらのロングタスクは、ユーザーインタラクションへの応答に遅延を引き起こし、インタラクティビティパフォーマンスに直接影響します。
ロングタスクとINPの同一ソースデータが不足しているため、それらを関連付けないことにしました。しかし、RUMvisionのデータを使用して平均ロングタスク期間を探ります。
タスク期間分布は、デスクトップで90ミリ秒、モバイルで108ミリ秒の中央値タスク期間を示しており、これは50ミリ秒未満のベストプラクティス推奨値の2倍です。25％未満のウェブサイトが50ミリ秒未満の最適なタスク期間を持っています。また、すべてのパーセンタイルにおいて、モバイルサイトのタスク期間がデスクトップサイトよりも長く、パーセンタイルが増加するにつれてギャップが拡大することがわかります。90パーセンタイルでは、デバイスタイプ間の平均タスク期間の間に46ミリ秒の差があります。これは、モバイルと比較してデスクトップでより良い結果を示すINPスコアとよく相関しています。
タスク期間データはLong Tasks APIを使用して取得されました。これは、パフォーマンス問題について有用なデータを提供しますが、動作の重さを正確に測定することについては制限があります。ロングタスクがいつ発生し、どれくらい続くかのみを識別します。レンダリングなどの重要なタスクを見落とす可能性があります。これらの制限により、次のセクションでは、より詳細な洞察を提供するLong Animation Frames APIを探ります。
ロングアニメーションフレーム
Long Animation Frames (LoAF)は、作業とレンダリングがメインスレッドをブロックするときを追跡することで、動作の重さと悪いINPを識別するためのパフォーマンスタイムラインエントリです。LoAFは、Long Tasks APIのような個別のタスクの代わりにアニメーションフレームを追跡します。ロングアニメーションフレームは、レンダリングアップデートが50ミリ秒を超えて遅延する場合です（Long Tasks APIの閾値と同じ）。これは、INPパフォーマンスのボトルネックを引き起こすスクリプトを見つけるのに役立ちます。このデータにより、LoAFの原因となるスクリプトのカテゴリーに基づいてINPパフォーマンスを分析できます。
モバイルとデスクトップデバイスで遅いINPスコアへの貢献がもっとも大きい上位2つのカテゴリーは、ユーザー行動スクリプト（モバイルの37％、デスクトップの60％のページが良好なINP）とCDN/ホスティング（モバイルの50％、デスクトップの65％のページが良好なINP）です。
ユーザー行動スクリプトには、script.hotjar.com、smartlook.com、newrelic.comなどのホストからのスクリプトが含まれます。これらのツールはユーザーについて価値ある洞察を提供しますが、我々のデータは、ウェブサイトのインタラクションを遅くすることでユーザーエクスペリエンスを大幅に悪化させる可能性があることを示しています。
CDNとホスティングスクリプトカテゴリーの例は、cdn.jsdelivr.net、ajax.cloudflare.com、cdnjs.cloudflare.com、cdn.shopify.com、sdk.awswaf.com、cloudfront.net、s3.amazonaws.comなどのドメインから来ています。CDNがもっとも悪いINP結果を持つカテゴリーに含まれることは議論の余地があるように思えます。なぜなら、CDNは通常、サーバー負荷を減らし、ユーザーによりコンテンツを速く配信するパフォーマンス最適化技術として推奨されるからです。しかし、このカテゴリーに含まれるCDNは通常、ファーストパーティまたはサードパーティのJavaScriptリソースを配信し、これがLoAFに貢献してインタラクティビティに悪影響を与えます。
モバイルデバイスでは、同意プロバイダーがINPに重要な影響を与えるようで、それらを使用するとモバイルページの53％のみが良好なINPを持つことになります。このカテゴリーは、consentframework.com、cookiepro.com、cookiebot.com、privacy-mgmt.com、usercentrics.euなどのプロバイダーで構成されます。デスクトップデバイスでは、同意プロバイダースクリプトははるかに良い結果を示し、つまり76％のページが良好なINPを持ちます。この違いは、デスクトップデバイスのより強力なプロセッサーによるものと考えられます。
注目すべきは、パフォーマンス監視ツールも含む監視カテゴリーが、悪いINP結果へのもっとも少ない影響の1つを持つことです。これは、ウェブパフォーマンス監視ツールの使用を支持する良い論拠です。これらは、インタラクティビティパフォーマンスに大きく影響することなく、価値あるウェブパフォーマンスの洞察を提供するためです。
Total Blocking Time（TBT）
Total Blocking Time（TBT）は、First Contentful Paint（FCP）後に、メインスレッドが入力応答性を阻害するのに十分な時間ブロックされた総時間を測定します。
TBTはラボメトリクスで、CrUXやRUMvisionなどのリアルユーザーモニタリングでのみ収集できるINPなどのフィールドベースの応答性メトリクスの代理として使用されることがよくあります。ラボベースのTBTとフィールドベースのINPは相関があり、TBTの結果は一般的にINPの傾向を反映します。200ミリ秒未満のTBTが良好と見なされますが、ほとんどのモバイルウェブサイトはこの目標を大幅に超えています。
モバイルの中央値TBTは1,209ミリ秒で、これはベストプラクティスの6倍高い値です。対照的に、デスクトップウェブサイトは、中央値TBTがわずか67ミリ秒と、はるかに良いパフォーマンスを示しています。ラボ結果はエミュレートされた低電力デバイスと低速ネットワークを使用するため、実際のデバイスとネットワーク条件は変化する可能性があり、実際のユーザーデータを反映していない可能性があることを強調することが重要です。しかし、それを念頭に置いても、これらの結果は、90パーセンタイルではモバイルデバイスのユーザーがサイトがインタラクティブになるまでほぼ6秒待つ必要があることを示しています。
TBTはロングタスクによって引き起こされるため、パーセンタイルごとの同じ傾向、および2つのメトリクス結果でのモバイルとデスクトップ間のギャップでの類似の傾向に気づくのは驚くことではありません。また、高いTBTがINPの入力遅延部分に貢献し、全体的なINPスコアに悪影響を与える可能性があることに注意することも重要です。
インタラクティビティの結論
インタラクティビティ結果の主な要点は以下の通りです：
- 毎年INPの改善にもかかわらず、デスクトップ（97％の良好なINP）とモバイル（74％の良好なINP）のパフォーマンス間には依然として大きなギャップが存在します。
- もっとも訪問されるウェブサイトは、人気の低いサイトと比較してより悪いINP結果を示しています。
- INPは3つのサブパーツに分けることができます：入力遅延、処理時間、プレゼンテーション遅延。プレゼンテーション遅延がRUMvisionのデータで中央値INPの最大の割合を占めています。
- ユーザー行動追跡、同意プロバイダー、CDNカテゴリーからのスクリプトが、悪いINPスコアの主な貢献要因です。
視覚的安定性
ウェブサイトの視覚的安定性は、ページが読み込まれユーザーがそれとインタラクションする際の視覚的要素の一貫性と予測可能性を指します。視覚的に安定したウェブサイトは、コンテンツが予期せずシフト、移動、レイアウト変更をしないことを保証し、ユーザーエクスペリエンスを阻害しません。これらのシフトは、寸法が指定されていないアセット（画像とビデオ）、サードパーティ広告、重いフォントなどによってしばしば発生します。視覚的安定性を測定する主要なメトリクスは、Cumulative Layout Shift（CLS）です。
Cumulative Layout Shift（CLS）
CLSは、ページが開いている間に発生する予期しないレイアウトシフトについて、レイアウトシフトスコアの最大バーストを測定します。レイアウトシフトは、可視要素がある場所から別の場所に位置を変更するときに発生します。
0.1以下のCLSスコアは良好と見なされ、ページが視覚的に安定したエクスペリエンスを提供することを意味します。0.1から0.25の間のスコアは改善の必要性を示し、0.25を超えるスコアは悪いと見なされ、ユーザーが破壊的で予期しないレイアウトシフトを経験する可能性があることを示します。
2024年、72％のウェブサイトが良好なCLSスコアを達成し、11％が悪いスコアでした。また、サイトの安定性に関して、モバイルデバイスのウェブサイトがデスクトップサイトよりも良いユーザーエクスペリエンスを提供していることもわかります。
時間の経過とともにメトリクスを見ると、良い上昇傾向を確認できます。2020年の良好な視覚的安定性を持つウェブサイトの60％から2024年のほぼ80％まで増加しています。モバイルデータの目に見える上昇は、すでに詳細に言及されており、2022年の章でbfcacheの導入に起因するとされています。2022年からの目に見える違いがまだあるため、それに貢献した可能性のある側面をいくつか詳しく見ていきます。
Back/forward cache（bfcache）
Back/forward cache（bfcache）は、ユーザーがページから離れるときに、完全にインタラクティブなページのスナップショットをメモリにキャッシュすることで、ウェブページ間のナビゲーションの速度と効率を向上させるブラウザ最適化機能です。しかし、すべてのサイトがbfcacheの対象となるわけではありません。広範囲な適格性基準があるため、サイトが適格かどうかを確認する最も簡単な方法は、Chrome DevToolsでテストすることです。
よくある原因でラボデータを使用して簡単に測定できるいくつかの適格性基準をチェックして、より深く見てみましょう。
「よくある容疑者」の1つは、ユーザーがページから離れるときにトリガーされるunloadイベントです。bfcacheがページの状態を保持する方法により、unloadイベントはページをbfcache不適格にします。ここで重要なのは、この機能はデスクトップのブラウザに特有であることです。モバイルブラウザは、bfcache適格性を決定する際にunloadイベントを無視します。これらのデバイスでは、バックグラウンドページがより頻繁に破棄されるため、すでに信頼性がないからです。この動作は、長年にわたるCLSの改善とモバイルとデスクトップの数値間のギャップを説明できるかもしれません：
ページからのunloadイベントを示す上記のチャートから、いくつかの興味深いことがわかります。全体的なイベント使用状況はかなり低く、15-16％です。しかし、上位1,000サイトでは劇的に増加し、デスクトップで35％、モバイルで27％となり、より人気のあるサイトがこの特定のイベントをよく使用するサードパーティサービスをかなり多く使用している可能性があることを示しています。モバイルとデスクトップの間のギャップは重要です。unloadイベントを使用するモバイルサイトがまだbfcacheの対象となっている一方で、それらは依然として信頼性がないからです。
Google ChromeやFirefoxなどの主要ブラウザが2020年頃からその廃止に向けて動き、pagehideやvisibilitychangeなどの代替イベントの使用を推奨していることから、unloadイベントの使用のこの減少を見ることは予想されます。これらのイベントはより信頼性があり、ブラウザのナビゲーションをブロックせず、bfcacheと互換性があり、ユーザーが前後にナビゲートするときにページをメモリに保持し、即座に復元することを可能にします。
ウェブサイトがbfcache不適格カテゴリーに分類されるもう1つの一般的な理由は、cache-control: no-storeディレクティブの使用です。このキャッシュ制御ヘッダーは、ブラウザ（および中間キャッシュ）にリソースのコピーを保存しないよう指示し、リクエストごとにサーバーからコンテンツを取得することを保証します。
Cache-Control: no-storeを使用するサイトの割合。
21％のサイトがCache-Control: no-storeを使用しています。これは、この測定値が約22％だった2022年のレポートからのわずかな減少です。
bfcacheが最初に導入されたとき、Core Web Vitalsに顕著な改善をもたらしました。それに基づいて、ChromeはCache-Control: no-storeヘッダーの使用により以前は不適格だったサイトに徐々にbfcacheを適用しています。この変更は、サイトパフォーマンスをさらに改善することを目的としています。
unloadイベントとCache-Control: no-storeは、ページの視覚的安定性に直接影響しません。すでに述べたように、bfcache読み込みの概念は副作用として、サイズが指定されていない画像や動的コンテンツなど、メトリクスに直接影響する潜在的な問題の一部を排除することで、この積極的な影響を与えます。ウェブの視覚的安定性の側面を探求し続けるために、CLSに直接影響するいくつかのプラクティスをチェックしてみましょう。
CLSベストプラクティス
以下のベストプラクティスにより、CLSを削減、または完全に回避することができます。
明示的な寸法
予期しないレイアウトシフトのもっとも一般的な理由の1つは、アセットや受信する動的コンテンツのためのスペースを保持しないことです。たとえば、画像にwidthとheight属性を追加することは、スペースを保持しシフトを回避するもっとも簡単な方法の1つです。
66％のモバイルページが少なくとも1つのサイズが指定されていない画像を持っており、これは2022年の72％からの改善です。
ウェブページあたりのサイズが指定されていない画像の中央値は2個です。90パーセンタイルに移ると、その数はデスクトップサイトで26個、モバイルで23個まで跳ね上がります。ページにサイズが指定されていない画像を持つことはレイアウトシフトのリスクとなる可能性があります。しかし、重要な側面は、画像がビューポートに影響しているかどうか、そしてもしそうなら、どの程度かを見ることです。
中央値のモバイルサイトは約100ピクセルの高さのサイズが指定されていない画像を持っています。我々のテストデバイスは512ピクセルのモバイルビューポート高さを持ち、画面幅のほぼ20％を表しています。これは、サイズが指定されていない（全幅の）画像が読み込まれるときに潜在的に下にシフトされる可能性があり、これは軽微でないシフトです。
予想通り、デスクトップページの画像の高さはより大きく、中央値のサイズが110ピクセル、90パーセンタイルで403ピクセルです。
フォント
フォントはCLSに直接影響する可能性があります。ウェブフォントが非同期で読み込まれる場合、ページの初期レンダリングとカスタムフォントが適用される時間の間に遅延が発生します。この遅延中、ブラウザはしばしばフォールバックフォントを使用してテキストを表示しますが、これはウェブフォントと比較して異なる寸法（幅、高さ、文字間隔）を持つ可能性があります。ウェブフォントが最終的に読み込まれると、テキストが新しい寸法に合わせてシフトし、目に見えるレイアウトシフトを引き起こし、より高いCLSスコアに貢献する可能性があります。
システムフォントを使用することは、この問題を修正する1つの方法です。しかし、85％のモバイルページがウェブフォントを使用しているため、近い将来それらの使用が停止される可能性は非常に低いです。ウェブフォントを使用するサイトの視覚的安定性を制御する方法は、CSSでfont-displayプロパティを使用してフォントの読み込みと表示方法を制御することです。パフォーマンスと美的観点のトレードオフについてのチームの決定に応じて、異なるfont-display戦略を使用できます。
上に表示されたデータから、モバイルとデスクトップサイトの両方の約44％がfont-display:swapを使用している一方で、23％のサイトがfont-display:blockを使用していることがわかります。9％のサイトがfont-displayプロパティをautoに設定し、3％がfallbackプロパティを使用しています。約1％のサイトのみがoptional戦略を使用しています。
2022年のデータと比較すると、すべてのfont-display戦略の使用に目に見える増加があり、最大のものはswapで、モバイルとデスクトップページ両方での使用が2022年の約30％から44％超まで上昇しました。
ほとんどのfont-display戦略がCLSに貢献する可能性があるため、潜在的な問題を最小化するための他の戦略を見る必要があります。その1つは、サードパーティフォントができるだけ早く発見され読み込まれることを保証するためにリソースヒントを使用することです。
テストされたモバイルとデスクトップページの全体の約11％がウェブフォントをプリロードしており、ブラウザにこれらのファイルをダウンロードするよう指示し、フォントの遅い到着によるシフトを回避できるよう早期にダウンロードできることを期待しています。プリロードを不正に使用すると、それを助ける代わりにパフォーマンスを害する可能性があることに注意してください。これを回避するには、プリロードされたフォントが使用されることを確認し、あまりに多くのアセットをプリロードしないことが必要です。あまりに多くのアセットをプリロードすると、他のより重要なリソースを遅延させることになる可能性があります。
18％のサイトがpreconnectを使用してサードパーティオリジンへの早期接続を確立しています。preloadと同様に、このリソースヒントを慎重に使用し、やりすぎないことが重要です。
アニメーション
予期しないシフトのもう1つの原因は、非合成CSSアニメーションです。これらのアニメーションは、複数の要素のレイアウトや外観に影響するプロパティの変更を含み、スタイルの再計算、ドキュメントのリフロー、画面のピクセルの再描画などのよりパフォーマンス集約的なステップを通過することをブラウザに強制します。ベストプラクティスは、代わりにtransformやopacityなどのCSSプロパティを使用することです。
39％のモバイルページと42％のデスクトップページがまだ非合成アニメーションを使用しており、これは2022年の分析でのモバイル38％、デスクトップ41％からの非常にわずかな増加です。
視覚的安定性の結論
サイトの視覚的安定性は、ページのユーザーエクスペリエンスに大きな影響を与える可能性があります。読んでいる間にテキストがシフトしたり、クリックしようとしていたボタンがビューポートから消えたりすることは、ユーザーフラストレーションにつながる可能性があります。良いニュースは、Cumulative Layout Shift（CLS）が2024年に改善し続けたことです。これは、画像のサイジングや動的コンテンツのスペース保持などの良いプラクティスを採用し、このブラウザ機能から恩恵を受けるためにbfcache適格性を最適化するウェブサイト所有者がますます増えていることを示しています。
結論
ウェブパフォーマンスは2024年に改善し続け、多くの主要メトリクスにわたって積極的な傾向を示しました。ウェブサイトのインタラクティビティを評価するより包括的なメトリクス、つまりINPを持つようになり、これがさらに大きなパフォーマンス最適化につながることが期待されます。
しかし、課題は残っています。たとえば、デスクトップとモバイル間でINPパフォーマンスにまだ大きなギャップがあります。プレゼンテーション遅延が悪いINPの主な貢献要因で、主に行動追跡、同意プロバイダー、CDNのサードパーティスクリプトによって引き起こされます。
視覚的安定性は、適切な画像サイジングや動的コンテンツのスペース保持などのベストプラクティスの採用により改善し続けています。さらに、Chromeのbfcache適格性の最近の変更により、より多くのサイトがより速い戻る・進むナビゲーションから恩恵を受けるでしょう。
全体的に、ウェブパフォーマンスは有望な軌道にあり、読み込み時間をより速く、インタラクティビティをよりスムーズに、視覚的安定性をより信頼性があるものにしています。しかし、モバイルとデスクトップエクスペリエンス間の違いは依然として大きいです。将来のWeb Almanacレポートでは、このギャップが減少し、すべてのデバイスにわたって一貫したウェブエクスペリエンスを実現することを期待しています。
