PageSpeed Insights や Search Console に出てくる LCP / INP / CLS は、読者が「待たされる・押しても反応しない・画面がガタつく」と感じる時間を、3つに分けた数字です。

LandingHub は、この3つ全部を魔法のように直すツールではありません。

効くところと、効かないところを先に知っておくと、導入後の期待がずれません。

3つの数字を、日本語で言うと

効く／効かない対応表

いちばん多い入れ方（タグ1行）を前提にしています。

LCP：最初の画面が出るまでの速さ

LP や通販ページでは、最初に目に入る大きな写真が LCP の主役になることが多いです。

LandingHub が得意なのは、まさにここです。

• 画像を軽くする
• 読者から近い場所から届ける
• 画面に映っているものを先に読み、まだ見えていないものは後回しにする

だから「見た目は同じなのに、最初の画面が速く出る」ことが起きます。

逆に、次のようなときは LCP があまり動きません。

• もともと画像が小さく、待ちの原因が別にある
• 最初の画面の主役が、画像ではなくプログラムで組み立てた部品
• 背景として指定した画像が主役なのに、普通の写真だけを速くしている

背景画像が最初の画面の主役のときは、設定の話になります。別の記事でまとめます。

INP：押したときの反応の速さ

INP は、カートに入れる・メニューを開く、といった 操作への返事 です。

原因の多くは、ページの中で動くプログラムが忙しいことです。

LandingHub のタグ1行は、そのプログラムを分割したり、書き直したりしません。

だから INP を直接よくするのが目的の製品ではありません。

ただし、重い画像のダウンロードが減ると、ブラウザに余裕が出ることがあります。

その結果、押したときの反応が少し良く見える、という間接効果はあり得ます。期待値としては「おまけ」です。

プログラムが重いことが分かっているページは、制作側の改修とセットで考える必要があります。

CLS：画面のガタつき

画像の幅と高さが書いていないと、あとから写真が割り込んで、ボタンが下にずれます。読者から見ると「押そうとしたら動いた」です。

LandingHub は、画像の実物の大きさが分かるとき、幅と高さを補うことがあります。

全部のガタつきをゼロにする機能ではありません。

広告や埋め込みが後から出てくるタイプのずれは、枠の大きさを先に決めるなど、ページ側の対応が必要です。

よくある質問

PageSpeed の点数は必ず上がる？

上がりやすいのは、最初の画面の画像が重いページです。プログラムが原因のページでは、点の伸びは小さくなります。

INP が悪いから LandingHub を入れれば直る？

主目的ではありません。画像待ちが減った結果、少し楽になることはあります。プログラム本体の重さは残りません。

CLS は画像を軽くすれば直る？

軽さとは別の話です。場所が先に決まっているかが本題です。軽くなっても、幅と高さが無いと同じようにガタつくことがあります。

まとめ

タグ1行の LandingHub が正面から効くのは LCP（最初の画面の画像・動画） です。INP は間接効果まで、CLS は画像の大きさの補完まで、が正直な線です。

「全部の数字が必ず緑になる」ではなく、「遅さの原因が画像なら、そこを先に潰せる」と考えてください。