この記事はAhrefs公式ブログの日本語訳です。
原文：What Is Largest Contentful Paint (LCP) & How To Improve It
（著者：Patrick Stox/ 原文の最終更新日：March 22, 2024）
※フルスピード註：この記事は2024年3月22日時点の記載をもとに翻訳しています。Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。
Largest Contentful Paint (LCP) は、ビューポートに表示される単一の最大の要素を読み込むのにかかる時間です。これは、視覚的に読み込まれている Web サイトを表し、Google がページ エクスペリエンスを測定するために使用する 3 つの Core Web Vitals (CWV) 指標の 1 つです。
ユーザーがサイトに対して抱く第一印象は、サイトの読み込み速度です。
通常、最大の要素はアイキャッチ画像、または <h1> タグになります。ただし、次のいずれかである可能性もあります。
- <img> 要素
- <svg> 要素内の <image> 要素
- <video> 要素内の画像
- url() 関数でロードされた背景画像
- テキストのブロック
- 自動再生 <video> 要素用にペイントされた最初のフレーム
- アニメーション GIF などのアニメーション画像形式の最初のフレーム
サイズを計算する際、ビューポートの外側にあるものやオーバーフローは考慮されません。画像がビューポート全体を占める場合、その画像は LCP の対象として考慮されません。
LCP がどれくらいの速度であるべきか、そしてそれを改善する方法を見てみましょう。
適切な LCP 値はどれくらいなのか?
適切な LCP 値は 2.5 秒未満であり、Chrome ユーザー エクスペリエンス レポート (CrUX) データに基づく必要があります。これは、サイトを訪問し、この情報の共有をオプトインしている Chrome の実際のユーザーからのデータです。ページ訪問の 75% を 2.5 秒以内に読み込む必要があります。
ページは次のいずれかのバケットに分類される場合があります。
- 良好: <=2.5 秒
- 改善が必要: >2.5 秒、<=4 秒
- 悪い: >4 秒
LCPデータ
2023 年 4 月の時点で、サイトの 57.1% が良好な LCP バケットに入っています。これはサイト全体の平均です。前述したように、ここで「良好」と表示するには、ページ訪問の 75% が 2.5 秒以内に読み込まれる必要があります。
LCP は、人々が改善に最も苦労している Core Web Vital です。
Core Web Vitals に関する調査を実施したところ、モバイル デバイスではデスクトップに比べてページの LCP 値が良好である可能性が低いことがわかりました。
低速接続では LCP しきい値を通過することはほとんど不可能と思われます。
LCPの測定方法
LCP を測定するには、フィールド データとラボ データといういくつかの方法を確認する必要があります。
フィールド データは、データの共有を選択した Chrome の実際のユーザーからのデータであるChrome ユーザー エクスペリエンス レポート (CrUX)から取得されます。これにより、さまざまなネットワーク条件、デバイス、キャッシュなどにおける実際の LCP パフォーマンスについての最良のアイデアが得られます。これは、Google によるCore Web Vitalsの実際の測定対象でもあります。
実験室データは、テストを再現可能にするために同じ条件でのテストに基づいています。 Google はこれを Core Web Vitals に使用しませんが、CrUX/フィールド データは 28 日間の移動平均であるため、変更の影響を確認するのに時間がかかるため、テストには役立ちます。
LCP を測定する最適なツールは、必要なデータのタイプ (研究室/現場)、および 1 つの URL に対して必要か、複数の URL に対して必要かによって異なります。
単一 URL の LCP の測定
Pagespeed Insights は、他の方法では CrUX データセットでクエリできないページレベルのフィールド データを取得します。また、Google Lighthouseに基づいてラボ テストを実行し、元のデータを提供するので、ページのパフォーマンスをサイト全体と比較できます。
多数の URL またはサイト全体の LCP を測定する
Google Search Console で CrUX データを取得でき、良好、改善が必要、不良のカテゴリに分類されます。
問題の 1 つをクリックすると、影響を受けるページ グループの内訳が表示されます。グループは、同じテンプレートを使用する可能性が高い、同様の値を持つページです。テンプレートで一度変更を加えると、その変更はグループ内のページ全体で修正されます。
ラボ データとフィールド データの両方を大規模に取得したい場合、それを取得する唯一の方法は PageSpeed Insights API を使用することです。 Ahrefs のサイト監査を使用して簡単に接続し、パフォーマンスの詳細を示すレポートを取得できます。これは、Ahrefs ウェブマスター ツール(AWT) アカウントを持つ検証済みサイトの場合は無料です。
表示される Core Web Vitals データは、セットアップ中にクロール用に選択したユーザー エージェントによって決定されることに注意してください。モバイルからクロールする場合は、API からモバイル CWV 値を取得します。
LCPを改善する方法
PageSpeed Insights では、LCP 要素は「診断」セクションで指定されます。また、LCP に関連する問題のみを表示する LCP を選択するタブがあることにも注意してください。これらは、ラボ テストで確認された、解決する必要がある問題です。
LCP には関連する問題が数多くあるため、改善が最も難しい指標となっています。
一般理論は十分に簡単に思えます。最大の要素を早く教えてください。しかし実際には、これはかなり複雑になる可能性があります。ファイルによっては、他のファイルを最初にロードする必要がある場合や、ブラウザ内で優先順位が競合している場合があります。多くの問題を修正しても実際には改善が見られない場合があり、イライラする可能性があります。
あまり技術的知識がなく、人を雇いたくない場合は、使用しているシステムに合わせて、パフォーマンスまたはページ速度を最適化するプラグイン、モジュール、またはパッケージを探してください。以下の情報は、必要な機能のガイドとして使用できます。
LCP を改善する方法は次のとおりです。
1. LCP 要素を見つける
PageSpeed Insights では、[診断] セクションの [最大のコンテンツフル ペイント要素] をクリックすると、LCP 要素が識別されます。
2. リソースのロードを優先する
LCP チェックに合格するには、クリティカル レンダリング パスにリソースがどのように読み込まれるかを優先する必要があります。つまり、リソースがダウンロードされて処理される順序を並べ替えたいということです。
まず、LCP 要素に必要なリソースと、スクロールせずに見える範囲のコンテンツに必要なその他のリソースをロードする必要があります。最初に表示される要素がユーザーにロードされた後、残りの要素がロードされます。
多くのサイトでは、初期のヒントを追加したり、メイン画像や必要なスタイルシートやフォントなどのプリロード ステートメントを追加するだけで、LCP の使用を終了できます。さまざまなリソースタイプを最適化する方法を見てみましょう。
初期の画像
画像が必要ない場合、最も効果的な解決策は、単純に画像を削除することです。画像が必要な場合は、サイズと品質を最適化して、画像をできるだけ小さくすることをお勧めします。
Early Hintsを使用することもできます。 Fetchpriority=”high” は <img> タグまたは <link> タグで使用でき、ブラウザーに画像を早期に取得するように指示します。これは、少し早く表示されることを意味します。
Early Hints はすべてのブラウザで機能するわけではないため、画像をプリロードすることもできます。これにより、イメージのダウンロードが少し早く開始されますが、fetchpriority=”high” ほど早くは開始されません。
レスポンシブ画像のプリロードステートメントは次のようになります。
<link rel="preload" as="image" href=“cat.jpg"
imagesrcset=“cat_400px.jpg 400w,
cat_800px.jpg 800w, cat_1600px.jpg 1600w"
imagesizes="50vw">
fetchpriority=”high” とプリロードを一緒に使用することもできます。
画像が遅い
すぐに必要でないイメージは遅延ロードする必要があります。これにより、プロセスの後半、またはユーザーが画像を表示する直前に画像が読み込まれます。次のように、loading=“lazy” を使用できます。
<img src=“cat.jpg" alt=“cat" loading="lazy">
画像をスクロールせずに見える範囲に遅延ロードしないでください。
CSS初期
持っている CSS はすべて縮小する必要があります。可能であれば、未使用の CSS も削除します。
あなたがすべきもう 1 つの主要なことは、重要な CSS をインライン化することです。これは、ユーザーに表示されるコンテンツをすぐに読み込むために必要な CSS の一部を取得し、それを HTML に直接適用します。 HTML がダウンロードされると、ユーザーに表示される内容を読み込むために必要なすべての CSS がすでに利用可能になります。
CSSが遅い
重要ではない追加の CSS がある場合は、プロセスの後半で適用することをお勧めします。 preload ステートメントを使用して CSS のダウンロードを開始しても、後で onload イベントを使用するまで CSS を適用することはできません。これは次のようになります。
<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">
フォント
ここではいくつかのオプションを紹介します。
良い例: フォントをプリロードします。同じサーバーを使用して接続を解除するとさらに良いでしょう。
より良い:フォント表示: オプション。これは、プリロード ステートメントと組み合わせることができます。これにより、フォントの読み込みに少し時間がかかります。フォントが間に合わない場合、最初のページ読み込みではデフォルトのフォントが表示されます。カスタム フォントはキャッシュされ、その後のページ読み込み時に表示されます。
最善の方法: システム フォントを使用するだけです。ロードするものは何もないので、遅延はありません。
JavaScript 初期
未使用の JavaScript を削除し、既存のものを縮小することについてはすでに説明しました。 JavaScript フレームワークを使用している場合は、ページを事前レンダリングまたはサーバーサイド レンダリング (SSR)することができます。
必要な JavaScript を早い段階でインライン化することもできます。これは、CSS セクションで説明したのと同じように機能し、JavaScript ファイルから一部を移動して、代わりに HTML でロードします。
もう 1 つのオプションは、JavaScript ファイルをプリロードして、より早く取得できるようにすることです。これは、スクロールせずに見える範囲にあるコンテンツを読み込むために必要なアセットに対してのみ、または一部の機能がこの JavaScript に依存している場合にのみ実行してください。
JavaScriptが遅い
すぐには必要ない JavaScript は、後でロードする必要があります。これを行うには、defer 属性と async 属性という 2 つの主な方法があります。これらの属性はスクリプト タグに追加できます。
通常、ダウンロード中のスクリプトは、ダウンロードおよび実行中にパーサーをブロックします。非同期では、解析とダウンロードを同時に実行できますが、スクリプトの実行中に解析はブロックされます。 Defer はダウンロード中に解析をブロックせず、HTML の解析が終了した後にのみ実行されます。
どれを使用するべきですか?もっと早くに実行したいものや依存関係があるものについては、私は非同期を使用することをお勧めします。
たとえば、より多くのユーザーが記録されるように、分析タグで非同期を使用する傾向があります。必要でないもの、または依存関係がないものはすべて延期する必要があります。属性の追加は非常に簡単です。
これらの例を確認してください。
普通：
<script src="https://www.domain.com/file.js"></script>
非同期:
<script src="https://www.domain.com/file.js" async></script>
延期:
<script src="https://www.domain.com/file.js" defer></script>
3. ファイルを小さくする
ファイルを削除するか、ファイルのサイズを減らすことができれば、ページの読み込みが速くなります。これは、使用されていないファイルや使用されていないコードの一部を削除する必要があることを意味します。
これをどのように行うかは設定によって大きく異なりますが、ファイルの不要な部分を削除するプロセスは通常、ツリー シェーキングと呼ばれます。
これは通常、JavaScript フレームワークを使用した Webpack または Grunt を使用した自動プロセス、または場合によっては WordPress などのシステムを使用して行われますが、ほとんどの一般的な CMS システムはこれをサポートしていない可能性があります。
これをスキップするか、システムにこのオプションを備えたプラグインがあるかどうかを確認することをお勧めします。
ファイルを小さくするには、通常、ファイルを圧縮します。
CSS、JavaScript、画像、HTML など、Web サイトの構築に使用されるほとんどすべてのファイル タイプを圧縮できます。また、ほぼすべてのシステムとサーバーが圧縮をサポートしています。
通常、これはサーバーまたは CDN レベルで行われますが、WP Rocket for WordPress などの一部のプラグインはこれをサポートしています。
4. ユーザーの近くでファイルを提供する
情報が伝わるまでには時間がかかります。サーバーから離れるほど、データの転送に時間がかかります。地理的に狭いエリアにサービスを提供している場合を除き、コンテンツデリバリーネットワーク (CDN)を使用することをお勧めします。
CDN は、ユーザーに近いサイトに接続してサービスを提供する方法を提供します。これは、サーバーのコピーを世界中のさまざまな場所に置くようなものです。
5. 同じサーバー上のホストリソース
初めてサーバーに接続すると、Web をナビゲートし、サーバーとの間に安全な接続を確立するプロセスが実行されます。
これには時間がかかり、同じプロセスを経る間に新しい接続を確立する必要があるため、さらに遅延が発生します。同じサーバー上でリソースをホストすると、余分な遅延を排除できます。
同じサーバーを使用できない場合は、事前接続またはDNS プリフェッチを使用して、より早く接続を開始することをお勧めします。通常、ブラウザは HTML のダウンロードが完了するまで待ってから接続を開始します。ただし、プリコネクトまたは DNS プリフェッチを使用すると、通常よりも早く開始されます。 DNS プリフェッチはプリコネクトよりも優れたサポートを備えていることに注意してください。
早期に取得したいリソースごとに、次のような新しいステートメントを追加します。
<link rel="preconnect" href="https://fonts.googleapis.com/">
<link rel="dns-prefetch" href="https://fonts.googleapis.com/" />
6. キャッシュを使用する
リソースをキャッシュすると、最初のページ ビューではダウンロードされますが、それ以降のページ ビューではダウンロードする必要はありません。すでに利用可能なリソースがあるため、追加のページの読み込みははるかに高速になります。
以下のウォーターフォール グラフで、2 ページ目の読み込みでダウンロードされるファイルの数がどれだけ少ないかを確認してください。
ページの最初のロード:
ページの 2 回目の読み込み:
可能であれば、CDN にもキャッシュしてください。キャッシュ時間は、快適な長さである必要があります。
理想的な設定は、非常に長期間キャッシュし、ページに変更を加えたときにキャッシュを消去することです。
7. その他
パフォーマンス向上に役立つテクノロジーが他にもいくつかあります。これらには、投機的プリレンダリング、署名交換、およびHTTP/3が含まれます。
参考文献
- Largest Contentful Paintを最適化する – web.dev
- Largest Contentful Paintの調査–Paul Irish (ビデオ)
- 最初から最後までページ速度を向上させる方法– Ahrefs
まとめ
目に見える負荷を測定するためのより良い指標はありますか?現時点では、新しいことは何も起こりそうにありません。私たちは負荷を測定しようとするいくつかの進化をすでに見てきました。
Load と DOMContentLoaded では、ユーザーに何が表示されるかはわかりません。 First Contentful Paint (FCP) は読み込みエクスペリエンスの始まりです。 First Meaning Paint (FMP) と Speed Index (SI) は複雑で、メイン コンテンツがいつロードされたかを実際には識別しません。
ご質問がございましたら、Twitter でメッセージをお送りください。
著者プロフィール
Patrick Stox は、Ahrefs のプロダクト アドバイザー、テクニカル SEO、およびブランド アンバサダーです。彼は、2021 年の Web 年鑑の SEO の章の筆頭著者であり、2022 年の SEO の章の査読者でもありました。また、Ahrefs の『初心者のための SEO 本』の共著者であり、『The Art of SEO 第 4 版』のテクニカル レビューの編集者でもありました。彼は、Raleigh SEO Meetup (米国で最も成功した SEO Meetup)、Beer and SEO Meetup、Raleigh SEO Conference などのいくつかのグループの主催者であり、Technical SEO Slack グループを運営し、レディット/r/TechSEO のモデレーターでもあります。
コメント