「LPは作ったのに、なぜかコンバージョンが伸びない」

広告費を投じてランディングページ（以下、LP）を制作し、いざ運用を始めたものの思ったほど成果が出ない。そんな経験をお持ちの方は多いのではないでしょうか。デザインやコピーを何度も練り直しているのに数字が動かない場合、原因は表示速度にあるかもしれません。

Googleの調査によると、ページの読み込み時間が1秒から3秒に増えると離脱率が32%上昇するとされています。LPは「ユーザーが最初に触れるページ」という性質上、通常のWebページ以上に表示速度がコンバージョン率に直結します。

この記事では、Googleが定めるCore Web Vitals（LCP・INP・CLS）の3指標に沿って、LPの表示速度を改善するための具体的な実装テクニックをコード付きで解説します。フロントエンドの専門家でなくても取り組める施策から、一歩踏み込んだ最適化まで段階的に紹介していきます。

Core Web VitalsがLPにとって特に重要な理由

Core Web Vitalsとは、Googleが「ユーザー体験の質」を定量的に評価するために定めた3つの指標です。Googleの公式ドキュメントで詳しく定義されていますが、ここではLP開発の文脈で押さえておくべきポイントに絞って整理します。

LCP（Largest Contentful Paint）

ページ内で最も大きなコンテンツ要素が表示されるまでの時間です。LPではメインビジュアル画像やヒーローセクションの見出しがこれに該当することがほとんどです。目標は2.5秒以内になります。

INP（Interaction to Next Paint）

ユーザーがページ上で行ったクリックやタップなどの操作に対して、画面が反応するまでの時間を測定します。LPではCTAボタンのクリックやフォーム入力時のレスポンスがこれにあたります。目標は200ミリ秒以内です。

CLS（Cumulative Layout Shift）

ページ読み込み中に要素が予期せずずれ動く量を数値化したものです。LPで画像が遅れて表示されてボタンの位置がガタっと動く、あの現象がまさにこれです。目標は0.1以下になります。

通常のWebサイトでは、これらの指標はSEO評価の一部として重要視されています。しかしLPの場合、それだけではありません。LPは「広告をクリックしたユーザーが最初に見るページ」であり、ここでの体験が悪ければ、広告費をかけて集めたユーザーがそのまま離脱してしまいます。つまりCore Web Vitalsの改善は、広告のROAS（投資対効果）に直結するのです。

Core Web Vitalsの各指標の概念や測定方法についてさらに詳しく知りたい方は、サーチフォーカスのCore Web Vitals改善ガイドも参考にしてください。

LCP改善：ファーストビューを2.5秒以内に表示する

LCPはユーザーの第一印象を左右する指標です。LPにおけるLCP要素は多くの場合、ヒーロー画像かメインの見出しテキストになります。ここから改善を始めましょう。

ヒーロー画像の最適化

LPのヒーロー画像は見た目のインパクトを重視するあまり、ファイルサイズが大きくなりがちです。以下の3段階で最適化します。

次世代フォーマットの採用

JPEG/PNGの代わりにWebPまたはAVIFフォーマットを使いましょう。WebPはJPEGと比較して25〜35%、AVIFはさらに20%ほどファイルサイズを削減できます。

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="サービス紹介メインビジュアル"
       width="1200" height="630"
       fetchpriority="high"
       decoding="async">
</picture>

ここでのポイントは fetchpriority="high" 属性です。これはブラウザに「この画像を優先的に読み込んでほしい」と伝える指定で、LCPの改善に大きく寄与します。一方で、ファーストビュー外の画像には loading="lazy" を指定して、不要なリソース読み込みを後回しにします。

レスポンシブ画像の提供

スマートフォンに1200px幅の画像を配信するのは帯域の無駄です。srcset と sizes を使って端末に応じた適切なサイズを配信しましょう。

<img srcset="hero-480.webp 480w,
             hero-768.webp 768w,
             hero-1200.webp 1200w"
     sizes="100vw"
     src="hero-1200.webp"
     alt="サービス紹介メインビジュアル"
     width="1200" height="630"
     fetchpriority="high">

プリロードによる先行読み込み

ヒーロー画像のURLがCSSの background-image で指定されている場合、ブラウザはHTMLの解析→CSSの読み込み→画像の発見という手順を踏むため、画像の取得開始が遅れます。<link rel="preload"> でこのボトルネックを解消できます。

<head>
  <link rel="preload" as="image" href="hero.webp"
        type="image/webp" fetchpriority="high">
</head>

クリティカルCSSのインライン化

ブラウザは外部CSSファイルの読み込みが完了するまでページの描画を開始しません。これをレンダリングブロックと呼びます。LPのファーストビューに必要なCSSだけを <style> タグとしてHTMLに直接記述することで、外部CSSの読み込みを待たずに描画を開始できます。

