LPレスポンシブ対応の方法｜CSSの基本とスマホ7施策

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！

LPをPCで作ったら、スマホで見ると文字が小さい、横にはみ出す、ボタンが押しにくい。レスポンシブ対応が必要なのは分かっていても、CSSのどこから手をつければいいのか、スマホのCVRを上げるには何を直せばいいのか、迷っていませんか。

LPのレスポンシブ対応とは、1つのHTMLのまま、画面の幅に合わせてレイアウトや文字・画像の大きさを切り替えて表示できるようにすることです。MDN Web Docsでは、レスポンシブウェブデザインを「ユーザビリティを確保しながら、すべての画面サイズと解像度でウェブページをうまく描画するためのウェブデザインの手法」と説明しています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。

この記事では、LPのレスポンシブ対応の基本3点（viewport・メディアクエリー・画像）とCSSの書き方の例、スマホで崩れず使いやすくする7つの施策、レスポンシブが難しいときの「デバイス別表示」との違い、公開前後の確かめ方までを、MDN・web.dev・Google 検索セントラルなどの公式情報をもとに解説します。

01｜【結論】LPレスポンシブ対応で押さえる7つの施策

レスポンシブ対応の土台は、05で解説する3点（viewportの指定・メディアクエリー・画像の可変化）です。そのうえで、スマホで崩れず使いやすくするための7つの施策を、公式の基準とあわせて並べました。

#	施策	やること	公式の基準・根拠
1	画像を軽くする	WebPで書き出し、表示サイズに合った画像を使う	WebPはPNG・JPEGより小さい（Google for Developers）
2	画像の遅延読み込み	ファーストビューより下の画像に loading="lazy"	LCPの画像は遅延読み込みしない（web.dev）
3	タップ領域を広げる	ボタン・リンクの押せる範囲を広げ、間隔を空ける	Apple：44×44pt以上／web.dev：48デバイス非依存ピクセル前後
4	フォームを入力しやすくする	項目を減らし、type・inputmode・autocomplete を指定	端末に合ったキーボードと自動入力（MDN）
5	ファーストビューを1つの目的に絞る	スマホの最初の画面に、伝えたいことと申し込みボタンを置く	LCPは2.5秒以下が目安（web.dev）
6	追従CTAボタン	position: fixed で画面の下に固定し、本文に余白を足す	固定した要素は文書のフローから外れる（MDN）
7	スマホだけでABテスト	スマホの案を分けて作り、デバイス別に成果を比べる	Googleオプティマイズは2023年9月30日に終了

施策の詳細は04、CSSの書き方は05、公開前後の確かめ方は07で解説します。

｜Squad beyondの解決事例を公開中！

02｜スマホのCVRがPCと変わる理由

スマホとPCでは、同じLPでも見え方と操作のしかたが違います。

• 画面の幅が狭く、一度に見える情報が少ない
• 通信環境が一定ではなく、表示の速さの影響を受けやすい
• 指で操作するため、小さなボタンや入力欄が押しにくい
• 移動中などのすき間時間に見られることがある

PC向けに作ったページをそのままスマホに出すと、これらの違いがそのまま「読みにくい」「押しにくい」「待たされる」につながります。デバイスの違いを前提に作り直すことが、レスポンシブ対応の本質です。

まずは、自社のLPでスマホとPCのCVRがどれだけ違うのかを、デバイス別に分けて確かめるところから始めます（07）。

03｜スマホCVRが低い5つの典型原因（自社診断チェックリスト）

3-1. 原因1：ファーストビューに情報を詰め込みすぎている

PC前提でデザインしたLPをそのままスマホで表示すると、最初の画面に多くの要素が並び、何を見ればいいのかが分からなくなります。スマホは一度に見える範囲が狭いため、最初の画面に置くものを絞ります（施策5）。

3-2. 原因2：フォームの項目が多く、入力しにくい

