LP・サイト制作における技術選定の基準とCore Web Vitals最適化の実践的手法を、具体的なコード例と共に詳しく解説します。
LP制作で本当に大事な技術の話
LP、デザインよりも"速度"で損しているかもしれません。
ページが遅くて離脱される。スマホで重くて見られない。広告費をかけてもCVしない。
これ、実は「技術選定ミス」が原因のことが多いです。
ページ読み込みが遅いと、ユーザーは離れる。1秒遅れるごとにコンバージョン率が7%落ちるというデータがある以上、技術選定とパフォーマンス最適化は、デザインと同じくらい成果に効く。
この記事では、LPの成果に直結する「パフォーマンス最適化」と正しい技術の選び方を解説します。
技術はこれで選べばOK
迷ったときの判断基準を最初に示しておきます。
とにかく速さ重視 → 静的サイト（Jamstack）
バランス型 → CMS + 最適化
柔軟性重視 → フルスクラッチ
迷ったら「速い構成を選ぶ」が正解です。
なぜ速度が重要なのか？
ページが遅いと、ユーザーは待たずに離脱します。
表示に3秒以上かかると、離脱率は32%増加
モバイルユーザーの53%は3秒以内に表示されないと離れる
1秒の遅延で、CVRが7%低下する
つまり、表示速度＝CVRに直結します。
パフォーマンス最適化は「技術的な理想論」ではなく、ビジネス上の意思決定です。
まずは敵を知る
技術選定の前に、なぜLPが遅くなるのかを理解しましょう。
主な原因は3つ
① 画像が重い
未最適化の画像、必要以上に大きいサイズ、古いフォーマット（JPEG/PNG）を使っている。
② サーバーが遅い
共有サーバー、CDN未使用、キャッシュ設定なし。
③ 不要なスクリプト
使っていないプラグイン、巨大なライブラリ、過剰なトラッキングタグ。
→ つまり「構成の問題」です。
よくある失敗パターン
WordPressに機能を入れすぎて激重
プラグインが20個以上、テーマが重い、画像最適化していない。画像最適化をしていない
10MBの画像をそのままアップロード、Retinaサイズで配信。必要ないJSを読み込みまくる
全ページでアニメーションライブラリを読み込む、使っていないフォントをロード。
ケース別おすすめ構成
プロジェクトの目的と運用体制によって、最適な技術は変わります。
■ とにかく速くしたい
→ 静的サイト（Next.js / Astro）
ビルド時にHTMLを生成、サーバー処理なし
CDNから配信、圧倒的な速度
更新頻度が低いLP・キャンペーンサイト向け
フレームワーク読み込み速度学習コスト向いているケースNext.js★★★★中複数LP・段階的な機能拡張Astro★★★★★低コンテンツ重視・JS最小化11ty★★★★★低シンプルLP・構成の柔軟性
■ 簡単に運用したい
→ WordPress + 軽量テーマ
非エンジニアでも更新可能
プラグインで機能拡張
適切に最適化すれば十分速い
条件： プラグインは最小限、画像最適化必須、CDN必須
■ 柔軟に作りたい
→ Next.js + ヘッドレスCMS
マーケティングチームが頻繁に更新
A/Bテストを積極的に回したい
ISRで静的サイトの速度とCMSの柔軟性を両立
ヘッドレスCMSを使うべきタイミング:
非エンジニアが運用する、コンテンツ更新が頻繁、複数サイトで同じコンテンツを使いまわす。Next.js + Contentful の組み合わせでISRを活用すれば、静的サイトの速度とCMSの柔軟性を両立できる。
すぐに効果が出る3つの施策
技術選定の前に、今すぐできる改善があります。
① 画像を軽くする
AVIFまたはWebPを使う（JPEGより40〜60%軽い）
ファーストビューの画像に
priority属性を付与スクロール先の画像は
loading="lazy"で遅延読み込みCDNのキャッシュ設定は最低1年間
② 不要なスクリプトを削除
使っていないプラグインを削除
トラッキングタグを見直す（本当に必要？）
コード分割で必要なものだけ読み込む
③ CDNを使う
静的ファイルをCDNから配信
キャッシュ設定を最適化
グローバル配信で地域を問わず高速化
Googleが見ている3つの指標
SEOにも直結するCore Web Vitals。パフォーマンス改善の指標として押さえておきましょう。
LCP
最大コンテンツの
表示速度
≤ 2.5s
ヒーロー画像の最適化、フォントのpreload、CDNキャッシュが効く
FID
初回入力への
反応速度
≤ 100ms
JS遅延読み込み、コード分割、デバウンス処理(推奨300ms)
CLS
レイアウトの
ずれ
≤ 0.1
aspect-ratio で事前スペース確保、スケルトンUIの活用
これらの指標を定期的に計測し、改善サイクルを回すことが重要です。
「重すぎるページ」を防ぐ予算管理
チーム全員が基準を持つことが大事。リソースサイズに上限を設け、CI/CDで自動チェックする。
リソース上限HTML30KB以下JavaScript150KB以下CSS50KB以下画像500KB以下合計800KB以下
Lighthouse CLIをCI/CDに組み込み、スコアが90点を下回った場合はビルドを失敗させる設定が効果的。
失敗しない進め方
技術選定で迷ったら、この順番で進めましょう。
01、最初はシンプル構成で作る
複雑な技術は後から追加できる。まずは速く、シンプルに。
02、数値を見て改善
Web Vitalsを計測し、ボトルネックを特定。感覚ではなくデータで判断。
03、必要なら技術を変える
成果が出ない、運用が回らないなら、技術スタックを見直す。
これが一番失敗しない進め方です。
成果を出すために守りたい4原則
01、継続的改善
計測→改善→再計測のサイクルを止めない。一度きりの最適化に意味はない。
02、優先順位付け
全部やろうとしない。効果の高い施策（LCP・画像最適化）から着手する。
03、測定可能性
すべての改善を定量的に評価する。感覚ではなくデータで語る。
04、チーム共有
パフォーマンスをビジネス指標として共有。技術チームだけの課題にしない。
結局、パフォーマンスは「習慣」だ。
完璧な技術選定よりも、計測と改善を繰り返す文化の方が長期的な成果を生む。技術選定は「目的に合わせて選ぶ」が基本。迷ったら速い構成を選び、まずは Web Vitals を計測するところから始めよう。
コレデイー編集部
.png&w=3840&q=75)