LCP（Largest Contentful Paint）は、ページの最も大きなコンテンツが表示されるまでの時間を測定する重要な指標です。

このページではLCP改善の12施策をわかりやすく解説します。

LCPの仕組みや内容を把握したい方は「LCPとは」の記事をご覧ください。

LCPの表示速度の計測と要素を特定する方法

まずは、LCPを計測し現状を把握するところから始めましょう。

今回はChrome DevToolsでの計測方法を解説していきます。

①計測する回線の基準を決める

まずは正確な測定環境の基準を決めましょう。

ユーザーの実際の通信環境を反映した測定が重要で、闇雲に計測しても意味がありません。

まずGoogle Analyticsでモバイル・デスクトップの訪問比率を確認し、モバイルが60%以上なら4G環境を測定基準にすべきです。

PageSpeed Insightsはデフォルトで4G想定のため、実環境に近い結果が得られます。

Chrome DevToolsを使った計測前の設定方法

Chrome DevToolsでは、「ネットワーク」タブからスロットリングをかけます。

基本的におすすめは「低速4G」を選択し、実ユーザーの体感速度を再現するのがいいかと思います。

上記の画像の赤枠部分で設定ができます。

サイトの計測目的に合わせて選択してみてください。

※ここの設定で計測結果もかなり変わるため、サイトに合わせて基準をしっかり作っておくことをお勧めします。

②LCPの計測と特定方法

設定ができたら次はLCPを計測し現状を把握しましょう。

また、合わせてどのコンテンツがLCPの対象となるかも確認します。

確認方法として、まずは「DevTools＞パフォーマンスタブ」を開き、ページを再読み込みします。

上記画像の黄色枠の部分がLCPの読み込みにかかった時間が表示され、赤色枠の部分でLCPの対象となるファイルが確認できます。

赤枠部分をクリックすると、HTMLソースが出てきてどのファイルかと、HTLの箇所がわかります。

③ネットワークで読み込みの状況を確認・表示する

「DevTools＞ネットワークタブ」を開き、ページを再読み込みします。

すると下記のように各ファイルの読み込まれた状況が把握できます。

上記のようにネットワークで読み込み状況を表示させます。

どの項目がLCPになるのかもここで確認しておきましょう。

基本的には、LCPの横棒（緑から青までのライン）ができるだけ左側で終わっていれば早く読み込めているということになります。

LCPの読み込みが遅い要因を調査する方法

次にLCP自体の読み込みにかかってる要素を特定します。

LCPの読み込みには、ファイル自体の容量（重いと時間がかかる）、サーバーの帯域と回線の問題が考えられます。

実際、ファイル自体に改善余地があるのか、サーバー側の問題なのかを判断するために、下記の手順で計測を行ってみましょう。

①ダウンロード速度が遅すぎないかを確認する

ここでは、サーバーの帯域のスペックがどうかをチェックするための方法です。

手順としては、LCPに該当する画像URLのみをChrome DevToolsのネットワークで読み込みます。

（LCPでなくてもページにある大きめの画像を選択する形でもOKです）

ネットワーク＞スロットリングなし（ネット回線などの影響を受けずサーバー能力がフルに発揮されている）の状態で、画像を読み込み直します。

ここでチェックしてほしいのが、サイズとウォーターフォールのコンテンツダウンロードの秒数です。（画像の黄色枠の部分）

上記の画像の場合、1,157KBのサイズの画像が34.81ms（秒に直すと0.034秒）で読み込まれたことになります。

この数値を確認できたら、下記の式に当てはめて計算してみてください。

画像サイズ÷コンテンツダウンロード時間（秒に合わせる）×8÷1024＝（読み込み速度Mbps）

※式の×8はKbpsの単位に合わせるための数値で÷1024はMbpsの単位に合わせるための計算。

目安として、これで出てくる読み込み速度が100Mbps以上であれば特に気にしなくていいですが、100Mbpsを下回る場合はサーバーなどの改善を検討しましょう。

上記の画像の例を参考に計算すると下記となります。

1,157KB÷0.034s×8÷1024=265Mbps

この場合は265Mbpsなのでサーバーは問題ないと判断して良いとなります。

ここの数値が下回る場合はページ下部の

LCP改善手順④：サーバーの読み込みが遅い場合の改善策

で改善方法を確認してみてください。

問題なければ下記の②のチェックへ進みましょう。

②サーバーの応答時間をチェックする

サーバーの応答時間もチェックを進めましょう。

サーバー応答時間のチェックの方法として、まずはLCPの画像をChrome DevToolsの「ネットワーク」にかけて確認します。

ここもサーバーの応答の確認なので、「スロットリングなし」でチェックします。

ウォーターフォールの「サーバーの応答を待機しています」の緑バーの数値を見ます。