PCではキーボードで入力できる項目も、スマホでは1つずつ指で入力することになります。必須ではない項目が残っていないか、電話番号やメールアドレスの欄で合ったキーボードが出るかを確かめます（施策4）。

3-3. 原因3：ボタンが小さく、タップしづらい

指の大きさに対してボタンが小さいと、押し間違いや「押せない」状態が起こります。Appleのヒューマンインターフェイスガイドラインは、ボタンには少なくとも44×44ptの「hit region（押せる範囲）」が必要としています（出典：Buttons｜Apple Human Interface Guidelines）。

3-4. 原因4：表示が遅い

スマホの通信環境では、PC基準の重い画像やJavaScriptが表示を遅くします。web.devでは、ページの主要な内容が表示されるまでの時間を測る指標LCP（Largest Contentful Paint）を2.5秒以下にすることを目指すべきとし、4.0秒を超える値を「不良」としています。測るときは、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルを見るのがよいとしています（出典：Largest Contentful Paint（LCP）｜web.dev）。LPの表示速度の原因と対策は、LPの表示速度を改善するには？原因と対策方法を解説で詳しく解説しています。

3-5. 原因5：文字が小さく読めない（viewportの指定漏れ）

文字が小さすぎると、拡大しないと読めません。Chromeの点検ツールLighthouseは、ページの文字の40%以上が12px未満のときに警告を出し、ページの文字の60%以上を12px以上にすることを目安としています。viewportの設定が無いために文字が読めない、と出た場合は、<meta name="viewport" content="width=device-width, initial-scale=1"> を <head> に足すよう案内しています（出典：Document does not use legible font sizes｜Chrome for Developers）。viewportの指定がない場合に起こることは、05で解説します。

04｜スマホCVRを上げる7つの施策

4-1. 施策1：画像を軽くする（WebP・表示サイズに合わせる）

画像の書き出し方を変えるだけで取り組めるので、最初に手をつけやすい施策です。Googleによると、WebPの可逆圧縮の画像はPNGより26%小さく、非可逆圧縮の画像は同じ画質指標（SSIM）のJPEGより25〜34%小さくなります。WebPはChrome・Safari・Firefox・Edge・Operaで標準でサポートされています（出典：An image format for the Web｜Google for Developers）。

あわせて、表示する大きさより大きな画像を読み込まないようにします。画面の幅に合わせて画像の大きさを出し分ける方法は、05の5-4で解説します。なお、Squad beyondでは、アップロードした画像はサーバー側で自動で圧縮され、横幅1,600px以下にする必要があります（出典：Squad beyondにアップロードできるファイルについて｜Squad beyond FAQ）。

4-2. 施策2：ファーストビューより下の画像だけを遅延読み込みする

<img> に loading="lazy" を付けると、画面の外にある画像の読み込みを後回しにできます。ただしweb.devは、ページの読み込み時に表示領域に入る可能性が高い画像、特にLCPの対象になる画像は遅延読み込みしないように、としています。また、レイアウトのずれを避けるため、すべての <img> に width と height の属性を付けることをすすめています（出典：Browser-level image lazy loading for the web｜web.dev）。

書き方の例：<img src="photo.webp" width="600" height="400" loading="lazy" alt="商品の写真">（ファーストビューより下の画像だけに付ける）

4-3. 施策3：タップできる範囲を広げる

ボタン・リンク・チェックボックスなど、指で押す要素の押せる範囲を広げます。Appleは44×44pt以上を挙げています（3-3）。web.devは、推奨する最小のタッチターゲットのサイズを48デバイス非依存ピクセル前後（原文 "around 48 device independent pixels"）とし、ターゲットどうしも上下左右に間隔を空けるよう求めています（原文 "spaced about 8 pixels apart"）（出典：Accessible tap targets｜web.dev）。

見た目を小さく保ちたい場合でも、CSSの padding で押せる範囲を広げられます。ボタンの大きさ・色・置き場所の決め方は、CTAボタンのデザインとは？色・サイズ・配置の基準と決め方で解説しています。

