会社情報
採用情報
お問い合わせ
Article

ランディングページ最適化リニューアル：CVRを劇的に上げた方法

高田晃太郎
ランディングページ最適化リニューアル：CVRを劇的に上げた方法

業界調査では、モバイルサイトの読み込みが0.1秒高速化するとコンバージョン率（CVR）が平均で約8〜10%改善することが報告されています¹²。DeloitteとGoogleの共同研究が示すこの数字は、体感ではわずかな差でも収益には大きな影響がある事実を裏づけます。さらに、Googleが提唱するCore Web Vitals（ウェブ体験の品質を測る主要指標群。LCP＝Largest Contentful Paint：主要コンテンツの描画完了までの時間、CLS＝Cumulative Layout Shift：レイアウトのずれ、INP＝Interaction to Next Paint：操作に対する応答の速さ）には、良好とされる基準値（LCP≤2.5秒、CLS≤0.1、INP≤200ms）が公開されています³⁴⁵。一般に、読み込み体験と意思決定動線（CTAやフォームの導線）を同時に最適化することで、Core Web Vitalsの改善とCVR向上が同時に観測されるケースは少なくありません。本稿で示す数値や設定はあくまで参考例であり、業種・トラフィック構成・デバイス比率などによって適正値は変動します。ページの見た目を変えるだけでは機能しません。計測設計、配信アーキテクチャ、実験設計、そして意思決定プロセスが連鎖して初めて結果が出ます。本稿では、CTOやエンジニアリーダーが自社で再現できる形で、実装手法とコードを公開します。

データから始めるLPリニューアルの設計

多くのLP改善が失敗する理由は、視覚的な刷新から着手してしまい、計測可能な仮説と実験設計が後追いになることです。最初に必要なのは、ビジネスKPIからの逆算とイベントの正規化です。たとえば主要KPIを「リード送信CVR（フォーム送信完了/セッション）」と定義し、補助指標としてスクロール完了率、主要CTA（Call To Action）の可視回数、フォーム各フィールドのエラー率、ファーストインタラクション（最初の操作）までの時間を採用します。これらは後述する計測基盤で自動収集し、BigQueryなどのDWHに日次で着地させる設計が扱いやすいでしょう。重要なのは、定義をシンプルに保ち、実装と分析の行き来が迷子にならない構造を作ることです。

情報設計では、ファーストビューに価値提案、証拠、明確な次の行動を集中させます。具体的には、顧客メリットを一文で言い切るヘッドライン、定量的な裏付け（公開統計や第三者レポートへの参照）、社会的証明としてのロゴやレビュー、そして摩擦の少ない主要CTAを同一視界に収めます。ファーストビュー以降は、反論処理、詳細の掘り下げ、比較、FAQ、セカンダリCTAの順で論理展開を組み、スクロールデプスとヒートマップの行動データで折返し位置を微調整します。ここでの原則は、図解やUI変更の前に仮説を言語化し、計測設計に落とし込むことです。

実験単位は「一画面一メッセージ」を原則にします。ファーストビューではヘッドラインのベクトルを複数案で比較し、フォームではフィールド数の削減とバリデーション順序の最適化を別実験として独立させます。実験期間は流入のばらつきと営業日の影響を考慮し、最低でも二週間、可能なら四週間の観測で有意性と持続性を同時に検証します。

スピードと可視性：計測基盤の整備

高速なLPは成果の必要条件です。私はまずRUM（Real User Monitoring：実ユーザー計測）の確立から着手します。ライブラリにはweb-vitalsを使い、LCP、CLS、INP、TTFBなどの実測値を計測し、独自エンドポイントに送信してBigQueryへ集約します。これによりA/Bテストの各バリアントごとの体験差を定量化できます。以下はブラウザでCore Web Vitalsを計測し、送信するコード例です。

// /public/vitals.js
import {onCLS, onLCP, onINP, onTTFB} from 'web-vitals';

function sendToAnalytics(metric) {
  try {
    const match = document.cookie.match(/(?:^|; )expVariant=([A-Z])/);
    const expVariant = match ? match[1] : 'C';
    const body = JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      rating: metric.rating,
      navigationType: performance?.getEntriesByType('navigation')[0]?.type || 'unknown',
      exp_variant: expVariant,
      path: location.pathname,
      ts: Date.now()
    });
    navigator.sendBeacon('/rum', body) || fetch('/rum', {method: 'POST', headers: {'Content-Type': 'application/json'}, body});
  } catch (e) {
    console.error('vitals send error', e);
  }
}

onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onTTFB(sendToAnalytics);

受け側は軽量なエンドポイントで十分です。以下はNode.jsとExpressでの受信とエラーハンドリング、そしてBigQueryへのバッファリング送信の例です。

// server/rum.js
import express from 'express';
import {BigQuery} from '@google-cloud/bigquery';

const app = express();
app.use(express.json());
const bq = new BigQuery();
const dataset = bq.dataset('lp_analytics');
const table = dataset.table('web_vitals');