上記画像の場合は約38msということがわかります。

TTFB自体はかなり速い速度となりますが、目安としてgoogleは200ms（0.2秒）以内を目指すことを理想としています。

これを超えてくる場合は、改善の余地があると判断できます。

また、LCP画像のチェックと合わせて、ドキュメントのサーバー応答速度も合わせて確認します。

ドキュメントのサーバー応答速度のチェック方法として、対象のURLをスロットリングなしで読み込みます。

上記の画像の場合、LCP画像が38msで読み込めたのに対し、ドキュメントは約285msで読み込めたことになります。

ここでLCP画像と同じほどの読み込み速度だった場合は特に問題はありません（シンプルなドキュメントで読み込みが速い状態です）が、上記のようにドキュメントの方の読み込みが遅い場合、phpやデータベースなどの取得に時間がかかっていることを意味します。

この場合は、読み込みに時間のかかっているファイルを改善できれば更に速くなります。

ここに問題がある場合は、ページ下部の

LCP改善手順④：サーバーの読み込みが遅い場合の改善策の「サーバーアプリケーションに問題ないかを確認する」の見出しにいって改善しましょう。

参考記事：TTFB（サーバーの応答速度）

③LCPのコンテンツ容量が重くないかを確認する

同じくネットワークのLCPの項目をまずは確認し、タイプの列とサイズの列を確認します。

上記の画像の場合、LCPの画像ファイルはjpegの拡張子で1156KBということがわかります。

次世代フォーマットの拡張子に変更したり、サイズを圧縮することでかなりの改善が見込めます。

サイトの目的によっても変わりますが、最大限速度重視で考えた場合、画像であれば10〜30KB程度まではサイズを減らすことはできます。

100KB以上あるLCP画像で更に改善をしたい場合は

「LCP改善手順②：画像サイズを縮小する」の見出しへ進み、改善方法を確認しましょう。

LCP改善という意味では、LCPをチェックしますが、サイト全体の表示速度を上げるという意味では他の画像のサイズもチェックしておくといいでしょう。

④LCPの読み込みが阻害されているかを確認する

ここでは、LCP画像単体で読み込んだ場合の秒数とページ全体で読み込んだ場合の秒数を比較して、どのくらい他の要素に阻害されているかを確認します。

まずは、下記の手順でページ全体を読み込みます。

「ページ全体を開く＞ネットワーク＞低速4G」にして度読み込みします。

確認方法としては、「時間」の列か、ウォーターフォールの中を確認してみましょう。（赤枠部分）

この場合、画像の読み込みにかかった時間は約21.8秒程度となります。

次に下記の手順でLCP画像単体を読み込みます。

「LCP画像URLを開く＞ネットワーク＞低速4G」にして度読み込みします。

この場合、画像の読み込みにかかった時間は6.99秒となります。

これらを比較すると、ページ読み込みの場合は画像単体の読み込みの時と比べて大体３倍ほど読み込みに時間がかかってることがわかります。

要はLCPの画像以外の読み込みに2/3程度のリソースを割かれていることになります。

LCP画像の読み込みを阻害している対象となるリソースの判断方法としては、LCPの読み込み開始から読み込み終了までに含まれるリソースは全て対象となります。

上記の画像で解説するとLCP読み込み開始のライン（オレンジ）からLCP読み込み終了のライン（緑）

の間に含まれる読み込みは全て対象（薄ピンクの部分）となります。

赤枠の部分でファイル名が確認できます。

このLCP以外の読み込みリソースを遅らせるか、削減するかでLCPの読み込みは格段に速くなります。

ここの具体的な改善策については「LCP改善手順③：LCP読み込みを阻害するリソースの最適化」の見出しで紹介しています。

LCP改善手順①：プリロード（preload）の活用

LCP改善策の1つ目として、LCPがどこから読み込み開始しているかをチェックしてみてください。

プリロード（preload）を使う場合と使わなくても大丈夫かをここで判断します。

下記の画像を参考に解説すると、赤枠の部分から始められていれば、プリロード（preload）をうまく活用できている状況なので問題ありません。

参考記事：rel=preloadとは

仮に赤枠よりも右側からLCPが読み込まれている場合（headを読み込んだ後に読み込まれている場合）は、プリロード（preload）を設置しましょう。

ちなみに、サイトの読み込みを段階的に分けると下記のように分けられます。

• ページのリクエスト開始からダウンロード完了までの時間
• <head>内のリソースの読み込み時間
• <body>内のリソースの読み込み時間

ページは上記の順番で読み込みされていくのですがhead読み込みからLCPを読み込ませることで表示までの時間を短縮でき、LCPが改善される仕組みとなります。

プリロード（preload）の設置方法

プリロード（preload）は、head内にHTML5の<link rel="preload">を使用して実装します。