4-4. 施策4：フォームを入力しやすくする

スマホのフォームは、まず項目を減らします。そのうえで、端末に合ったキーボードと自動入力が出るように属性を指定します。

• inputmode は、入力されるデータの型のヒントで、ブラウザーが適切な仮想キーボードを表示できるようにします。tel は電話番号用のテンキー、email はメールアドレス用のキーボード、numeric は数字だけのキーボードです。電話番号やメールアドレスの欄は、ふつうは代わりに <input type="tel">・<input type="email"> を使うよう書かれています（出典：HTML inputmode グローバル属性｜MDN Web Docs）
• autocomplete は、欄にどの種類の情報が期待されているかをブラウザーに示し、自動入力の支援を受けられるようにします。値には name（氏名）・email・tel・postal-code（郵便番号）などがあります（出典：autocomplete 属性｜MDN Web Docs）

書き方の例：<input type="tel" name="tel" autocomplete="tel">、郵便番号は <input type="text" inputmode="numeric" autocomplete="postal-code">

フォームの改善を道具で進めたい場合は、EFOツール比較15選｜CVR改善する選び方も参考になります。

4-5. 施策5：ファーストビューを「1つの目的」に絞る

スマホのファーストビューには、「最も伝えたいメッセージ」と「申し込みボタン」を置き、補足の情報は2画面目以降に回します。視線が1か所に集まるようにするのが基本です。

ファーストビューの大きな画像やテキストは、LCPの対象になりやすい要素です。web.devは、LCPの対象として <img> 要素、<video> 要素、url() で背景画像を読み込む要素、テキストを含むブロックレベル要素などを挙げています（出典：Largest Contentful Paint（LCP）｜web.dev）。ファーストビューの画像は軽くし（施策1）、遅延読み込みの対象から外します（施策2）。

4-6. 施策6：追従CTAボタンを置く

画面の下に常に表示される追従CTAボタンを置くと、どこまでスクロールしてもタップできる状態を作れます。CSSでは position: fixed; bottom: 0; で実装できます。

注意点は2つあります。1つ目は余白です。position: fixed の要素は文書の通常のフローから除外され、ページレイアウト内に要素のための空間が作られません（出典：position｜MDN Web Docs）。そのままでは本文の最後がボタンに隠れるので、本文の下にボタンの高さぶんの余白を足します。

2つ目は、画面の形が長方形でない端末です。viewportに viewport-fit=cover を指定する場合、MDNは重要なコンテンツが画面の外に出ないよう safe-area-inset-* 変数を使うことを強くすすめています（出典：<meta name="viewport"> 属性値｜MDN Web Docs）。env(safe-area-inset-bottom) は、画面の下端から安全な距離を表し、ツールバーなどがない長方形のビューポートでは0になります（出典：env() 関数｜MDN Web Docs）。

書き方の例：.fixed-cta { position: fixed; bottom: 0; left: 0; right: 0; padding-bottom: env(safe-area-inset-bottom); }

4-7. 施策7：スマホだけでABテストをする

PCとスマホでは見え方と操作が違うため、PCで効いた施策がスマホでも効くとは限りません。ABテストも、スマホの案を分けて作り、デバイス別に成果を比べます。

GoogleオプティマイズとOptimize 360は、2023年9月30日以降は利用できなくなっています（出典：Google オプティマイズ（2023 年 9 月廃止）｜アナリティクス ヘルプ）。いまスマホ専用のABテストをするなら、ほかのABテストツールやSquad beyondを使います。LPのABテストの手順はLPのABテストの正しいやり方は？メリットや手順、ツールを解説、テストの期間とサンプル数の決め方はABテストの有意差とは？必要サンプル数と期間の決め方で解説しています。

05｜レスポンシブ対応のCSS基本実装（書き方の例つき）

LPをレスポンシブ対応にする基本は、viewportの指定・メディアクエリー・画像の可変化の3点です。ここでは、それぞれの書き方を例つきで解説します。コード中の数値（48emなど）は説明用の値です。

