表示速度は本当にCVRに効くのか — 測り方と、直す順番

速度はCVRの上限を決めますが、CVRそのものはつくりません

表示速度が問題になるのは、多くの場合コンバージョンの手前ではなく、その前段の離脱です。ページが表示される前に離脱されれば、そこにどれだけ優れた提案が書かれていても読まれません。とくに広告から流入するLPや、モバイル回線でアクセスされるページでは、最初の数秒の差がそのまま到達率の差になります。

一方で、速さ自体が申し込みの理由になることはありません。速度改善は「機会損失を減らす」施策であって、「動機をつくる」施策ではないという整理が現実的です。すでに十分速いサイトで数値をさらに詰めるより、提案内容やフォームの設計を見直したほうが効く場面は多くあります。

何を、どう測るか

まず区別すべきなのは、ラボデータとフィールドデータです。開発者の高速な回線とPCで測った数値（ラボデータ）は再現性がある一方、実際のユーザー環境を表していません。実際の訪問者の端末と回線で記録されたフィールドデータのほうが、事業判断には有効です。両者が食い違うときは、原則としてフィールドデータを信じてください。

指標としてはCore Web Vitalsを基準にすると話が早くなります。LCPは主要なコンテンツが表示されるまでの時間、INPは操作に対する反応の速さ、CLSは表示中にレイアウトがずれる量です。数値を眺めるだけでなく、廉価帯のAndroid端末とモバイル回線で実際に自社サイトを開いてみると、体感として何が遅いのかがすぐにわかります。

• ●LCP：主要コンテンツが表示されるまでの時間。多くの場合は画像かWebフォントが原因
• ●INP：クリックやタップへの反応速度。重いJavaScriptが原因になりやすい
• ●CLS：表示中のレイアウトのずれ。画像や広告枠のサイズ未指定が典型
• ●フィールドデータ：実際の訪問者環境での実測値。改善判断はこちらを優先
• ●計測は改善前に必ず取得し、公開後も同じ条件で比較する

直す順番 — 効果の大きいところから

改善は、費用対効果の高い順に進めるのが鉄則です。実際の案件で最も効くのは、ほぼ例外なく画像です。必要以上に大きい画像を等倍で読み込んでいる、最新のフォーマットに変換していない、画面外の画像まで初期表示で読み込んでいる。この3点を直すだけで、LCPが目に見えて改善するサイトは多くあります。

次に見るのがWebフォントと外部タグです。フォントの読み込み方法によっては、本文が一定時間表示されません。また、タグマネージャ経由で追加されたチャットツール、広告タグ、ヒートマップなどは、一つひとつは軽くても合算するとページ本体より重くなることがあります。使っていないタグの棚卸しは、コードを書かずにできる改善です。

そのうえで、JavaScriptの分割と遅延読み込み、サーバー応答時間、キャッシュとCDNの設定に進みます。ここは実装側の作業になりますが、順番を守れば、多くのサイトは全面的な作り直しをせずに実用的な速度まで到達できます。

• ●画像：適切なサイズへのリサイズ、次世代フォーマット、画面外の遅延読み込み
• ●Webフォント：使用ウェイトの削減、読み込み方法の見直し
• ●外部タグ：使っていないタグの削除、必要なタグの読み込みタイミング調整
• ●JavaScript：初期表示に不要なコードの分割と遅延実行
• ●サーバー：応答時間、キャッシュ設定、配信の見直し

速くしても数字が動かないときに見る場所

速度を改善したのにCVRが変わらない場合、ボトルネックは別の場所にあります。よくあるのは、フォームの入力項目が多すぎる、次に何をすればよいかが画面上で不明確、スマートフォンで送信ボタンが押しにくい位置にある、といった導線と入力体験の問題です。速度は前提条件であって、意思決定の理由ではありません。

もう一つの可能性は、そもそも流入している人が対象顧客ではないことです。この場合、ページをいくら速くしても数字は動きません。速度改善に着手する前に、流入経路ごとのCVRを分けて見ておくと、投資すべき場所を取り違えずに済みます。私たちも、速度改善が最優先ではないと判断した場合は、その旨をそのままお伝えします。

よくある質問