下記のソース例では、headに<link rel="preload">で画像を指定した例です。

<head>
  <!-- WebP画像をプリロード -->
  <link rel="preload" 
        as="image" 
        href="/images/hero.webp" 
        type="image/webp"
        fetchpriority="high">
  
  <!-- フォールバック用JPEG（WebP非対応ブラウザ用） -->
  <link rel="preload" 
        as="image" 
        href="/images/hero.jpg"
        fetchpriority="high">
</head>

<body>
  <picture>
    <source type="image/webp" srcset="/images/hero.webp">
    <img src="/images/hero.jpg" 
         alt="ヒーロー画像" 
         width="1200" 
         height="600"
         fetchpriority="high">
  </picture>
</body>

上記のソースを参考に設置してみてください。

LCP改善手順②：画像サイズを縮小する

コンテンツが要因で読み込みが遅い場合、下記のようなポイントをチェック＆改善していきましょう。

今回はLCPが画像の例で解説していきます。

①LCP画像の大きさを小さくする

一番初めに画像の大きさを小さくするのがおすすめです。（一番圧縮できるため）

具体的な方法を紹介していきます。

下記はmacの場合ですが、対象のLCP画像をPCのローカルで画像サイズを計測しておきます。

今回の画像の場合、サイズは1155KB（KBに直してます）で、大きさは2000×1333という画像です。

まずは、画像を開き「ツール＞サイズを調整」のところで幅や高さのサイズ変更が可能です。

サイズ変更のポイントとして、下記は押さえておきましょう。

• 画像サイズは横幅412pxほどを目安にする（スマホ）
• 高画質を維持したい場合は横幅1,179pxを目安にする（スマホ）
• PC用の画像はコンテナーのサイズに合わせた画像サイズにする
• サイズの解像度は72基準にする

それぞれの理由は下記で解説します。

画像サイズを412pxにする意図としてはPageSpeed Insightsが基準としているサイズ（MotoGのサイズ）が412pxだからという理由です。

ただ、最近ではiphone14以降などのスマホ端末だと高解像度の端末もあるため、高画質を維持したい場合は1,179pxを目安にしましょう。

画像によって綺麗に見える画像、そうでない画像があります。

迷った場合は実際端末で目視して綺麗に見えるサイズに合わせることをお勧めします。

また、サイズの解像度についてはウェブであれば72にしておけば十分綺麗に表示されます。

それ以上にすると逆に画像サイズが大きくなってしまう原因になります。

また、上記で解説している通り、PC用とスマホ用の画像サイズをそれぞれ用意しておきましょう。

（最終的にレスポンシブで表示させることでLCPも更に良くなります）

先ほどの画像を412pxに変更して保存します。

サイズ変更後のサイズを比較してみると下記のようになりました。

1155KB（KBに直してます）だった画像サイズが66KB（KBに直してます）約17分の1まで小さくなりました。

②LCP画像を圧縮する

サイズ縮小の次に実施したい内容が画像の圧縮です。

先ほど66KBまで小さくした画像の圧縮で解説していきます。

今回はTinyPngのサービスを使って画像を圧縮します。

こちらのサイトに画像をアップし、ダウンロードするだけで簡単に圧縮ができます。

圧縮した結果は下記の通り。

圧縮前の画像が約66KBだったのに対し、約48KB（約30％の圧縮）まで圧縮できました。

③次世代フォーマット画像を使用する

画像の拡張子がgifやjpg、pngとなっている場合は、AVIFやwebpなどの次世代フォーマット画像に変換することで画像サイズを小さくできます。

おすすめはfreeconvertが細かいパラメータも調整できておすすめです。

画像をアップした後に変換したい拡張子を選択して、歯車マークを押します。

下記のようにオプションで調整も可能です。

今回は、先ほど48KBまで圧縮したJPEGの画像を次世代フォーマット画像のwebpの拡張子に変換してみます。

画質72、圧縮速度6にして変換してみました。

約48KBだったJPEG画像が、約18KBのwebp画像に変換されました。

半分以下のサイズまで小さくできた形になります。

参考記事：次世代フォーマットとは

LCP改善手順③：LCP読み込みを阻害するリソースの最適化

LCPと同時に読み込まれているリソースがあると、LCP自体の読み込みもその分遅くなります。

ここではLCPと同時に読み込まれているリソースを最適化して改善する方法をお伝えします。

大きな改善ポイントをまとめると下記の3つを意識して進めましょう。

• いらないファイルは削除する
• 読み込みの遅延を検討する
• ファイルを圧縮する

上記でも解説しましたが、LCP画像の読み込みを阻害している対象となるリソースの判断方法としては、LCPの読み込み開始から読み込み終了までに含まれるリソースは全て対象となります。