5-1. viewportを指定する

まず <head> にviewportの <meta> タグを入れます。MDNによると、一部のモバイル端末では、画面よりも広い仮想のビューポートでページを描画し、それを縮小して表示します。たとえば幅640pxの画面で、980pxの仮想ビューポートで描画して縮小することがあります。これを避けるよくある設定が、ビューポートを端末の幅に合わせ、100%のズームで表示する次の指定です（出典：<meta name="viewport"> 属性値｜MDN Web Docs）。

書き方の例：<meta name="viewport" content="width=device-width, initial-scale=1">

MDNは、このviewportメタタグを文書の先頭に常に含める必要がある、としています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。一方で、user-scalable=no でズームを止めると、弱視のユーザーがページを読み取れなくなるとして警告しています（出典：<meta name="viewport"> 属性値｜MDN Web Docs）。

5-2. メディアクエリーは「スマホが基本、広い画面で足す」で書く

メディアクエリーは、画面が特定の幅より大きいかどうかなどを調べて、CSSを選んで適用する仕組みです。レイアウトが切り替わるポイントはブレークポイントと呼ばれます。MDNは、狭い画面向けに単純な1列のレイアウトを作り、画面が十分に広いと分かったら複数列のレイアウトにする方法を「モバイルファースト」デザインと紹介しています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。

書き方の例（スマホは1列、広い画面で2列にする）：

• .items { display: grid; gap: 16px; }（スマホでもPCでも効く基本のスタイル）
• @media (min-width: 48em) { .items { grid-template-columns: 1fr 1fr; } }（画面が広いときだけ2列にする）

5-3. ブレークポイントは端末の幅で決め打ちしない

「スマホは何px、タブレットは何px」と端末の幅から決めると、新しい端末が出るたびに合わなくなります。MDNは、ブレークポイントを個々の端末の絶対サイズではなく、相対的な単位で定義することをベストプラクティスとしてすすめています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。実際には、画面の幅を少しずつ広げながら、レイアウトが崩れ始めるところにブレークポイントを置くと決めやすくなります。

5-4. 画像を枠からはみ出させない（srcset・picture）

画像が画面からはみ出す崩れは、CSSの1行で防げます。MDNは、メディアがコンテナーより大きくならないようにする方法として、img・picture・video に max-width: 100% を指定する例を挙げています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。

書き方の例：img, picture, video { max-width: 100%; }

ただし、大きな画像1枚を縮めて使うと、スマホでは必要以上に大きな画像をダウンロードすることになります。MDNは、同じ画像を端末に合った大きさで出し分ける「解像度切り替え」には <img> の srcset と sizes を、画面の大きさに応じてトリミングの違う別の画像を出し分ける「アートディレクション」には <picture> と <source media="…"> を使う方法を紹介しています（出典：HTML におけるレスポンシブ画像の使用｜MDN Web Docs）。LPで「スマホは縦長のメインビジュアル、PCは横長」としたい場合は <picture> が向いています。

書き方の例：<picture><source media="(min-width: 48em)" srcset="fv-pc.webp"><img src="fv-sp.webp" alt="メインビジュアル"></picture>

5-5. 文字の大きさは、ズームできる形で切り替える

画面の幅に合わせて文字の大きさを変える方法として、MDNはメディアクエリーの中で文字サイズを変える方法と、ビューポート単位（vw）を使う方法を紹介しています。ただし、vw だけで文字の大きさを決めると、ユーザーが文字を拡大できなくなるため、ビューポート単位を単独で使って文字を設定しないように、としています（出典：レスポンシブウェブデザイン｜MDN Web Docs）。文字の大きさの目安は、3-5のLighthouseの基準が使えます。

LPのコーディングを自社で進めるか外注するかの判断は、LPコーディングの外注相場はいくら？費用比較と未経験でも制作できる方法でまとめています。

06｜【別アプローチ】レスポンシブが難しいときの「デバイス別表示」

