LP制作の表示速度を改善する方法｜パフォーマンス最適化と技術選定の完全ガイド

LP制作で本当に大事な技術の話

LP、デザインよりも"速度"で損しているかもしれません。

ページが遅くて離脱される。スマホで重くて見られない。広告費をかけてもCVしない。

これ、実は**「技術選定ミス」が原因**のことが多いです。

ページ読み込みが遅いと、ユーザーは離れる。1秒遅れるごとにコンバージョン率が7%落ちるというデータがある以上、技術選定とパフォーマンス最適化は、デザインと同じくらい成果に効く。

この記事では、LPの成果に直結する「パフォーマンス最適化」と正しい技術の選び方を解説します。

技術はこれで選べばOK

迷ったときの判断基準を最初に示しておきます。

優先事項	おすすめ構成	代表的な技術
とにかく速さ重視	静的サイト（Jamstack）	Astro / Next.js / 11ty
バランス型	CMS + 最適化	WordPress + 軽量テーマ
柔軟性重視	フルスクラッチ	Next.js + ヘッドレスCMS

迷ったら**「速い構成を選ぶ」が正解**です。

なぜ速度が重要なのか？

ページが遅いと、ユーザーは待たずに離脱します。

遅延	影響
表示に3秒以上	離脱率が 32%増加
モバイルで3秒超	53%のユーザーが離脱
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で自動チェックする。

リソース	上限
HTML	30KB以下
JavaScript	150KB以下
CSS	50KB以下
画像	500KB以下
合計	800KB以下

リソース配分イメージ（合計 800KB）

HTML 30KB

CSS 50KB

JS 150KB

画像 500KB

0KB 800KB

Lighthouse CLIをCI/CDに組み込み、スコアが90点を下回った場合はビルドを失敗させる設定が効果的です。

失敗しない進め方

技術選定で迷ったら、この順番で進めましょう。

1. 最初はシンプル構成で作る複雑な技術は後から追加できる。まずは速く、シンプルに。

2. 数値を見て改善Web Vitalsを計測し、ボトルネックを特定。感覚ではなくデータで判断。

3. 必要なら技術を変える成果が出ない、運用が回らないなら、技術スタックを見直す。

これが一番失敗しない進め方です。

成果を出すために守りたい4原則

01

継続的改善

計測→改善→再計測のサイクルを止めない。一度きりの最適化に意味はない。

02

優先順位付け

全部やろうとしない。効果の高い施策（LCP・画像最適化）から着手する。

03

測定可能性

すべての改善を定量的に評価する。感覚ではなくデータで語る。

04

チーム共有

パフォーマンスをビジネス指標として共有。技術チームだけの課題にしない。

結局、パフォーマンスは「習慣」だ。

完璧な技術選定よりも、計測と改善を繰り返す文化の方が長期的な成果を生みます。技術選定は「目的に合わせて選ぶ」が基本。迷ったら速い構成を選び、まずは Web Vitals を計測するところから始めましょう。