上記の画像で解説するとLCP読み込み開始のライン（オレンジ）からLCP読み込み終了のライン（緑）

の間に含まれる読み込みは全て対象（薄ピンクの部分）となります。

赤枠の部分でファイル名が確認できます。

参考記事：レンダリングブロックとは

①使用してないファイルは削除する

一番効果を発揮できる方法として、不要なファイルを削除することが効果的です。

いらないファイルは極力削除していきましょう。

CSS、Javascript、画像、フォントファイルなど全てのファイルが対象となります。

確認方法として、ネットワークで読み込まれているファイル名を確認します。

実際に制作した方と確認しながら、使用していないのに読み込みが発生しているファイルがあれば削除していきましょう。

理想はサイトを作成できる時から、無駄な読み込みが起きないよう設計していけるのが理想的です。

また、ファイルごと消せなくても、ファイルの中身で使用されていないソースを削っていくことでも読み込みは速くなります。

下記の画像のように「ファイル名＞プレビュー」でファイルの中身までチェックしていき、いらないソースをカットしていくと良いでしょう。

ここまで来るとかなり根気のいる作業になりますが、1つ1つチェックして軽量化していきましょう。

②GTMの中身までチェックする

マーケターにとってGTMはとても便利なツールですが、しっかり整理ができていないとこれも読み込みを遅くする原因にもなります。

まずはgtmタグが入っているかどうかを確認します。

入っている場合はネットワークで検索枠に「gtm」と入れればgtm.jsというファイルが出てきます。

gtm自体はマーケティングをしている以上、入っていても問題ありませんが問題は中身です。

gtmの管理画面内で実際に使用しているタグかどうかを確認します。

使用していないタグなのにONになっているものは下記のようにOFFにしておくか、タグごと削除しておきましょう。

読み込みの量が格段に減ります。

特に多いのが、代理店や外部企業ごとにGTMを分けるような管理をしているケースで、複数のGTMをサイトに貼っているケースなどがあります。

計測タグが無駄に重複していたり、管理できていないで使用していないタグだけどONになりっぱなしになっている場合は削除できる対象となります。

整理できたあとは、ウォーターフォールのコンテンツのダウンロードの時間が短くなっているかをチェックしましょう。

③ファーストビュー以外の画像は遅延読み込み

ファーストビュー以外の画像要素（LCP画像以外）の画像の遅延読み込みに「loading=”lazy”」を利用します。

下記のようにLCP画像などファーストビューの画像はそのまま読み込み、ページ下部にある画像は遅延読み込みさせるようにします。

これらの設置でファーストビュー以外の画像の読み込みを後回しにすることができるため、ファーストビュー要素の読み込みが格段と早くなり、LCPの数値も改善されます。

設置は、簡単で遅延読み込みさせたい画像要素に「loading=”lazy”」を挿入するだけです。

通常のイメージ画像は下記のようなソースになります。

画像の遅延読み込みができている場合は、下記のようなソースとなります。

ソースに「loading=”lazy”」を入れたら実際に遅延読み込みができているかを確認しましょう。

下記の動画を参考に確認してみてください。

1. DevToolsのネットワークでページを読み込みます（ファーストビューにしておく）
2. 一通り読み込み終わったらネットワークで読み込んだ項目を下の方までスクロールしておきます。
3. 実際のページをスクロールしていく
4. スクロールしていく過程で、右側のネットワークの項目が追加で読み込まれているか確認
5. 追加で読み込まれた項目の中にページ下部（ファーストビュー以外）の画像が追加で読み込まれているか確認

スクロールしていく過程で、ページ下部の画像が後から読み込まれていることが確認できれば遅延読み込みはうまく動いていることになります。

ポイント

ブラウザによって何px下まで読むかなどが変わります。

基本的に表示されている部分より少し下までは一緒に読み込まれることがほとんどです。

その点、landinghabの機能ではスクロールするまで読み込まない（上にスクロールしても下にスクロールしても同様）などの機能があります。

通常の遅延読み込みよりも効率的に読み込みできる特許機能もついています。

landinghabの利用も是非検討してみてください。

参考記事：Lazy Loadとは？

レスポンシブ画像にもloading=”lazy”を使いましょう

また、レスポンシブ画像にも「loading=”lazy”」を挿入するだけで対応が可能です。

レスポンシブ画像（srcset要素）の例

<!-- レスポンシブ + 遅延読み込み -->
<img loading="lazy"
     src="hero-small.jpg"
     srcset="hero-small.jpg 300w, 
             hero-medium.jpg 600w, 
             hero-large.jpg 1200w"
     sizes="(max-width: 600px) 300px, 
            (max-width: 1200px) 600px, 
            1200px"
     alt="レスポンシブ画像">

レスポンシブ画像（picture要素）の例