ここまでの施策をしても「デザインがどうしても崩れる」「スマホとPCでまったく違うレイアウトにしたい」という場合は、レスポンシブではなく「デバイス別表示」という方法もあります。

6-1. デバイス別表示とは

同じURLにアクセスしても、ユーザーの端末（PC／スマホ）を判定して、別のHTMLを表示する方法です。レスポンシブが「同じHTMLを画面幅で変形する」のに対し、デバイス別表示は「端末ごとに別のHTMLに切り替える」方法です。

Google 検索セントラルは、Googleがスマートフォン用クローラーで取得したサイトのモバイル版をインデックス登録とランキングに使うとしたうえで、構成として「レスポンシブ ウェブデザイン」「動的な配信」「別々のURL」の3つを挙げています。デバイス別表示は、このうち「動的な配信」にあたります。Googleが推奨しているのは、実装と保守が最も簡単なレスポンシブ ウェブデザインです。動的な配信では、Vary: User-Agent のHTTPレスポンスヘッダーを使う必要があり、モバイル版にもPC版と同じコンテンツを載せるよう求めています（出典：Mobile-first Indexing Best Practices｜Google 検索セントラル）。

6-2. デバイス別表示のメリット・デメリット

• メリット1：PCとスマホを、それぞれ別のデザインで作れる（複雑なレスポンシブの実装がいらない）
• メリット2：端末ごとに必要なものだけを入れたHTMLを返せる
• メリット3：URLは1つのままにできる
• デメリット1：PC版とスマホ版の2つを管理する必要がある
• デメリット2：端末を判定する仕組みが必要（サーバー側の判定と、検索エンジン向けの Vary: User-Agent ヘッダーなど）

6-3. Squad beyondでのデバイス別表示

Squad beyondでは、PC用とスマホ用のVersion（LPの案）を作り、Versionオプション設定の「デバイス別出し分け」で、スマートフォン・デスクトップ・タブレットの3種類ごとに表示するVersionをオン・オフできます。PC用のVersionは、配信Versionの幅を「100」「%」にします（スマホ用は設定不要）。URLは1つのまま、端末ごとに別のVersionが表示されます（出典：PC/スマホで表示されるページ内容を変更する｜Squad beyond FAQ）。

• デバイス別の出し分けは、STANDARDプラン以上で使える機能です（出典：同上）
• ある端末に対して配信割合が1以上のVersionが設定されていないと、その端末からのアクセスで404エラーになります。変更後は配信URLで確かめます（出典：同上）
• iOS・Androidなど、モバイルのOS別にVersionを出し分ける機能もあります。こちらは有料で、LP高速表示モードの利用時にだけ使えます（出典：モバイルOS別にVersionを出し分けする（有料）｜Squad beyond FAQ）

レスポンシブの実装に時間をかけずに、端末ごとに作り分けたLPで広告を配信したいときの選択肢になります。

07｜公開前後にスマホ表示とCVRを確かめる3つの手順

7-1. 手順1：パソコンで崩れを見る（デバイスモード）

Chromeのデベロッパーツールのデバイスモードを使うと、パソコンの上でスマホの画面の幅に切り替えて表示を確かめられます。画面の幅を少しずつ変えながら、横にはみ出す要素や、重なる要素がないかを見ます。ただし公式ドキュメントは、デバイスモードはモバイル端末での見え方と使い心地の「first-order approximation（第一近似）」だとし、迷ったら実際のモバイル端末でページを動かすのが一番だとしています（出典：Device Mode｜Chrome for Developers）。

7-2. 手順2：実機で表示と操作を確かめる

iPhoneとAndroidの実機で、文字の大きさ、ボタンの押しやすさ、フォームの入力と送信、表示の速さを確かめます。公式ドキュメントは、モバイルのCPUの構造はノートパソコンやデスクトップのCPUとは大きく違う、とも書いています。実機でページを動かしながら、パソコンから調べる「リモートデバッグ」という方法もあります（出典：Device Mode｜Chrome for Developers）。

