LPが速いかどうかは、手元の端末での体感ではなく訪れた人の側で出ている数値で決まります。Googleが公開している基準では、最も大きい要素が表示されるまでの時間（LCP）が2.5秒以内、操作への反応（INP）が200ミリ秒以下、表示のずれ（CLS）が0.1以下で、いずれもページ読み込みの75パーセンタイルを見ます。
LPは広告の受け皿として作るため、1枚の中にファーストビューの大きな画像、動画、埋め込みフォーム、計測タグが集まります。遅くなる要素が1ページに集中しやすい作りだと考えると、どこを見るかの見当が付きます。
この記事では、数値の取り方、直す場所の決め方、LCPと表示のずれの直し方、直したあとの確認の順に整理します。LPの成果そのものを上げる手順はLPを改善する方法で扱っているため、ここでは速度の話だけに絞ります。
基準は3つ。見るのは75パーセンタイル
Core Web Vitals は3つの指標で構成されます。web.dev の説明では、それぞれの良好な水準と、判定に使う位置が次のように決められています。
| 指標 | 何を測るか | 良好とされる水準 |
|---|---|---|
| LCP（Largest Contentful Paint） | 読み込みを始めてから、最も大きい要素が表示されるまで | 2.5秒以内 |
| INP（Interaction to Next Paint） | 操作してから、次の描画が起きるまでの反応 | 200ミリ秒以下 |
| CLS（Cumulative Layout Shift） | 表示が勝手にずれた量 | 0.1以下 |
判定の位置は75パーセンタイルで、モバイルとデスクトップを分けて見ます。平均ではありません。PageSpeed Insights のドキュメントは、この位置を使う理由を「端末と回線の条件が厳しい側でも良い体験になるようにするため」と説明しています。言い換えると、速い端末での結果が良くても、遅い側の4分の1に入る訪問者の体験が基準を外れていれば合格になりません。
web.dev は、3つの指標すべてが75パーセンタイルで目標を満たしていれば、そのページを合格として扱うべきだとしています。1つだけ良い状態は合格ではありません。LPの場合、操作の少ないページでは INP が問題になりにくく、LCPと表示のずれのどちらかで外れていることが多くなります。どれで外れているかを先に確定させてください。ここを飛ばして画像の圧縮から始めると、原因が別のところにあったときに効果が出ません。
2種類の数値を混ぜない
PageSpeed Insights は1つの画面に2種類の数値を出します。この2つは役割が違うため、分けて扱います。
1つは実際に訪れた人の数値です。PageSpeed Insights のドキュメントによれば、直近28日の収集期間について実利用者の体験を報告し、すべての指標で75パーセンタイルの値を出します。もう1つは管理された条件で測った数値で、同じ条件を繰り返せるため不具合の切り分けに向きます。ただしドキュメントは、管理された条件での計測は現実の詰まりを捉えないことがあると明記しています。逆に実利用者の数値は実際の体験を捉えますが、そこから原因は分かりません。
手順にすると、実利用者の数値でどの指標が外れているかを決め、管理された条件での計測でどこを直すかの候補を集める、という使い分けになります（この順番は当社の整理です）。表示の点数だけを追いかけて、実際の訪問者の体験が変わらないまま終わるのは避けたい失敗です。
もう1つ、LP単体では実利用者の数値が出ないことがあります。訪問が少ないページは、集まったデータが足りず数値が表示されません。Search Console の Core Web Vitals レポートは、この問題に対して体験が似ているページをグループにまとめ、グループ単位で状態を示す作りになっています。状態は「良好」「改善が必要」「低速」の3段階で、データの元は CrUX レポートだと説明されています。
| 使う道具 | データの元 | 分かること |
|---|---|---|
| Search Console の Core Web Vitals レポート | CrUX レポート（実利用者のデータ） | サイト全体で、どのページ群が基準を外れているか |
| PageSpeed Insights | 実利用者のデータと、管理された条件での計測 | 1ページの合否と、直す候補 |
LCPは4つに分けて、時間を使っている場所を見つける
LCPが遅いと分かっても、「画像が重い」と決めつけると外します。web.dev の最適化ガイドは、LCPを4つの区間に分けて考える形を示しています。
4つの区間は、最初のバイトが届くまで（TTFB）、そこからLCPの素材を読み込み始めるまでの待ち、素材そのものの読み込み時間、読み込みが終わってからその要素が完全に表示されるまでの描画の待ちです。ガイドが目安として挙げている割合は、TTFBが約40%、読み込みの待ちが10%未満、素材の読み込みが約40%、描画の待ちが10%未満です。時間の大半は素材を実際に読み込んでいる状態であるべきで、待ちは小さく保つという考え方です。
この分け方が実務で効くのは、同じ「遅い」が別の作業に結び付くからです。読み込みの待ちが大きいなら、LCPになる画像の発見が遅れています。見つかるのがCSSやスクリプトの後になっている、という形です。素材の読み込み時間が大きいなら、その画像や動画そのものが重いことになります。TTFBが大きいなら、サーバー側や配信の設定の話であり、画像を軽くしても変わりません。どの区間が膨らんでいるかを見ないまま手を動かすと、関係のない箇所を直すことになります。
LPで最初に確認したいのは、ファーストビューの画像がLCPの要素になっているかです。広告からの訪問者が最初に見るのはこの1枚で、ここが表示されるまでページは実質的に空白のままです。
表示のずれは、場所を先に確保すれば防げる
CLSは、読み込みの途中で表示が動いた量です。LPは1枚で完結させる作りのため、画像、埋め込み、後から出る帯が同じ画面に同居しやすく、ずれが起きやすくなります。
ガイドが挙げている原因は5つです。寸法の指定がない画像や動画は、読み込まれた瞬間に場所を取り、下の内容を押し下げます。対応は、画像と動画に width と height を書くか、CSSの aspect-ratio で必要な場所を確保することです。最近のブラウザはこの属性から縦横比を計算するため、読み込みの前後で高さが変わらなくなります。
広告や埋め込み、遅れて届く内容は、最初のレイアウトで場所を取っておけば、ずれを避けられます。min-height や aspect-ratio で枠を決めるのが対応です。あわせて、遅れて届くものはビューポートの下のほうへ置くと、影響が小さくなります。後から差し込まれる帯やお知らせも同じで、仮の枠を見せておき、中身が届いたら入れ替えます。
残る2つは、配置をやり直させるアニメーションとWebフォントです。top や left を動かすと周りの要素の配置計算が起きます。transform を使えば周りを動かさず、ずれとしても数えられません。フォントは、代替フォントを決めておき、font-display の指定と重要なフォントの先読みで入れ替わりの影響を抑えます。
LPでは、読んでいる途中でボタンの位置が動くと、押そうとした場所が別の要素に変わります。ずれの対策は、数値のためだけでなく誤操作を防ぐためにも効きます。
検索順位への効果を、先に見積もらない
Google 検索セントラルは、Core Web Vitals がランキングのシステムで使われていると書いています。同時に、ページの体験が良くなくても最も関連性の高いコンテンツを示すという方針も書かれています。順位は速度だけで決まりません。
同じページは、サイト運営者が自己評価する項目として、Core Web Vitals、HTTPS、モバイルでの表示、広告の量と割り込みの度合い、全画面の割り込み、主要なコンテンツと補助的なコンテンツの区別の6つを挙げています。速度はこのうちの1つです。
LPの速度を直す理由は、順位の上昇を狙うためというより、広告費を払って連れてきた訪問者が、中身を見る前に離れるのを防ぐためです（この位置付けは当社の判断です）。検索順位への影響を根拠に投資を説明すると、効果が出たかどうかを後から確かめられません。
直したあとの確認は28日の窓で見る
直す作業が終わったら、実利用者の数値が動くのを待ちます。PageSpeed Insights が報告する実利用者の数値は直近28日の収集期間を対象にしているため、公開した翌日に数値が置き換わるわけではありません。Search Console のレポート側も、問題の修正を申告すると28日間のモニタリングが始まり、その期間で実際に問題が起きていないかを確認する作りになっています。
このため、確認の手順は次の形になります。管理された条件での計測で直したことを確かめ、実利用者の数値は28日の窓が入れ替わってから判定します。待っている間に別の変更を重ねると、どちらが効いたのか分からなくなります。LPの作り方でも触れているとおり、変更は1つずつ入れるのが結果的に速い進め方です。
この記事で確認できなかったこと
参照した一次情報の範囲で書けなかった項目を残します。
- 表示速度と成約率の関係を示す数値は、参照した6本には記載がありません。「◯秒速くすると成約率が◯%上がる」という形の値は、ここでは書けません
- TTFBの絶対値の目標も、ここで参照した最適化ガイドには書かれていません。示されているのはLCP全体に対する割合だけです
- 画像形式を変えたときの削減量、サーバーやCDNの設定ごとの効果も、参照した範囲には記載がありません
速度の数値は、訪問者の端末と回線の分布によって変わります。自社のLPで測った値が基準の内側にあるかどうかを、実利用者の数値で確かめるところから始めてください。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
LPを改善する方法｜数値の見方と直す順番を解説 ランディングページの改善手順を、計測の準備・切り分け・直す箇所の決定・検証という流れで解説します。どこで止まっているかの見分け方、優先度、変更を1つずつ行う理由までを実務目線で整理します。
LPの作り方｜企画から原稿・デザイン・公開・計測までの手順 ランディングページの作り方を、企画・原稿・デザイン・実装・公開前確認・計測という手順で解説します。広告との一貫性、書いてはいけない表現、公開後に見る数値までを実務目線で整理します。
ランディングページとは？LPの目的とホームページとの違いを解説 ランディングページ（LP）の意味と、ホームページとの違いを整理します。広告の評価に関わるランディングページの利便性、基本の構成、作る前に決めること、判断の基準までを実務目線で解説します。