開示: この章は、Core Web Vitalsプログラムを作成したGoogleの従業員によって共同執筆されています。この章とその基礎となる分析は、Googleと無関係の他の人々によってレビューされ、承認されました。
+ +## Core Web Vitals + +CWVがGoogle Searchのランキングシグナルとして追加されてから1年が経ちましたので、このプログラムがウェブ上のユーザーエクスペリエンスにどのような影響を与えたかを見てみましょう。 + +{{ figure_markup( + image="good-core-web-vitals-by-device.png", + caption="デバイスと年によって分けられた良好なCWVを持つウェブサイトの割合。", + description="2020年にはデスクトップで使用されるウェブサイトの34%、電話での24%が良好なCore Web Vitalsを持っていました。2021年にはそれぞれ41%と29%に増加し、2022年にはさらにデスクトップサイトが44%、電話サイトが39%に増加しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=1239858329&format=interactive", + sheets_gid="555510064", + sql_file="web_vitals_by_device.sql" + ) +}} + +2021年には、モバイルユーザー向けのウェブサイトの29%が良好なCWVと評価されました。これは2020年からの大幅なステップアップで、5ポイントの増加を表しています。しかし、2022年の進歩はさらに大きな前進で、モバイルで良好なCWVを持つウェブサイトは39%になり、さらに10ポイントの増加を表しました！ + +デスクトップで良好なCWVを持つウェブサイトは44%です。これはモバイルよりも良いですが、デスクトップ体験の改善率はモバイルほど速くはないため、ギャップは縮まっています。 + +モバイル体験がデスクトップよりも悪い理由にはいくつかの説明があります。ポケットサイズのコンピューターの携帯性は大きな便利さですが、ユーザーエクスペリエンスに悪影響を及ぼす可能性があります。[モバイルウェブ](./mobile-web#モバイルパフォーマンス)章で説明されているように、小さなフォームファクターは搭載できる処理能力の量に影響を与え、これはさらに、より強力な電話を所有するための高コストによって制約されます。処理能力が低いデバイスは、ウェブページをレンダリングするために必要な計算を実行するのにより長い時間がかかります。これらのデバイスの携帯性は、ウェブサイトのロード速度に影響を与える貧弱な接続性のエリアに持ち込むことができることも意味します。最後に、開発者がウェブサイトを構築する方法についての考慮事項があります。ページのモバイルフレンドリーなバージョンを作成するのではなく、一部のウェブサイトはデスクトップサイズの画像や不必要な量のスクリプト機能を提供しているかもしれません。これらのことはすべて、モバイルユーザーをデスクトップユーザーと比較して不利にする可能性があり、彼らのCWVパフォーマンスが低いことを説明するのに役立つかもしれません。 + +2022年には、2021年と比較して、はるかに多くのウェブサイトが良好なCWVと評価されました。しかし、その改善はウェブ全体でどれほど均等に分配されましたか？ + +{{ figure_markup( + image="good-cwv-performance-by-rank-and-year.png", + caption="ランクと年によって分けられた良好なCWVを持つウェブサイトの割合。", + description="2021年と2022年にランクごとに良好なCore Web Vitalsを持つウェブサイトの分布を示す棒グラフ。2021年では、トップ1,000のウェブサイトで37%、トップ10,000で31%、トップ100,000で29%、トップミリオンで30%、全体で32%でした。2022年では、トップ1,000のウェブサイトで53%、トップ10,000で44%、トップ100,000で40%、トップミリオンで40%、全体で42%でした。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=737356809&format=interactive", + sheets_gid="863235163", + sql_file="web_vitals_by_rank_and_device.sql" + ) +}} + +私たちは、相対的な人気（ランク）と年によってサイトを区分しましたが、デスクトップとモバイルの区別はしませんでした。興味深いことに、どうやら今年は人気のあるサイトに関係なく、全体的にウェブサイトがよりパフォーマントになったようです。もっとも人気のあるトップ1,000のウェブサイトがもっとも顕著に改善され、53%に16ポイントの増加を遂げましたが、すべてのランクが10ポイント以上改善されました。人気のあるウェブサイトは、もっとも良いCWV体験を持っている傾向がありますが、これは、彼らがより大きなエンジニアリングチームと予算を持っていると仮定するとあまり驚くことではありません。 + +今年、モバイル体験がこれほど改善された理由をより深く理解するために、個々のCWV指標についてさらに詳しく掘り下げてみましょう。 + +## 最大のコンテントフルペイント（LCP） + +最大のコンテントフルペイント（LCP）は、ナビゲーションの開始からビューポート内で最大のコンテンツブロックが表示されるまでの時間です。この指標は、ユーザーがもっとも意味のあるコンテンツをどれだけ早く見ることができるかを表しています。 + +ウェブサイトのLCPが良好であるとは、すべてのページビューの少なくとも75%が2,500ミリ秒よりも速い場合を指します。3つのCWV指標の中で、LCPの合格率はもっとも低く、良好なCWV評価を達成する上でのボトルネックとなることがよくあります。 + +{{ figure_markup( + image="good-lcp-by-device.png", + caption="デバイスと年に分けられた良好なLCPを持つウェブサイトの割合。", + description="棒グラフによると、良好なLCPを持つウェブサイトの数は2020年の53%から2021年には60%に増加し、2022年には63%になりました。携帯電話で訪問されたサイトでは、2020年の43%から2021年には45%に、そして2022年には51%に増加しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=1542261080&format=interactive", + sheets_gid="555510064", + sql_file="web_vitals_by_device.sql" + ) +}} + +今年、モバイルで良好なLCP体験を提供するウェブサイトは51%で、デスクトップでは63%です。LCPは、ウェブサイトのモバイル体験が2022年に大幅に改善された主な理由の1つであり、今年は6ポイントの改善がありました。 + +なぜLCPは今年これほど改善されたのでしょうか？それを理解するために、いくつかのローディングパフォーマンス診断指標、TTFBとFCPを探ってみましょう。 + +### 最初のバイトまでの時間（TTFB） + +最初のバイトまでの時間（TTFB）は、ナビゲーションの開始からクライアントに返される最初のデータバイトまでの時間です。これはウェブパフォーマンスチェックリストの最初のステップであり、とくにネットワーク接続速度とサーバー応答時間に関して、LCPパフォーマンスのバックエンドコンポーネントを表しています。 + +{{ figure_markup( + image="good-ttfb-by-device.png", + caption="デバイスと年に分けられた良好なTTFBを持つウェブサイトの割合。", + description="棒グラフによると、良好なTTFBを持つウェブサイトの数は2020年の47%から2021年には51%に増加し、2022年には52%になりました。携帯電話で訪問されたサイトでは、2020年に良好なTTFBを達成したサイトは41%、2021年は39%、2022年は40%とほぼ安定しています。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=628253519&format=interactive", + sheets_gid="555510064", + sql_file="web_vitals_by_device.sql" + ) +}} + +余談ですが、Chromeは今年初めに「良好」なTTFBの閾値を500ミリ秒から800ミリ秒に変更しました。上のグラフでは、比較目的でこの新しい閾値を使用して過去のデータすべてが示されています。 + +これを念頭に置くと、良好なTTFBを持つウェブサイトの割合は実際にはあまり改善していません。過去1年間で、ウェブサイトのデスクトップとモバイル体験は1ポイント改善されたに過ぎず、これは良いことですが、LCPに観察された利得を説明するものではありません。「必要な改善」と「不十分」のTTFB分布の両端に改善がなかったわけではありませんが、「良好」な端がもっとも重要です。 + +もう1つの複雑な点は、TTFBがCrUXで依然として実験的な指標とみなされていることです。CrUXのドキュメントによると、TTFBは、プリレンダリングや戻る/進むナビゲーションなど、より高度なナビゲーションタイプを考慮に入れていません。これはある種の盲点であり、これらの領域で改善があった場合、それらは必ずしもTTFBの結果に影響を与えるとは限りません。 + +### 視覚コンテンツの初期表示時間（FCP） + +視覚コンテンツの初期表示時間（FCP）は、リクエストの開始から画面に最初の意味のあるコンテンツが描画されるまでの時間です。TTFBと同様に、この指標はレンダリングをブロックするコンテンツの影響を受けることがあります。「良好」なFCPの閾値は1,800ミリ秒です。 + +{{ figure_markup( + image="good-fcp-by-device.png", + caption="デバイスと年に分けられた良好なFCPを持つウェブサイトの割合。", + description="棒グラフによると、良好なFCPを持つウェブサイトの数は2020年の53%から2021年には60%に増加し、2022年には64%になりました。携帯電話で訪問されたサイトでは、2020年に良好なFCPを達成したサイトは38%で、2021年も同じで、2022年には49%に増加しました。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=831105883&format=interactive", + sheets_gid="555510064", + sql_file="web_vitals_by_device.sql" + ) +}} + +FCPは今年、劇的に改善されました。モバイルウェブサイトの49%が良好な体験を提供し、デスクトップでは64%です。これは、モバイルとデスクトップそれぞれについて、11ポイントと4ポイントの増加を表しています。 + +TTFBのデータが反対のことを示していない限り、これはフロントエンドの最適化、たとえばレンダリングをブロックするリソースの削除やリソースの優先順位付けの改善など、大幅な改善があったことを示しています。しかし、以下のセクションで見るように、今年のLCPの改善に感謝すべきはまったく別の何かかもしれません。 + +### LCPメタデータとベストプラクティス + +これらのパフォーマンスの改善は、実際にはウェブサイト自体の変更によるものではないかもしれません。ネットワークインフラ、オペレーティングシステム、またはブラウザの変更も、このようにウェブスケールでLCPパフォーマンスに影響を与える可能性があります。そこで、いくつかのヒューリスティックに深く掘り下げてみましょう。 + +#### レンダリングをブロックするリソース + +ページにレンダリングをブロックするリソースがあるとは、リソースがページの初期描画（またはレンダリング）を遅らせる場合を指します。これは、ネットワーク経由でロードされる重要なスクリプトやスタイルにとくに当てはまります。Lighthouseには、これらのリソースをチェックする監査が含まれており、CrUXの各ウェブサイトのホームページで実行しました。これらのページをどのようにテストしているかについては、[Methodology](./methodology)で詳しく学ぶことができます。 + +{{ figure_markup( + image="pages-passing-render-blocking-resources-audit.png", + caption="レンダリングをブロックするLighthouse監査に合格したページの割合、デバイスと年別。", + description="棒グラフによると、2021年にモバイルページの19%が「レンダリングをブロックするリソース」監査に合格しました。2022年にはわずかに増加して20%になり、デスクトップの同等のデータも追加され、14%でした。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=1619115021&format=interactive", + sheets_gid="1317344415", + sql_file="render_blocking_resources.sql" + ) +}} + +驚くべきことに、レンダリングをブロックするリソースを持つページの割合に劇的な改善はありませんでした。モバイルページのわずか20%が監査に合格しており、これは昨年からわずか1ポイントの増加に過ぎません。 + +2022年は、デスクトップのLighthouseデータを持つ最初の年です。したがって、以前の年と比較することはできませんが、デスクトップページがLCPとFCPのパフォーマンスがより良い傾向にあるにもかかわらず、モバイルに比べて監査に合格するデスクトップページがはるかに少ないことは興味深いことです。 + +#### LCPコンテンツタイプ + +LCP要素は、画像、見出し、またはテキストの段落など、さまざまなタイプのコンテンツである可能性があります。 + +{{ figure_markup( + image="top-lcp-element-types.png", + caption="LCP要素として特定の要素を持つページの割合。", + description="棒グラフによると、`IMG`はデスクトップページの47%、モバイルページの42%でLCP要素です。`DIV`はそれぞれ28%と26%、`P`は6%と9%、`H1`は3%と5%、`undetected`は3%と3%、`SECTION`は3%と3%、`H2`は1%と2%、`A`は1%と2%、`SPAN`は1%と1%、`H3`は0%と1%、`HEADER`は1%と1%、`LI`は1%と1%、`RS-SBG`は1%と1%、`TD`は1%と1%、`VIDEO`は0%と0%、最後に`H4`はデスクトップとモバイルの両方のページで0%のLCP要素タイプです。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=932136285&format=interactive", + sheets_gid="1174093943", + sql_file="lcp_element_data.sql", + width=600, + height=702 + ) +}} + +画像はもっとも一般的なLCPコンテンツタイプであり、`img`要素はモバイルページの42%でLCPを表しています。モバイルページでは、見出しや段落の要素がLCPとなる可能性がデスクトップページよりもわずかに高く、デスクトップページでは画像要素がLCPとなる可能性が高くなっています。1つの可能な説明は、とくに縦向きのモバイルレイアウトでは、レスポンシブでない画像が小さく表示されるため、見出しや段落のような大きなテキストブロックがLCP要素になるというものです。 + +2番目に人気のあるLCP要素タイプは`div`です。これは、テキストや背景画像のスタイリングに使用される汎用的なHTMLコンテナーです。これらの要素が画像やテキストを含んでいる頻度を詳しく評価するために、[LCP API](https://developer.mozilla.org/docs/Web/API/LargestContentfulPaint)の`url`プロパティを評価できます。仕様によると、このプロパティが設定されている場合、LCPコンテンツは画像でなければなりません。 + +{{ figure_markup( + image="top-lcp-content-types.png", + caption="LCPコンテンツのタイプごとのページの割合。", + description="棒グラフによると、画像はデスクトップページの82%、モバイルページの72%でLCPコンテンツタイプです。テキストはそれぞれ17%と26%、インライン画像はデスクトップの2%、モバイルの1%です。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vR-dJP3uphZoGE5A_luniNBFm5V2ww6irfOxANg0hrMid7gjgrtchsN_utOIDOvVZUjIwpmUBb27nHF/pubchart?oid=839846485&format=interactive", + sheets_gid="872701281", + sql_file="lcp_resource_type.sql" + ) +}} + +モバイルページの72%、デスクトップページの82%が画像をLCPとしています。たとえば、これらの画像は従来の`img`要素やCSSの背景画像である可能性があります。これは、前の図で見た`div`要素の大部分も画像であることを示唆しています。モバイルページの26%、デスクトップページの17%がテキストベースのコンテンツをLCPとしています。 + +ページの1%が実際にインライン画像をLCPコンテンツとして使用しています。これは、キャッシュや複雑さを中心に、さまざまな理由でほとんど常に悪いアイデアです。 + +#### LCPの優先順位付け + +HTMLドキュメントがロードされた後、LCPリソース自体をいかに早くロードできるかに影響を与える2つの主要な要因があります：発見可能性と優先順位付け。[LCPの発見可能性](#lcpの静的発見可能性)については後で探りますが、まずLCP画像がどのように優先されるかを見てみましょう。 + +画像はデフォルトでは高優先度でロードされませんが、新しい優先度のヒント APIのおかげで、開発者はLCP画像を高優先度でロードするように明示的に設定し、非必須リソースよりも優先させることができます。 + +{{ figure_markup( + content="0.03%", + caption="LCP要素に`fetchpriority=high`を使用しているページの割合。", + classes="big-number", + sheets_gid="600760184", + sql_file="lcp_element_data_2.sql" + ) +}} + +0.03%のページがLCP要素に`fetchpriority=high`を使用しています。逆効果的に、いくつかのページは実際にLCP画像の優先度を下げています：モバイルで77ページ、デスクトップで104ページです。 + +`fetchpriority`はまだ非常に新しく、どこでもサポートされているわけではありませんが、ほとんどの開発者のツールボックスになぜ含まれていないのかについてはほとんど理由がありません。APIを開発した[Patrick Meenan](https://twitter.com/patmeenan)は、実装が相対的に簡単であることに対して潜在的な改善がどれほど大きいかを考えると、それを「チートコード」と[表現しています](https://twitter.com/patmeenan/status/1460276602479251457)。 + +#### LCPの静的発見可能性 + +LCP画像が早期に発見されることは、ブラウザができるだけ早くそれをロードするための鍵です。上で議論した[prioritization](#lcpの優先順位付け)の改善でさえ、ブラウザが後でリソースをロードする必要があることを知らない場合には役立ちません。 + +LCP画像が_静的に発見可能_であるとは、そのソースURLがサーバーから送信されたマークアップから直接解析できる場合を指します。この定義には、`picture`または`img`要素内で定義されたソースおよび明示的にプリロードされたソースが含まれます。 + +1つの注意点は、この定義に基づくと、テキストベースのLCPコンテンツは常に静的に発見可能であるということです。しかし、テキストベースのコンテンツはクライアントサイドレンダリングやWebフォントに依存することがあるため、これらの結果を下限として考えてください。 + +```html +++まず、INPはTBTと相関していますか？FIDよりもTBTとの相関が強いですか？はい、そうです！
+しかし、両方のメトリックがTBTと相関しています。INPはメインスレッドをブロックするJavaScriptの問題をより多く捕捉していますか？「良い」閾値を満たすサイトの割合を分解することで、はい、そうです！
+
+```
+
+カスタムの遅延読み込み技術のような上記の例は、画像が静的に発見可能でないようにする方法の1つです。これは、`src`属性を更新するためにJavaScriptに依存しているためです。クライアントサイドのレンダリングもLCPコンテンツを隠す可能性があります。
+
+{{ figure_markup(
+ content="39%",
+ caption="LCP要素が静的に発見可能でなかったモバイルページの割合。",
+ classes="big-number",
+ sheets_gid="1465687616",
+ sql_file="lcp_preload_discoverable.sql"
+ )
+}}
+
+モバイルページの39%が静的に発見可能でないLCP要素を持っています。この数字はデスクトップでは44%のページでさらに悪いです。これは、前のセクションの発見によるものかもしれません。それによると、LCPコンテンツがデスクトップページで画像である可能性が高いです。
+
+これは、この指標を見る最初の年なので比較のための歴史的データはありませんが、これらの結果は、LCPリソースのロード遅延を改善する大きな機会があることを示唆しています。
+
+#### LCPのプリロード
+
+LCP画像が静的に発見可能でない場合、