Squad beyondでは、HTMLエディタのプレビューでスマホ・PC・タブレットの表示を切り替えられ、実機プレビューのURLを確かめたいPCやタブレットで開いて、検証ツールでレスポンシブ対応を確かめる方法も案内されています（出典：HTMLエディタにおいて、スマホ(SP)画面のプレビューを確認したい｜Squad beyond FAQ、PCやタブレットのプレビューを確認したい｜Squad beyond FAQ）。

7-3. 手順3：公開後はデバイス別にCVRを見る

公開後は、スマホとPCのCVRを分けて見ます。GA4では、ディメンション「デバイス カテゴリ」で、ユーザーのアクションが発生したデバイスの種類（パソコン・モバイル・タブレットなど）ごとに分けられます（出典：アナリティクスのディメンションと指標｜アナリティクス ヘルプ）。Squad beyondのデイリーレポートでは、日付・Version・端末を指定して1日単位の数値を見られます（出典：レポートの種類｜Squad beyond FAQ）。

スマホだけCVRが低いときは、03の5つの原因を上から確かめ、1つずつ直して比べます。

08｜よくある失敗3つ

8-1. 失敗1：PCで作ってから、スマホに合わせて直す

• 症状：PCのデザインを先に完成させてからスマホに当てはめると、横にはみ出す要素や小さな文字が残り、スマホで読みにくいLPになる
• 原因：広い画面で並べた要素を、後から狭い画面に押し込もうとしている
• 対策：スマホの1列のレイアウトを基本に作り、画面が広いときだけ列を増やす（5-2のモバイルファースト）
• 回避策：デザインの段階でスマホの画面から作り、スマホで必要な要素を決めてからPC版に広げる

8-2. 失敗2：ファーストビューの画像まで遅延読み込みにする

• 症状：すべての画像に loading="lazy" を付けると、最初の画面のメインビジュアルの表示が遅れ、LCPが悪くなる
• 原因：遅延読み込みは画面の外の画像のための仕組みなのに、表示領域に入る画像にも付けている
• 対策：ファーストビューの画像（LCPの対象になる画像）からは loading="lazy" を外す（施策2）
• 回避策：画像を書き出すときに「ファーストビュー用」と「それより下」を分け、下の画像にだけ属性を付ける運用にする

8-3. 失敗3：エミュレーターだけで確かめて、実機で見ない

• 症状：パソコンのデバイスモードだけで確かめて公開すると、実機での押しにくさや表示の遅さに気づかない
• 原因：デバイスモードは実機での見え方と使い心地の近似にとどまる
• 対策：iPhoneとAndroidの実機で、表示・タップ・フォームの送信までを確かめる（7-2）
• 回避策：公開前のチェック項目に「実機での確認」を入れ、確認した端末とOSを記録しておく

09｜よくある質問（FAQ）

10｜まとめ

LPのレスポンシブ対応は、1つのHTMLのまま、画面の幅に合わせて表示を切り替えられるようにすることです。

• 基本はviewportの指定・モバイルファーストのメディアクエリー・画像の可変化の3点（05）
• そのうえで、画像を軽くする・遅延読み込み・タップ領域・フォーム・ファーストビュー・追従CTA・スマホだけのABテストの7つの施策で、スマホで使いやすくする（04）
• レスポンシブで作り込むのが難しいときは、URLは1つのまま端末ごとにHTMLを切り替えるデバイス別表示も選べる（06）
• 公開前はデバイスモードと実機で確かめ、公開後はデバイス別にCVRを見て直す（07）

スマホとPCで別のLPを用意して、URLは1つのまま出し分けたい方は、Squad beyondのデバイス別出し分け（STANDARDプラン以上）をご検討ください。

　

Squad beyondサービス紹介資料はこちらからダウンロード

｜広告運用ノウハウ公開中！

より詳しく知りたい方は資料をダウンロード！