<picture>
    <source media="(max-width: 600px)" 
            srcset="mobile-image.webp">
    <source media="(max-width: 1200px)" 
            srcset="tablet-image.webp">
    <img src="desktop-image.webp" 
         loading="lazy" 
         alt="ピクチャー要素">
</picture>

画像要素の遅延読み込みのポイント

• LCP要素にはloading="lazy"を使わない
• スクロールしないと見えない画像にだけloading="lazy"を使用する
• レスポンシブ画像にもloading="lazy"を追加するだけで対応可能
• LCP要素にはfetchpriority=”high”やloading=”eager”を活用するといい

④内部CSSで読み込ませて後から読み込ませる

ファーストビュー部分のCSSに関しては、内部CSSに読み込みさせます。

それ以外の部分のCSSは後から遅延読み込みをさせることでレンダリングブロックを防ぎ表示速度の改善に繋がります。

基本的にはクリティカルCSSのツールを使って進めます。

今回はこちらのクリティカルCSSツールを使って解説します。

URLの箇所には改善したいページのURLを入れます。

横幅(width)と、縦幅(height)に関しては、スマホのページを最適化したい場合はスマホサイズ。

PCのページを最適化したい場合はPCサイズに合わせます。

ここではスマホサイズ（motogのサイズに合わせ412×823）での例です。

Render Wait Time (ms)は少し余裕もって時間を設定しておきましょう。

（読み込みが遅いページだと必要なCSSを読みきれないケースも出てきてしまうためです）

上記は5000ms（5秒）ですが、読み込みが遅いサイトなどは余裕を持って10000ms（10秒）程度にしてみましょう。

この内容で作成すると下記のようにCSSが出てきます。

ここで出てきたCSSをheadに入れればOKです。

ここまではファーストビューに必要なCSSをheadに読み込ませるまでの作業となります。

残りのCSSファイルはbody内においてから遅延読み込みをさせる形がおすすめです。

headにそのままファイルを入れてしまうと結局レンダリングブロックになってしまうためです。

bodyに移したCSSファイルはjavascriptで遅延読み込みさせる形になるので、エンジニアの方と一緒に進めると良いでしょう。

ポイント

• 分割したCSSファイルはbodyに設置
• javascriptで遅延読み込みさせる
• CSSは必要なDOMの前に入れる

上級者向け

可能であればCSSは分割を行って、表示が必要な箇所に必要な分のCSSを入れるようにするのがおすすめ。

表示させたいコンテンツの手前に必要な分のCSSファイルを作成し、DOMの手前で読み込ませる。

少し手の込んだ上級者向けの方法ですが、細かく設定することでかなり最適化ができます。

参考記事：CSS高速化

⑤JavaScriptが必要なDOMの直後に置く

javascriptについては1つのファイルでまとめてしまうのではなく、必要に合わせてファイルを分割し必要なDOMの直後に置くようにします。

特にカルーセル、スライダー、アコーディオンなどのコンテンツごとにjavascriptを分けて、最適なタイミングで読み込ませるようにします。

javascriptが重いとレンダリングブロックの大きな要因になるので、効果も高いです。

細かい設定が難しい・・・という方は、優先度の低いjavascriptをbodyの一番下に移動させるだけでも効果はあります。

ポイント

• javascriptファイルは分割して、必要な箇所の分に分けるのがおすすめ
• javascriptが必要なコンテンツのDOM直後に置く
• 見た目など崩れてしまう場合は、分割させすぎずに必要なjavascriptは読ませるようにしましょう

参考記事：JavaScriptの速度改善方法

⑥CSS・JavaScriptファイルを圧縮する

CSSやJavaScriptファイルを圧縮することで、読み込みが早くなり読み込み速度を早くすることができます。

方法としては、ページ上で使用されているCSSやjavascriptファイルをミニファイ（圧縮）させます。

まずはページ上で使用されているCSSやjavascriptファイルの特定方法です。

こちらもDevToolsを活用してチェックします。

対象となるのはLCPと同時に読み込んでいるファイルは全て対象となります。（下記画像の赤枠部分）

このファイルの中で「.min.js」や「.min.css」となっているファイルはミニファイ（圧縮）できているファイルなので、それ以外の「.js」「.css」ファイルは圧縮対象となります。

圧縮方法としてはミニファイするためのツールを使用します。

今回はMinifier.orgを活用した方法でご紹介します。

圧縮したいCSSやjavascriptファイル、またはURLを貼り付けて読み込ませた後に、minifyのボタンを押すだけで下記の画像のように圧縮されます。

圧縮できたファイルをダウンロードし、既存のファイルと差し替えましょう。

⑦フォントはサブセット化とフォーマットの最適化

まずはDevToolsを活用してフォントファイルを確認します。

タイプの行で「font」となっているファイルを探しましょう。