<head>
  <!-- ファーストビューに必要な最小限のCSS -->
  <style>
    .hero { position: relative; min-height: 60vh; }
    .hero__title { font-size: clamp(1.5rem, 4vw, 3rem); }
    .cta-button { background: #e63946; color: #fff; padding: 1rem 2rem; }
  </style>
  <!-- 残りのCSSは非同期で読み込む -->
  <link rel="preload" href="styles.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

WebpackやViteなどのビルドツールを使っている場合は、crittersというプラグインでクリティカルCSSの抽出を自動化できます。

Webフォントの最適化

カスタムフォントの読み込みもLCPを遅延させる要因です。特に日本語フォントはファイルサイズが大きいため、以下の対策が効果的です。

@font-face {
  font-family: 'NotoSansJP';
  src: url('NotoSansJP-Regular.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+3000-9FFF, U+FF00-FFEF;
}

font-display: swap はフォント読み込み完了前にシステムフォントで仮表示する指定です。ユーザーはフォントの切り替わりに気づくかもしれませんが、テキストが読めない時間をなくすことができます。

また unicode-range を指定することで、そのページで実際に使われる文字範囲のフォントデータだけを読み込むようブラウザに伝えられます。Google Fontsを利用する場合は、サブセット配信が自動で行われるためこの設定は不要です。

CLS改善：レイアウトのガタつきをなくす

CLSの数値が大きいということは、ユーザーが読もうとしている場所やクリックしようとしているボタンが、突然別の位置に動くということです。LPでCTAボタンの位置がずれると、ユーザーが意図しないリンクをクリックしてしまう可能性もあり、信頼性の低下に直結します。

画像・動画に明示的なサイズを指定する

CLSの最大の原因は、画像や動画の読み込みによるレイアウトシフトです。これを防ぐ最もシンプルな方法は、HTML上で width と height を明示することです。

<img src="feature.webp" alt="機能紹介" width="600" height="400">

ブラウザはこの属性値からアスペクト比を計算し、画像が読み込まれる前に適切な領域を確保します。CSSでレスポンシブに対応する場合は、以下のように組み合わせます。

img {
  max-width: 100%;
  height: auto;
}

動的に挿入されるコンテンツの領域確保

LPでよくあるパターンとして、JavaScriptで後からバナーやポップアップを挿入するケースがあります。これがCLSの原因になりがちです。

/* 動的バナーの領域をあらかじめ確保する */
.promo-banner-slot {
  min-height: 80px;
  contain: layout;
}

contain: layout はCSS Containmentという仕様で、その要素内部のレイアウト変更が外部に影響しないことをブラウザに宣言するものです。W3CのCSS Containment仕様で定義されています。

フォント読み込みによるレイアウトシフトへの対策

Webフォントが読み込まれた瞬間にテキストの行数が変わり、後続のコンテンツがずれるのもよくあるCLSの原因です。前述の font-display: swap に加えて、フォールバックフォントのサイズを調整するsize-adjustを使うことで、フォント切り替え時のレイアウトシフトを最小限に抑えられます。

@font-face {
  font-family: 'NotoSansJP-fallback';
  src: local('Hiragino Sans'), local('Yu Gothic');
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
  line-gap-override: 0%;
}

body {
  font-family: 'NotoSansJP', 'NotoSansJP-fallback', sans-serif;
}

この設定により、カスタムフォントとフォールバックフォントの表示サイズがほぼ一致するため、フォント切り替え時のレイアウトの動きが最小限になります。

INP改善：ユーザー操作にすばやく反応する

INPは比較的新しい指標で、2024年3月にFID（First Input Delay）に代わって正式にCore Web Vitalsに加わりました。LPでは主にCTAボタンのクリック、フォーム入力、アコーディオンの開閉といったインタラクションが測定対象になります。

メインスレッドをブロックしない

JavaScriptの実行はブラウザのメインスレッドで行われます。重い処理がメインスレッドを占有すると、ユーザーの操作に対する応答が遅れます。

LPでありがちなのは、ページ読み込み時に分析タグやチャットウィジェットのスクリプトが大量に実行されるケースです。これらは defer や動的インポートで後回しにしましょう。

<!-- 悪い例：レンダリングをブロックする -->
<script src="analytics.js"></script>
<script src="chat-widget.js"></script>

<!-- 良い例：ページの表示に影響しないスクリプトは遅延させる -->
<script src="analytics.js" defer></script>
<script>
  // チャットウィジェットはユーザーが下までスクロールしたら読み込む
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting) {
      import('./chat-widget.js');
      observer.disconnect();
    }
  });
  observer.observe(document.querySelector('.footer'));
</script>

イベントハンドラの最適化

フォームのバリデーションやスクロール連動アニメーションなど、頻繁に発火するイベントは requestAnimationFrame で制御します。