app.post('/rum', async (req, res) => {
  try {
    const payload = Array.isArray(req.body) ? req.body : [req.body];
    const rows = payload.map(p => ({...p, received_at: new Date().toISOString()}));
    await table.insert(rows, {raw: true, ignoreUnknownValues: true});
    res.status(204).end();
  } catch (err) {
    console.error('BQ insert failed', err);
    res.status(202).end(); // 受理のみ。後続でリトライキューへ
  }
});

export default app;

計測と並行して、合成監視（Synthetic Monitoring）も用意します。Lighthouse CIでPRごとのパフォーマンス回帰を検知し、しきい値を破ったらビルドを落とします⁶。LCP、CLS、Total Blocking Timeなどに下限・上限を定め、バンド外の差分をデプロイ阻止の条件にします。設定はリポジトリに同梱しておくと再現性が高まります。

// lighthouserc.json
{
  "ci": {
    "collect": {
      "staticDistDir": "./out",
      "url": ["http://localhost:8080/"]
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 1900}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["error", {"maxNumericValue": 150}]
      }
    }
  }
}

GitHub Actionsでの自動実行は次の通りです。キャッシュや並列度に注意しながら、プルリクエストにスコアを貼り付けるとチームの可視性が一気に高まります。

# .github/workflows/lhci.yml
name: Lighthouse CI
on: [pull_request]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: {node-version: '20'}
      - run: npm ci
      - run: npm run build && npm run export
      - run: npx @lhci/cli autorun

アーキテクチャと実装：高速LPのための技術選択

配信モデルは、安定したコンテンツは静的生成、パーソナライズと実験はエッジでの振り分け、問い合わせや計測はAPIに寄せる構成が効果的です。CDNのキャッシュ戦略は、HTMLを短TTLのstale-while-revalidate、アセットは長TTLのimmutableを基本にし、ファーストビューのHero画像は適切なサイズで遅延ではなく事前読み込みにします。フォントはサブセット化し、display:swapを指定してFOIT（Flash of Invisible Text）を避けます。Reactのクライアント側負荷は、上位折り返しより下のコンポーネントを動的インポートしてHydrationの分割を徹底します。

サーバーサイドのA/B割付は、一貫性が重要です。以下はExpressのミドルウェアで、User-Agentやクッキーに依存せず、UUIDベースで安定的にバリアントを付与し、クッキーで再訪を固定化する例です。

// server/ab-middleware.js
import crypto from 'crypto';

export function abAssign(req, res, next) {
  try {
    const cookie = req.headers.cookie || '';
    const match = cookie.match(/expVariant=([A-Z])/);
    if (match) {
      req.expVariant = match[1];
      return next();
    }
    const id = req.headers['x-user-id'] || crypto.randomUUID();
    const hash = crypto.createHash('sha1').update(id).digest('hex');
    const bucket = parseInt(hash.slice(0, 2), 16) % 100; // 0-99
    const variant = bucket < 50 ? 'A' : 'B';
    res.setHeader('Set-Cookie', `expVariant=${variant}; Path=/; Max-Age=2592000; SameSite=Lax`);
    req.expVariant = variant;
    next();
  } catch (e) {
    req.expVariant = 'C';
    next();
  }
}

エッジでの分岐が必要なら、Next.js Middlewareでの実装が適しています。下例はパスに応じたバリアント配信と計測用ヘッダの付与です。

// middleware.ts (Next.js 13+)
import {NextResponse} from 'next/server';
import type {NextRequest} from 'next/server';

export function middleware(req: NextRequest) {
  const url = req.nextUrl.clone();
  if (url.pathname === '/') {
    const cookie = req.cookies.get('expVariant');
    let v = cookie?.value;
    if (!v) {
      const r = Math.random();
      v = r < 0.5 ? 'A' : 'B';
      const res = NextResponse.next();
      res.cookies.set('expVariant', v, {path: '/', maxAge: 60 * 60 * 24 * 30});
      res.headers.set('x-exp-variant', v);
      return res;
    }
    const res = NextResponse.next();
    res.headers.set('x-exp-variant', v);
    return res;
  }
  return NextResponse.next();
}

フロントエンドでは、主要CTAクリックやフォーム送信をGA4へ確実に送信し、二重送信を防ぎます。以下はgtagの例で、実験バリアントをパラメータに含めます。

// analytics/events.js
export function trackLeadSubmit(expVariant) {
  try {
    window.gtag('event', 'generate_lead', {
      send_to: 'GA_MEASUREMENT_ID',
      exp_variant: expVariant,
      value: 1
    });
  } catch (e) {
    // no-op
  }
}

Hydration負荷の削減には、上部の非対話領域を純HTML化し、下部を動的に読み込みます。Next.jsでの実装例を示します。Heroセクションはサーバーコンポーネント、下段のレビューカルーセルはクライアントで遅延ロードします。

// app/page.tsx (Next.js 13+)
import dynamic from 'next/dynamic';
import Hero from './_components/Hero'; // Server Component
const Reviews = dynamic(() => import('./_components/Reviews'), {ssr: false});

export default function Page() {
  return (
    <>
      <Hero />
      <main>
        <section>...価値提案と証拠...</section>
        <section suppressHydrationWarning>
          <Reviews />
        </section>
      </main>
    </>
  );
}