まず確認するポイントとして、フォントファイルが使用されているファイルかどうかを確認します。

いらないフォントファイルがあれば削除することが最優先事項です。

また、フォントの見た目にそこまでこだわりがなく表示速度を重視したい場合は、ウェブフォントではなくシステムフォントを使うことをお勧めします。

フォントのサブセット化とフォーマットを変更する方法

サブセット化できるフォントファイルはサブセット化を行いましょう。

サブセット化でファイル容量を減らすことができます。

今回はTransfonterというツールでサブセット化を行う方法をご紹介します。

まずはフォントファイルをアップし、下記のようにサブセット化したい文字の設定をします。

「Characters」の部分には実際に使用する必要な文字を全て入力してください。

使用度合いに応じて対応しましょう。

また「formats」に関してはWOFF2のフォーマットが推奨です。

入力ができたら「コンバート」ボタンを押してファイルをダウンロードします。

最後にダウンロードしたファイルをサイトに実装しましょう。

サブセット化に関しては、サイト内で使用される文字が更新されるようなページには向いていないため注意してください。

サイトロゴなど固定されているような文字には最適な方法となります。

フォントの読み込みは最後にするのがおすすめ

通常ウェブフォントはheadなどで読み込ませることが普通ですが、javascriptで制御して意図的に読み込みタイミングを遅らせるとレンダリングブロックにならないためお勧めです。

javascriptでの制御に関しては技術的な部分も必要となってくるため、必ずエンジニアの方を交えて施策を行っていきましょう。

LCP改善手順④：サーバーの読み込みが遅い場合の改善策

サーバーの読み込みが遅い場合、TTFB（サーバーの応答速度）の数値を改善する方法を考えていきます。

下記のポイントを抑えて改善してみましょう。

サーバーアプリケーションに問題ないかを確認する

サーバーアプリケーションは、javascript、apache、nginxなどで作られたアプリケーションのことを指します。

馴染みのあるものでいうとwordpressなどのCMSやテーマ、プラグインなどもこれに当たります。

下記の図のように「ウェブサーバー→アプリケーションサーバー→データベースサーバー」といった流れで読み込まれていきます。

確認方法として、上記の図でどこが悪いかの工程をチェックしていきましょう。

チェック項目①アプリケーション

例えばここではwordpressを例にして説明します。

wordpressの場合であれば、下記のポイントをチェックしてみましょう。

• 軽いと言われているテーマに変更して比較してみる。
• プラグインを停止して比較してみる。

変更前にDevToolsで計測しておき、変更後の速度と比較して確認を行います。

チェック方法としては、LCP画像1つをスロットリングなしで読み込み、サーバーの応答を待機していますの時間を確認してみてください。（上記画像の赤枠部分）

目安として30ms〜40ms以下を目標に頑張ってみましょう。

wordpress以外であれば、アプリケーションを作ったエンジニアと相談して重くなる要素などを考慮して改善点を考えてみましょう。

チェック項目②DB（データベース）

まずは使用しているデータベースサーバーのコントロールパネルを確認し下記の項目をチェックしてみてください。

• CPU使用率
• メモリ使用量
• ネットワーク帯域
• ストレージスループット

これらが頭打ちになっていないかを確認しましょう。

サイトの内容によって最善の方法は変わりますが、データベースサーバーが分かれているかどうかや、データの取得方法などエンジニアの方と確認してみるといいでしょう。

他にもDBの同時接続数などの設定がある場合はそこの確認もしてみましょう。

契約サーバーの地域を確認する

サーバーはユーザーがアクセスする場所から距離が遠いと物理的に通信にも時間がかかります。

そのため、サービスを展開する国やエリアにあるサーバーを選ぶというのも重要なポイントです。

サーバー選定の方法について

各サーバープランの内容をまずは確認します。

チェックポイントとしては下記となります。

• 国内にデータセンターがあるか
• 国内で複数箇所のデータセンターがあるか（北海道、東京、大阪、福岡など）

サービス内容にどこのエリアにサーバーが設置されているかなどを確認しておくことをお勧めします。

複数のデータセンターがあって、かつCDNサービスがあるサーバーであればアクセスしたユーザーに近いサーバーに接続されるため、表示速度の早さにも影響します。

既存サーバーを確認する場合

ご自身が運用されているサイトのドメインをCMANなどのドメインIPチェックのツールにかけます。

下記の画像のように「入力の逆引き」のところに出てくるIPアドレスを確認します。

このIPアドレスをhttps://check-host.net/などのサービスで検索をかけます。

ここに出てきたエリアがサーバーのエリアになります。

※CDNを使用している場合は、各サーバーのエリアが表示される場合があります。

スペックの高いサーバーへの変更を検討する

エリアを確認したあとは、利用しているサーバーのスペックも確認しましょう。