// スクロール連動のヘッダー表示制御（INPに優しい実装）
let ticking = false;
document.addEventListener('scroll', () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      updateHeaderVisibility();
      ticking = false;
    });
    ticking = true;
  }
}, { passive: true });

{ passive: true } オプションは「このイベントリスナーは preventDefault() を呼ばない」とブラウザに宣言するもので、スクロール処理のパフォーマンスが向上します。

サードパーティスクリプトの管理

LP上でよく使われるサードパーティスクリプトには以下のようなものがあります。

  • Google Tag Manager / Google Analytics
  • Facebook Pixel / Meta Pixel
  • ヒートマップツール（Microsoft Clarity、Hotjarなど）
  • ライブチャット・チャットボット

これらを無秩序に <head> に並べると、メインスレッドが長時間ブロックされINPが悪化します。Google Tag Managerを使って一元管理し、トリガー条件を設定してページ表示完了後に順次読み込むのがベストプラクティスです。Googleのタグマネージャー公式ドキュメントでトリガー設定の詳細を確認できます。

// GTMのカスタムHTMLタグでの遅延読み込み例
(function() {
  // ページの読み込みが完了してから2秒後にヒートマップを初期化する
  setTimeout(function() {
    var s = document.createElement('script');
    s.src = 'https://www.clarity.ms/tag/your-id';
    document.body.appendChild(s);
  }, 2000);
})();

実装の優先順位と効果測定

ここまで多くのテクニックを紹介してきましたが、すべてを一度に実装する必要はありません。従業員80名規模のBtoB製造業で、自社のリード獲得用LPの改善を進めたケースでは、以下の優先順で取り組み、段階的に成果を上げていきました。

最初の1週間で着手すべきこと（効果大・工数小）

  • ヒーロー画像のWebP変換と fetchpriority="high" の追加 → LCPが4.2秒から2.1秒に改善
  • 全画像への width / height 属性の追記 → CLSが0.28から0.05に改善
  • 不要なスクリプトの defer 化 → INPが350msから180msに改善

次の2週間で取り組むこと（効果中・工数中）

  • レスポンシブ画像の srcset 対応
  • クリティカルCSSのインライン化
  • サードパーティスクリプトの遅延読み込み整理

その先で検討すること（効果小〜中・工数大）

  • フォントのサブセット化と size-adjust の導入
  • 画像CDNの導入とアダプティブ配信

効果測定には PageSpeed Insights を使って現状のスコアを計測し、改善後に再計測して差分を確認するのが最も手軽です。より継続的に監視したい場合は、Chrome DevToolsのパフォーマンスパネルでリアルタイムに指標を確認できます。

LP改善の効果をデータで検証する方法については、データドリブンのLP A/Bテスト実践ガイドで詳しく解説されています。

LP高速化で見落としがちな3つのポイント

モバイルファーストで検証する

LP訪問者の60〜80%はスマートフォンからのアクセスです。にもかかわらず、開発環境のデスクトップで「速い」と感じているだけで安心していないでしょうか。PageSpeed Insightsでは必ずモバイルタブで確認してください。3G回線相当のスロットリングでテストすると、実際のユーザー体験に近い結果が得られます。

高速化とデザインはトレードオフではない

「速くするためにはデザインを犠牲にするしかない」と考える方もいますが、実際にはそうではありません。WebPやAVIFを使えば画質を保ったままファイルサイズを大幅に削減できますし、<picture> タグによる出し分けで端末に最適な画像を配信できます。LPのUI/UXデザインの原則と高速化は両立できるのです。デザインとパフォーマンスの両立について詳しくは、クリエイティブハブのLP UI/UX設計ガイドが参考になります。

SEO観点からもLPの高速化は意味がある

「LPは広告経由だからSEOは関係ない」と思われがちですが、LP自体がオーガニック検索で流入を獲得できるケースも少なくありません。Core Web VitalsはGoogle検索のランキング要因の一つであり、LPを高速化することで広告費をかけずに流入を増やせる可能性があります。この点については、サーチフォーカスのLP×オーガニック流入最適化で具体的な手法が解説されています。

まとめ

LP高速化は一見すると専門的なテーマですが、実際には画像の最適化やHTML属性の追記といった小さな作業の積み重ねで大きな効果が得られます。

この記事で紹介した施策の中でも、まずは以下の3つから始めることをおすすめします。

  • PageSpeed Insightsで自社LPの現状スコアを確認する
  • ヒーロー画像をWebPに変換し、fetchpriority="high" を追加する
  • すべての画像に width と height 属性を指定する

この3つだけでも、LCPとCLSが目に見えて改善するはずです。まずは来週、PageSpeed Insightsで自社LPのモバイルスコアを確認するところから始めてみてください。数字が明確に出るので、改善のモチベーションにもつながります。