画像はAVIFやWebPを優先し、Heroの最大要素をLCPとして最適化します。プリロードを正しく設定し、表示サイズと実サイズを一致させてCLSを抑えます。

<link rel="preload" as="image" href="/hero.avif" imagesrcset="/hero.avif 1x, /hero@2x.avif 2x" imagesizes="100vw">
<img src="/hero.avif" width="1200" height="640" alt="価値提案" decoding="async" fetchpriority="high">

グロース運用：実験と意思決定のリズム

実験は走らせるだけでは価値になりません。意思決定のスピードと正確性を両立するため、私は週次での仮説レビュー、日次での異常検知、月次での学習サマリーを回します。統計は現実的な範囲で運用し、MDE（最小検出効果量）から必要サンプルサイズを見積もり、80%程度の検出力を目安にします。実運用では順序検定の有意性にこだわりすぎず、ベイズの事後確率やガードレールKPI（直帰率、平均読了時間、パフォーマンス指標）を併用して早期停止の判断を下します。サンプル比率不一致（SRM）は必ず監視し、検出した場合は集計を破棄します。

日次の集計にはBigQueryでの簡易なクエリが役立ちます。以下はA/BごとのCVRと95%信頼区間を算出する一例です。

-- BigQuery Standard SQL example
WITH s AS (
  SELECT exp_variant, COUNTIF(event_name='session_start') AS sessions,
         COUNTIF(event_name='generate_lead') AS leads
  FROM `project.dataset.events`
  WHERE DATE(event_date) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY) AND CURRENT_DATE()
  GROUP BY exp_variant
), m AS (
  SELECT exp_variant, leads / sessions AS cvr, sessions, leads FROM s
)
SELECT a.exp_variant AS variant,
       a.cvr AS cvr,
       1.96*SQRT((a.cvr*(1-a.cvr))/a.sessions) AS cvr_margin
FROM m a;

フォームのフィールド削減やバリデーション順序の見直しはエラー率低減と送信完了率の向上に寄与しやすく、ファーストビューのメッセージベクトルの見直しは主要CTAの初回クリック率を押し上げるケースが一般的に見られます。これらを合算ではなく漸進的に積み上げ、各実験での因果を明確にすることが、持続的なCVR改善への最短距離です。

ROIを見積もる際は、改善前後のCVRとトラフィックから増分リード数を算出し、リードから売上までのコンバージョン率と平均受注単価でインパクトを推計します。たとえば月間1万セッション、CVRが2.0%から2.5%に改善、増分50件のリード、SQL化率40%、成約率25%、平均受注単価80万円とすると、増分売上は約4,800万円/年の規模感になります。これに対してエンジニアリングとデザインの投入工数、広告運用の調整コストを加味しても、投資回収は数週間から数ヶ月のスパンで現実的に狙えます。数値はあくまで例示であり、実際のビジネスモデルに合わせて置き換えてください。

参考になる社内展開とナレッジ共有

成功を一過性にしないため、結果と学びをテンプレート化して他プロダクトへ横展開します。実験のPRD、イベント辞書、UIパターン、パフォーマンス予算、そして失敗事例のカタログを整備し、キックオフ時点で再利用できる状態にすることで、次のリニューアルは初速が格段に上がります。関連する詳説は、GA4移行とイベント設計の解説、Lighthouse CIの導入手順、エッジでのサーバーサイド実験、データ基盤の設計指針を参照してください。内部ドキュメントとしてはもちろん、公開記事としても価値が高い内容です。

まとめ：一画面一メッセージ、計測から始める

LPのリニューアルは見た目の刷新ではなく、計測に始まり、配信アーキテクチャで支え、実験で学習を蓄積する営みです。まずは現状の体験を正確に測るところから着手し、ファーストビューの価値提案とフォームの摩擦を個別に仮説化して検証してください。LCPを2.5秒未満、CLSを0.1未満、INPを200ms未満に収めることを現実的な初期目標とし³⁴⁵、上位折り返しのメッセージ密度と証拠の提示を磨き続けます。次のスプリントで何を変え、どの数字で判断するのかを明確にできれば、CVRの改善は積み上がります。あなたのチームは最初にどの一画面を変えますか。今日から計測を有効化し、ひとつの仮説をデプロイしてみてください。その小さな一歩が、収益構造を変える最短ルートになります。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "ランディングページ最適化リニューアル：CVRを劇的に上げた方法",
  "author": {"@type": "Person", "name": "高田晃太郎"},
  "articleSection": ["設計", "計測", "実装", "運用"],
  "about": ["ランディングページ", "CVR", "A/Bテスト", "Core Web Vitals"],
  "inLanguage": "ja",
  "isAccessibleForFree": true
}

参考文献

  1. Deloitte. Milliseconds make millions: A study of the economic impact of web performance
  2. Think with Google. Why mobile site speed matters
  3. web.dev. Largest Contentful Paint (LCP)
  4. web.dev. Optimize Cumulative Layout Shift (CLS)
  5. web.dev. Interaction to Next Paint (INP)
  6. web.dev. Lighthouse CI: Automate running Lighthouse for every commit