下記のような状況になっている場合はスペック変更を検討しましょう。

※できれば、ここの工程は最後に検討しましょう。

サーバー混雑してないかを確認する

チェックするポイントとして下記の項目を確認します。

・CPU

・ネットワーク

・ストレージ

・メモリ

が混雑していないか？をチェックします。

確認する場合はサーバーダッシュボードみて確認する。

これらが混雑していると処理がうまくできないので、最後の手段としてスペックの見直しを検討してみてください。

サイトの状況やサイトの用途によって、どのくらいのスペックを使うか、エンジニアと相談しながら決定してみてください。

参考記事：サーバーの速度改善方法

LCP改善手順⑤：レスポンシブ画像の実装

レスポンシブ画像は、デバイスの画面サイズや解像度に応じて最適なサイズの画像を自動配信する技術です。

画像を使用しているサイトであれば、レスポンシブ画像は導入するようにしましょう。

基本的にはsrcset属性とsizes属性を使用して下記のような記述で作成します。

srcset属性とsizes属性の使用例

<img 
  srcset="
    image-small.jpg 600w,
    image-medium.jpg 1200w,
    image-large.jpg 1920w
  "
  sizes="
    (max-width: 600px) 100vw,
    (max-width: 1200px) 50vw,
    33vw
  "
  alt="レスポンシブ画像"
>

特にポイントとしては、下記のポイントを意識して設定しましょう。

• どのくらいのサイズに分ければいいか
• それぞれのサイズは何ピクセルにするか

サイトによって最適な形は変わりますが、下記を目安としておくといいでしょう。

各ブレークポイントで必要な画像サイズ

参考記事：レスポンシブ画像

LCP改善手順⑥：キャッシュの活用

キャッシュも色々なキャッシュがありますが、下記のキャッシュは抑えておきましょう

ブラウザキャッシュ

ブラウザキャッシュはユーザーが閲覧しているブラウザのキャッシュのことを指します。

これは、ユーザーのブラウザの設定に依存する部分が大きく、最終的な制御はユーザーにしかできません。

ただ、サイト管理者側ではブラウザキャッシュの時間の設定は可能なので、サイトの目的や用途に合わせてキャッシュ時間の設定をすることをお勧めします。

※LCPの数値には直接関係はない要素となります。

CDNキャッシュ（エッジキャッシュ）

CDNは世界中のサーバーを利用し、サイトにアクセスした場所から近いエリアのサーバーからコンテンツを配信することで、サーバーの応答速度を向上できるサービスです。

このCDNキャッシュ（エッジキャッシュ）を活用する方法もあります。

活用する場合は、CDNは主に下記のようなサービスがありますので、導入するところから始めましょう。

• Cloudflare（無料プランから始められておすすめ）
• AWS CloudFront（AWS利用者から人気）
• さくらのCDN（日本のサービス）

CDNキャッシュは下記のような設定ができるので、サービスの管理画面で設定します。

• キャッシュ対象の設定（ファイルの種類など）
• キャッシュ時間の設定
• どこの階層にキャッシュを作るかの設定（階層式キャッシュ）

サイトによって最適な設定内容は変わりますので、サイト運営者とエンジニアの方で相談しながら決めていくといいでしょう。

参考記事：CDNとは

サーバーキャッシュ

サーバーキャッシュは、一度読み込んだファイルをサーバーが保存して、次回アクセス時に瞬時に表示させます。

キャッシュできるものの種類としては、メモリやディスクなど様々な種類があります。

こちらもサイトの運用方針によって設定方法は様々あります。

主には下記の項目が設定可能です。

• キャッシュ対象の設定
• キャッシュ時間の設定

運営者とエンジニアで相談しながら、最適な設定方法を考えてみてください。

LCP改善手順⑦：サーバー側の圧縮（Gzip/Brotli）

サーバー側の圧縮（Gzip/Brotli） は、HTML、CSS、JavaScriptなどのテキストベースのファイルを圧縮してから配信する技術です。

適切に設定することで、ファイルサイズを50〜80%削減し、LCPを0.2〜0.6秒改善できる基本的ながら非常に効果的な施策です。

Webページを表示するには、HTML、CSS、JavaScriptなど多数のテキストファイルをダウンロードする必要があります。

圧縮なしでは、レンダリングブロックリソース（CSS/JS）のダウンロードに余計な時間がかかり、LCPが大幅に遅延します。

ファイルタイプ別の圧縮効果例

Brotliは全てのテキスト形式で3〜6%追加削減を実現します。

実装方法例

下記の例を参考に実際に実装してみましょう。

Brotli有効化（推奨）

# .htaccess または httpd.conf

# Brotliモジュールの有効化
<IfModule mod_brotli.c>
    # Brotli圧縮を有効化
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript
    AddOutputFilterByType BROTLI_COMPRESS application/javascript application/x-javascript
    AddOutputFilterByType BROTLI_COMPRESS application/json application/xml application/rss+xml
    AddOutputFilterByType BROTLI_COMPRESS image/svg+xml
    
    # 圧縮品質レベル（0-11、推奨: 5）
    BrotliCompressionQuality 5
    
    # 圧縮対象の最小ファイルサイズ（バイト）
    BrotliFilterNote Input instream
    BrotliFilterNote Output outstream
    BrotliFilterNote Ratio ratio
    
    # 最小1KB以上のファイルを圧縮
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp|avif)$ no-brotli
</IfModule>

# Brotli非対応ブラウザ用のGzipフォールバック
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
    AddOutputFilterByType DEFLATE application/javascript application/x-javascript
    AddOutputFilterByType DEFLATE application/json application/xml application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml
    
    # 圧縮品質レベル（1-9、推奨: 6）
    DeflateCompressionLevel 6
</IfModule>

# すでに圧縮済みのファイルは除外
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp|avif|mp4|webm|zip|gz|bz2)$ no-gzip no-brotli

# 古いブラウザ対応
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Gzip有効化（基本）

# .htaccess

<IfModule mod_deflate.c>
    # Gzip圧縮を有効化
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/atom_xml
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE font/ttf
    AddOutputFilterByType DEFLATE font/otf
    AddOutputFilterByType DEFLATE font/woff
    AddOutputFilterByType DEFLATE font/woff2
    
    # 圧縮レベル設定（6推奨）
    DeflateCompressionLevel 6
    
    # 古いブラウザ対応
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    
    # プロキシサーバー対応
    Header append Vary User-Agent
</IfModule>

LCPの改善をするためのポイントやコツ

ポイント１：最も大きなコンテンツ要素が何かを把握する

LCPを改善するには、まず「何が最も大きなコンテンツなのか」を正確に把握することが重要です。

闇雲に最適化するより、ターゲットを絞った方が効果的だからです。

最も大きなコンテンツ要素を把握する方法

要素を探す方法はLighthouseとPageSpeed Insightsを使う方法の2つがあります。

Lighthouseで確認する方法（おすすめ）

Lighthouseで確認する手順は下記の通りとなります。

使用する手順

1. 改善したいページをChromeで開く
2. 右クリック→「検証」を押してデベロッパーツールを開く
3. 「パフォーマンス」タブをクリック
4. 「LCP要素」と表示された部分を確認

上記手順の１〜２の改善ページをChromeで開いた後に右クリックで検証を押し、デベロッパーツールを開きます。

デベロッパーツールを開いた後に、手順３のパフォーマンスタブをクリックします。（下記画像を参照）

手順４の「LCP要素」と表示された部分がLCP要素であることがわかります。

PageSpeed Insightsで確認する方法

PageSpeed Insightsで確認する手順は下記の通りとなります。

使用する手順

1. PageSpeed Insightsにアクセス
2. URLを入力して「分析」をクリック
3. パフォーマンスの「最大コンテンツの描画」セクションで詳細を確認
4. 「対象要素を表示」で実際の要素で確認

ただし、PageSpeed Insightsの場合、ページによっては要素が出てこない場合があります。

その場合はLighthouseを活用してみてください。

ポイント２：ファーストビューに無駄に重いコンテンツをおかない

LCPは表示されている画面内の最も大きいコンテンツが対象となります。

そのため、最も大きいコンテンツの対象が読み込みが重いもコンテンツにならないようにするということもポイントです。

それ以外にも、表示される画面内の要素に無駄に重いコンテンツを置かないということも大事です。

LCP対象のコンテンツの読み込みがスムーズになるので最善のパフォーマンスが出せるよう工夫してみましょう。

ポイント３：要素を把握しコントロールする

これは一つのテクニックではありますが、LCP対象となる最も大きいコンテンツの要素を読み込みが速いもの、軽いものに指定されるようにサイズを調整するというテクニックです。

もちろん、コンテンツが調整できる、できないはサイトによって変わりますが要素をコントロールすることで改善の余地も見えてきます。

LCPの改善方法まとめ

LCPの具体的な改善方法について紹介してきました。

これらを実践して、LCPの数値改善を実施してみてください。

特に大事なポイントとして、まずは大きい要因を解決させるところから始めることを優先しましょう。

1つ改善ができると、次の課題が出てくるような流れがほとんどです。

改善は一度だけじゃなく、何度かに分けて実施することをお勧めします。

また、landinghubはタグ1つの導入でLCP改善に貢献してくれるツールです。

技術的な部分での設定が難しい場合でも、landinghubの導入で数値改善も可能です。

landinghubの導入も是非ご検討ください。