スマホサイトやLPをデザイン・制作するとき、「ファーストビューのサイズは何pxに設定すればいいの?」「端末によってボタンや画像が見切れてしまう……」と悩んだことはありませんか?
Webアクセスの大半をスマホが占める今、ファーストビューの出来栄えはサイトの成果や離脱率を大きく左右します。しかし、多種多様な端末が存在する現代では、単に数値を決めるだけでなく、ブラウザのアドレスバーやノッチ(切り欠き)の影響まで考慮しなければなりません。曖昧な数値や不適切なCSSプロパティを使ってしまうと、重要なキャッチコピーや申し込みボタンが画面外に隠れてしまい、大きな機会損失につながってしまうことも……。
そこで本記事では、Web制作の現場に10年以上携わるエンジニア視点から、スマホファーストビューの「正しい基準サイズ」と「実務で失敗しないデザイン・実装ノウハウ」を分かりやすく解説します!
この記事を読めば、もうサイズ選びや表示崩れで迷うことはありません。デザインカンプの作成から実際のコーディングまで、自信を持って進められるようになりますので、ぜひ参考にしてみてください。
業界最安級、実績・口コミ多数!仕事に繋がるWebスキルを身につけるなら『デイトラ』スマホのファーストビューサイズは何px?まず押さえたい目安

スマホのファーストビュー(スクロールせずに最初に表示される画面領域)のサイズは、幅375pxまたは390px、高さ750px前後を基準としてデザイン・制作を行うのが現代のWeb制作における一般的な結論です。ただし、高さは閲覧する端末の画面比率やブラウザのUI(アドレスバーやツールバー)によって常に変動するため、固定の「絶対的な正解数値」が存在するわけではありません。デザインカンプ作成時と実際のCSS実装時で、可変前提の設計ルールを理解しておくことが重要です。
【図解案:スマホ画面におけるファーストビュー領域の構造図。画面全体(端末の全高)の中から、上部ステータスバー・アドレスバー、下部ナビゲーションバーを除いた「実質表示領域(ファーストビュー)」がどの範囲かを矢印と数値(幅375〜390px / 高さ750px前後)で分かりやすく示したイラスト】
スマホのファーストビューは幅375〜390px前後を基準に考える
スマホのファーストビューを設計する際、横幅はCSSピクセル(論理解像度)で「375px」または「390px」を基準にするのが基本です。
かつてはiPhone 6〜8やiPhone SE(第2・第3世代)、iPhone 12/13 miniなどの標準サイズである「375px」が圧倒的なシェアを誇り、Web制作のデファクトスタンダード(業界標準)とされていました。しかし近年では、iPhone 12〜16シリーズの標準モデルで採用されている「390px」や「393px」のシェアが急増しています。
実務でデザインカンプ(Figma、Adobe XD、Photoshopなど)を作成する場合、ターゲットユーザーやブレイクポイントの設計方針に合わせて次のように選びます。
- 幅375pxを基準にする場合: iPhone SEなどの小型端末を含む幅広い画面サイズで「表示崩れ」や「意図しないテキストの折り返し」を防ぎたい安全策重視のアプローチ。
- 幅390px(または393px)を基準にする場合: 最新のiPhone標準端末にジャストフィットさせ、現代の主流画面サイズで余白感やフォントの視認性を最適化するアプローチ。
制作現場では、あらかじめ「375px」の最小幅でレイアウトが破綻しないことを確認したうえで、390px〜430px程度の大型画面へ拡大されても自然に見えるレスポンシブな設計を行うのが最も確実です。
高さ750pxは固定の正解ではなくデザイン基準として使う
デザイン制作の現場で「ファーストビューの高さは750px」という数値がよく使われますが、これは特定の画面で固定表示される絶対値ではなく、デザインカンプ作成時の「画面内要素配置の安全域(安全圏目安)」として使われます。
「750px」という数値が使われる背景には、2つの要素が関係しています。
- 物理ピクセル(@2x Retina表示)との混同: かつてのiPhone 6/7/8などの画面解像度は「横750px × 縦1,334px(物理ピクセル)」でした。CSSピクセル換算では「横375px × 縦667px」となります。Web制作用語の「750px」が「横幅のRetina用画像解像度(375px × 2)」を指すのか、「縦方向のファーストビュー高さ」を指すのか混同されやすい点に注意が必要です。
- 現代の縦長スマホにおける実質表示高さ: 現代のiPhone 14/15/16(画面高さ844〜852px)などでブラウザを開いた際、上部のアドレスバーと下部のツールバーを除いた「実際にコンテンツが表示される高さ」が、およそ700px〜780px程度になります。この平均値として「750px」がデザインのアートボード上の目安枠として定着しました。
実務でよくある失敗例
高さの概念を誤解し、CSSで .hero { height: 750px; } と固定値を指定してしまうケースです。これを行うと、画面の小さい端末(iPhone SEなど、実質高さ600px前後)では重要なCTAボタンやキャッチコピーが画面下に食み出して見切れ、逆に縦長の大画面端末では下に無駄な余白が生じてしまいます。
高さ750pxはあくまで「この750pxの範囲内にメインコピーと重要な要素を入れておけば、大半のスマホでスクロールせずに目に入る」というガイドライン(デザイン枠)として活用しましょう。
ファーストビューのサイズを決めるときに見るポイント
ファーストビューのサイズや表示要素の可範囲を決定する際は、単に数値を当てはめるだけでなく、以下の4つのポイントを総合的に判断します。
| 判断ポイント | 見るべき内容と実務での影響 |
|---|---|
| 1. ターゲット端末の比率 | ユーザーの主力端末がiPhone SE(画面高さ低め)か、最新iPhone/Android(縦長)かによって表示範囲が変わる。 |
| 2. ブラウザUIの影響 | SafariやChromeのアドレスバー・ツールバーにより、画面上下の約90〜130pxは常時隠れる前提で設計する。 |
| 3. メインビジュアルの重要領域 | 人物の顔や商品の中心など、画面サイズが伸び縮みしても絶対に見切れては困る「重要エリア」を画面中央付近に配置する。 |
| 4. CTA(行動喚起)の位置 | 初回表示時(スクロール前)に購入・問い合わせボタン等のCTAを完全表示させるか、あえて半分見せてスクロールを促すか。 |
特に実務で意識したいのは「スクロールを誘発するチラ見せ(Scroll Trigger)」の設計です。
ファーストビューの枠内にすべての要素をぴったり収めすぎると、ユーザーが「ここでページが終わっている」と錯覚(フォールス・フッター現象)し、スクロールせずに離脱してしまうリスクがあります。あえて要素の下端や次のセクションの見出しを画面最下部に数10px分だけ見せる(チラ見せする)ことで、直感的・自然に下方向へスクロールさせる視線誘導が可能になります。
TVCMで話題の【ココナラ】無料会員登録はこちらスマホの画面サイズによってファーストビューの高さは変わる

スマホの画面サイズや機種、ブラウザのUI表示によって、ファーストビューとして実際に見える「高さ」は大きく変わります。同じデザインカンプで作られていても、表示端末の画面比率(縦長化)やアドレスバーの出現状況により可視領域が上下100px以上増減するため、端末ごとの表示の違いを踏まえた設計が不可欠です。
375px・390px・414px前後で見え方を確認する
スマホの画面幅は大きく分けて「375px前後(小型・標準)」「390px〜400px(現代の主流モデル)」「414px〜430px(大型モデル)」の3つの帯域に分かれます。デザイン制作時やコーディング後の実機チェックでは、これら代表的な幅での見え方(フォントの改行位置、要素の詰まり具合、縦方向の表示領域)を確認することが重要です。
以下に、主要端末のCSSビューポート(論理解像度)と物理解像度、デバイスピクセル比(dpr)の一覧表を整理しました。
| 端末区分・代表モデル | CSSビューポート幅×高さ(目安) | 物理解像度(画面パネル) | デバイスピクセル比 (dpr) | 特徴と見え方のポイント |
|---|---|---|---|---|
| 小型端末 iPhone SE (第3世代) | 375 × 667 px | 750 × 1334 px | 2x | 画面高さが低いため、縦長コンテンツは下部が見切れやすい。 |
| 主流端末 iPhone 15 / 16 | 393 × 852 px | 1179 × 2556 px | 3x | 現在最も標準的なアスペクト比(約19.5:9)。バランスが良い。 |
| 主流Android Galaxy S24 / S25 | 360 × 780 px | 1080 × 2340 px | 3x | 横幅がやや狭く(360px)、テキストが改行されやすいため注意。 |
| 大型端末 iPhone 16 Plus / Pro Max | 430 × 932 px | 1290 × 2796 px | 3x | 大画面のためファーストビュー内に多くの情報が入る。 |
| 大型Android Google Pixel 8 / 9 | 393〜412 × 874〜915 px(※設定により変動) | 1080 × 2424 px | 2.75x〜3x | OSの表示サイズ設定(文字・表示スケール)によりviewport幅が変化する。 |
※各端末の数値は標準ブラウザ表示時の目安値です。OSのアップデートやユーザーの表示スケール設定により変動する場合があります。
実務視点のアドバイス
制作時の検証では、特定の1端末(例:自身の所有するiPhone 16など)だけで確認して安心してしまう失敗が頻発します。横幅が狭い「Galaxyの360px」や高さを稼げない「iPhone SEの667px」など、制約が最も厳しい端末環境でもレイアウトが崩れず、主要メッセージがファーストビュー内に留まるかをブラウザのデベロッパーツール等で必ず横断確認しましょう。
端末の画面解像度とCSSのviewport幅は分けて考える
スマホの画面スペックに記載されている「物理解像度(例: 1179 × 2556 px)」と、Web制作で指定する「CSSのviewport幅(例: 393 × 852 px)」は明確に別物です。Webデザインやコーディングを行う際は、必ず「CSSのviewport幅」を基準にして計算します。
この仕組みを理解するためには、以下の3つの定義を整理しておく必要があります。
- 物理解像度(Hardware Resolution): スマホの画面パネルに実際に敷き詰められている微細なLED素子(物理ドット)の総数。
- CSSのviewport(CSS Pixels): Webブラウザが画面レイアウトやメディアクエリを計算する際の論理的なサイズ。
- devicePixelRatio(dpr / デバイスピクセル比): 1つのCSSピクセルを表示するために、縦横それぞれ何個の物理ドットを使っているかを示す倍率。

比喩で例えるなら、物理解像度は「画用紙の目の細かさ」であり、CSSのviewportは「レイアウトを決める標準の定規」です。
例えばiPhone 16のdprは「3」のため、1CSSピクセルに対して縦横それぞれ3倍(面積比で9倍)の物理ドットを使って、高精細で滑らかな文字や画像を描画しています。
そのため、カンプ作成やCSSのメディアクエリ(@media (max-width: 768px)など)で画面幅を指定する際は、物理解像度の「1179px」ではなく、常にCSSピクセルの「393px」を基準として扱います。
ブラウザUIやセーフエリアを考慮して見切れを防ぐ
スマホでWebサイトを閲覧するとき、画面全体(全高)がすべてWebコンテンツの表示エリアになるわけではありません。ブラウザ上下に常駐する「ブラウザUI」や、ノッチ(切り欠き)・Dynamic Island(ダイナミックアイランド)・角丸画面による「セーフエリア」によって、実際の表示可能領域は大幅に削られます。
ファーストビューの高さが見切れる主な原因は、次の3つのUI要素です。
- 上部ナビゲーション・ステータスバー(約40〜54px): 時刻、バッテリー残量表示、ブラウザのアドレスバー(URL入力欄)などが占有する領域。
- 下部ツールバー・ホームインジケーター(約34〜83px): Safariのブックマークや戻るボタンのバー、画面下部のスワイプ用ホームバー領域。スクロールの開始に伴い小さくなったり隠れたりする可変挙動を持ちます。
- ノッチ・Dynamic Islandおよび角丸エリア(セーフエリア): インカメラやセンサー類を避けるための保護領域。画面の最上部・最下部に要素を密着させすぎると重なって隠れてしまいます。
実際の可視域の計算イメージ(iPhone 16の例)
- 端末の全画面高さ(CSSピクセル):852px
- 上部UI + ステータスバー:約54px
- 下部ツールバー(初期読み込み時):約83px
- 実質的なファーストビュー高さ:852px – (54px + 83px) = 約715px
このように、画面高さが852pxある端末でも、初回読み込み時の実質ファーストビュー高さは「約715px」まで縮小します。
実務でのよくある失敗例として、画面下部に固定配置した「問い合わせボタン(Floating CTA)」が、スマホ下部のホームインジケーターバーやブラウザのツールバーと重なって誤タップを招いたり、押しづらくなったりするケースがあります。デザイン時・実装時には、これらのUI領域を考慮した安全域(Safe Area)の確保が必須です。
CSSでスマホのファーストビューを実装する方法
スマホのファーストビューを画面いっぱいに表示させるCSS実装では、従来の height: 100vh だけに頼るとアドレスバーによる「要素の見切れ」が発生します。現代のフロントエンド制作では、新しいビューポート単位である svh や dvh を適切に使い分け、さらに env(safe-area-inset-*) を組み合わせてセーフエリア(ノッチやホームバー)を考慮した実装を行うのが標準的なベストプラクティスです。

height: 100vhだけに頼らないほうがよい理由
ファーストビューのメインビジュアルを「スマホ画面いっぱいに表示させたい」と考え、CSSで height: 100vh と指定する手法はかつて多用されていましたが、現在のモバイルブラウザ環境では大きな問題を引き起こします。
その理由は、モバイル版のSafari(iOS)やChrome(Android)における 100vh の仕様にあります。仕様上、100vh は「ブラウザのアドレスバーやツールバーが最も小さくなった状態(または隠れた状態)の画面高さ」を基準として計算されます。
そのため、ページを開いた初期状態(アドレスバーや下部ツールバーが全表示されている状態)で height: 100vh を適用すると、要素の高さが実際の表示領域よりも大きくなり、画面下部のコンテンツやCTAボタンがツールバーの裏側に隠れて見切れてしまうのです。
実務でよく起きる「100vh問題」の失敗例
ランディングページ(LP)で画面最下部に「今すぐ申し込む」という重要なCTAボタンを配置していた際、height: 100vh で実装していたために初期表示でボタンが下部ツールバーの陰に完全に隠れてしまいました。ユーザーがスクロールしないとボタンが存在することすら気づけず、コンバージョン率が大幅に低下したというトラブルが制作現場で頻出しました。
このように、画面内にコンテンツを完璧に収めたいファーストビューの実装において、単一の 100vh 指定のみで完結させるのは危険です。
svh・dvh・lvhを使い分ける
「100vh問題」を解決するために仕様化されたのが、CSS Values and Units Module Level 4で定義された新しいビューポート単位(svh / dvh / lvh)です。
これらの単位を理解し、プロジェクトの目的に応じて正しく選択することが重要です。
| 単位 | 名称 | 仕組みと特徴 | アドレスバー表示時の挙動 | スクロール時の挙動 | 推奨ユースケース |
|---|---|---|---|---|---|
svh | Small Viewport Height | UI(ツールバー等)が最大表示されている状態の最小画面高さを基準とする | 画面内にぴったり収まる(見切れが発生しない) | 高さは固定されたまま変化しない | ファーストビューの全画面表示(最推奨) |
dvh | Dynamic Viewport Height | ツールバーの伸縮に合わせて動的にリアルタイム変化する画面高さ | 初期状態では画面内にぴったり収まる | アドレスバーが縮むと追従して伸びる | 画面に連動させたいインタラクティブな表現 |
lvh | Large Viewport Height | UI(ツールバー等)が最小表示(隠れた状態)の最大画面高さを基準とする | 下部が見切れる(従来の 100vh とほぼ同等) | 画面いっぱいに広がる | スクロール後の背景全画面固定など |
対応ブラウザの状況とフォールバック
svh / dvh / lvh は、iOS Safari 15.4+、Android Chrome 108+、Firefox 101+ 等の主要ブラウザで幅広くサポートされています。現代の制作環境では全主要モバイルブラウザで標準対応していますが、安全策として古い環境向けに従来の 100vh を直前に記述する「フォールバック設計」を行っておくのが実務上の作法です。
実務での単位の選び方(判断基準)
- 迷ったら
100svh(またはmin-height: 100svh)を選ぶ: スクロール時のアドレスバー出入りに伴う画面のガタつき(再計算によるレイアウトシフト)が発生しないため、最も安定したユーザー体験を提供できます。 dvhを使う際の注意点: スクロールに合わせて高さを動的に再計算するため、背景画像のリサイズ処理や子要素の高さ再計算が走り、古い端末ではスクロール動作がカタついたりチラつき(リペイント)の原因になる場合があります。
env()でsafe areaを考慮する実装例
iPhoneなどの端末に存在するノッチ(画面上部のカメラ切り欠き)、Dynamic Island、画面下のバー(ホームインジケーター)や角丸画面に対応するには、env(safe-area-inset-*) 関数を使用したセーフエリア調整が必要です。
これを行わないと、要素が画面縁の角丸で切れたり、ホームバーとボタンが被ってタップできなくなるトラブルが発生します。
セーフエリア対応の基本設定手順
- HTMLの
<meta name="viewport">にviewport-fit=coverを追記する。 - CSSで
env(safe-area-inset-top)やenv(safe-area-inset-bottom)を使い、余白(paddingやmargin)を動的に付与する。
コピペで使える全画面ファーストビューの実装コード例
以下は、見切れを防ぎつつセーフエリアとフォールバックに完全対応した、そのまま実務で使えるコンポーネントコードです。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<!-- viewport-fit=cover を指定して画面全域(ノッチ裏含む)までの描画を許可する -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
<title>ファーストビュー実装例</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<!-- ファーストビューのメインヒーローセクション -->
<section class="hero">
<div class="hero-container">
<h1 class="hero-title">感動を届ける<br>Webデザインの新しい標準</h1>
<p class="hero-lead">スマホ最適化でユーザー離脱を防ぎ、成果を最大化します。</p>
<!-- 初回表示で絶対に見切れさせない重要なCTA -->
<div class="hero-cta">
<a href="#contact" class="btn-primary">無料相談をはじめる</a>
</div>
</div>
</section>
</body>
</html>
/* style.css */
/* ルート変数の定義 */
:root {
--color-primary: #0066ff;
--color-text: #333333;
}
/* ボックスモデルの初期化 */
*, *::before, *::after {
box-sizing: border-box;
margin: 0;
padding: 0;
}
/* メインヒーローセクションの実装 */
.hero {
width: 100%;
/* --- 1. 高さ設定(フォールバック付き) --- */
/* 未対応ブラウザ向けのフォールバック */
min-height: 100vh;
/* 現代の標準:ブラウザUI表示時でも見切れない最小ビューポート高さを指定 */
min-height: 100svh;
/* --- 2. セーフエリアと余白の考慮 --- */
/* 上下左右のセーフエリア(ノッチ・ホームバー)を確保。標準余白20pxに安全域を加算 */
padding-top: calc(20px + env(safe-area-inset-top));
padding-bottom: calc(20px + env(safe-area-inset-bottom));
padding-left: calc(16px + env(safe-area-inset-left));
padding-right: calc(16px + env(safe-area-inset-right));
/* Flexboxでコンテンツを上下左右の中央、または均等配置 */
display: flex;
flex-direction: column;
justify-content: center;
align-items: center;
/* 背景ビジュアル設定 */
background-image: linear-gradient(rgba(0, 0, 0, 0.4), rgba(0, 0, 0, 0.4)), url('hero-bg.jpg');
background-size: cover;
background-position: center;
color: #ffffff;
text-align: center;
}
.hero-container {
width: 100%;
max-width: 600px;
display: flex;
flex-direction: column;
align-items: center;
gap: 20px;
}
.hero-title {
font-size: clamp(1.5rem, 5vw, 2.25rem); /* 画面幅に応じて可変するフォントサイズ */
font-weight: 700;
line-height: 1.3;
}
.hero-lead {
font-size: clamp(0.875rem, 3vw, 1.125rem);
opacity: 0.9;
line-height: 1.6;
}
.hero-cta {
margin-top: 10px;
width: 100%;
max-width: 320px;
}
.btn-primary {
display: flex;
justify-content: center;
align-items: center;
width: 100%;
/* タップ領域(アクセシビリティ)を意識し48px以上の高さを確保 */
min-height: 52px;
padding: 12px 24px;
background-color: var(--color-primary);
color: #ffffff;
text-decoration: none;
font-weight: bold;
border-radius: 50px;
box-shadow: 0 4px 12px rgba(0, 102, 255, 0.3);
transition: transform 0.2s ease, background-color 0.2s ease;
}
/* タッチ操作時の応答性を向上させるプロパティ */
.btn-primary:active {
transform: scale(0.98);
}
このコードでは、min-height: 100svh によりブラウザのアドレスバーが表示された状態でも絶対に要素が突き抜けないように制御しつつ、env(safe-area-inset-bottom) によってiPhoneのホームバーとボタンが重なる事故を完全に防いでいます。
スマホのファーストビュー画像サイズとアスペクト比
スマホのファーストビュー画像(メインビジュアル)のサイズは、表示幅の2〜3倍の解像度(横幅750〜1125px前後)で作成し、ファイル容量を100〜200KB以下に軽量化するのが基本です。また、画面いっぱいに表示する縦長スマホでは3:4(縦長)や4:3(やや縦長)のアスペクト比が相性良く収まります。画像の「解像度」「アスペクト比」「CSSによるトリミング制御」の3つをセットで設計することが見切れや表示遅延の防止につながります。

メインビジュアルの画像サイズはどう決める?
メインビジュアルの画像サイズ(ピクセル数)を決定する際は、「ディスプレイの高精細表示(Retina対応)」と「ページ読み込み速度(LCP対策)」のバランスを取ることが最重要です。
1. 解像度は表示サイズの「2倍〜3倍」で書き出す
現在のスマホはほとんどがデバイスピクセル比(dpr)2〜3のディスプレイを搭載しています。そのため、CSSピクセル幅で375〜430px程度で表示される画像であっても、1倍サイズの画像ではぼやけて見えてしまいます。
- 標準的な書き出しサイズ: 横幅 750px 〜 1,125px(375px表示の2〜3倍)
- 縦幅の目安: デザインのアスペクト比に合わせて1,000px 〜 1,500px前後
高解像度ディスプレイ向けに3倍(1,125px幅)で用意しておけば、最新のiPhoneや高解像度Android端末でもクッキリとした美しいビジュアルを提供できます。
2. 次世代画像フォーマット(WebP / AVIF)による軽量化
解像度を2〜3倍に上げると画像ファイル容量が増大し、ページの表示スピードが低下します。JPEGやPNGのまま書き出すのではなく、WebP(ウェッピー)やさらに圧縮率の高いAVIF(エエイフ)形式を活用します。
- 容量の目標値: メインビジュアル1枚あたり 100KB〜200KB以内(最大でも300KB以下)
- 圧縮率の設定: 80〜85%前後の画質設定(目視で劣化が分からないレベルで大幅に軽量化可能)
3. LCP(最大コンテンツの描画)とパフォーマンス最適化
ファーストビューの画像は、Googleが掲げるWebサイトの表示速度指標「Core Web Vitals」の LCP(Largest Contentful Paint) に直接影響します。
ファーストビュー画像には、絶対に遅延読み込み(loading="lazy")を指定してはいけません。初期読み込みを最優先させるため、以下のようなHTML記述を行います。
loading="eager"を明示(またはloading属性自体を省略)fetchpriority="high"を付与し、ブラウザに最優先でダウンロードさせる<head>内で<link rel="preload">を使って画像を事前読み込みさせる
16:9・4:3・3:4などのアスペクト比の使い分け
スマホの画面は縦長(アスペクト比 約19.5:9)であるため、PCサイトで定番の横長画像(16:9など)をそのままスマホで表示させると、画面に対して画像が小さく見えたり、上下に無駄な余白が生じたりします。
ファーストビューで伝えたい情報やデザインの目的に応じて、最適なアスペクト比を選択しましょう。
| アスペクト比 | 形状の特徴 | 主な用途・向いているコンテンツ | スマホファーストビューでの見え方とメリット |
|---|---|---|---|
| 3 : 4 | 縦長 | 人物写真、ファッション、個人のブランディング、スマホ特化LP | 画面の縦領域を大きく占有でき、スマホ画面との親和性が抜群。被写体をダイナミックに見せられる。 |
| 4 : 3 | やや横長 | サービス紹介、コーポレートサイト、複数要素を配置するヒーローエリア | 縦横のバランスが良く、画像の下部にキャッチコピーやボタンなどのテキスト要素を配置しやすい。 |
| 1 : 1 | 正方形 | 商品単体(ECサイト)、Instagram連動デザイン、各種サービス | 画面の中央に収まりが良く、上下にテキストや実績数値などの補足情報をゆったり配置できる。 |
| 16 : 9 | 横長 | 横長の風景写真、動画コンテンツ(YouTube埋め込み等)、PC共通デザイン | スマホ縦画面では高さが非常に低くなるため、単体表示だとインパクトが弱くなりやすい点に注意が必要。 |
実務での選び方の指針
ファーストビューの画面内に「画像だけでなく、大きなキャッチコピーとCTAボタンもすべて収めたい」場合は、画像を縦に伸ばしすぎない 4:3 や 1:1 が適しています。逆に「ビジュアルのインパクトを最優先し、背景としてダイナミックに見せたい」場合は 3:4(縦長) を採用するのが効果的です。
object-fit・background-sizeで画像の見切れを防ぐ
スマホの画面幅や高さを変更した際、画像内の重要な被写体(人物の顔、商品の中心、ロゴなど)が途中で切り取られて見切れてしまう失敗は、実務で非常によく発生します。
この見切れを防ぐには、CSSの object-fit(<img> タグの場合)または background-size(CSS背景画像の場合)を適切に制御します。
1. <img> タグを使うか CSS background-image を使うか?
現代のWeb制作およびSEO・アクセシビリティの観点からは、ファーストビューのメインビジュアルには <img> タグ(または <picture> タグ)を使用するのが推奨 されます。
<img>タグを使用するメリット: HTML内にalt属性で適切な画像説明を記述でき、srcsetや<picture>を使ったレスポンシブな画像切り替えやfetchpriority="high"によるLCP最適化が容易。- CSS背景画像(
background-image)を使うケース: 画像の上に複雑なHTML要素(テキストやボタン)を自由に重ね合わせたい場合。
2. 被写体の見切れを防ぐ object-position / background-position
画像を表示領域に合わせて拡大縮小・トリミング表示する際、トリミングの基準点(支点)を指定しないと、デフォルトでは「画像の中央(center)」を基準に端がカットされます。
人物の顔が画像の上部にある場合、中央基準だと「スマホで見たときに人物の首から上(顔)が切り取られて見えない」という事故が起きます。これを防ぐために、画像内の重要部分の位置(top, bottom, left, right や 50% 20% 等の数値)を明示します。
被写体を絶対に見切れさせないCSS実装コード例
以下は、<picture> タグを使って端末サイズごとに最適な画像(PC用/スマホ用)を切り替えつつ、CSSの object-fit と object-position で見切れを完全に防ぐコピペ可能なコード例です。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>メインビジュアル画像実装例</title>
<!-- LCP最適化:ファーストビュー画像を事前読み込み -->
<link rel="preload" as="image" href="hero-sp.webp" media="(max-width: 767px)" type="image/webp">
<link rel="stylesheet" href="style.css">
</head>
<body>
<header class="main-visual">
<picture>
<!-- 768px以上のタブレット・PC向け横長画像 -->
<source media="(min-width: 768px)" srcset="hero-pc.webp" type="image/webp">
<!-- スマホ向け縦長・軽量化画像(WebP) -->
<img
src="hero-sp.webp"
alt="最新のWebデザインで事業成長をサポートするメインビジュアル"
width="1125"
height="1500"
fetchpriority="high"
class="main-visual-img"
>
</picture>
<!-- 画像の上に重ねるテキストコンテンツ -->
<div class="main-visual-content">
<h1 class="title">成果に繋がる<br>スマホファースト設計</h1>
</div>
</header>
</body>
</html>
/* style.css */
.main-visual {
position: relative;
width: 100%;
/* スマホのファーストビューに適した高さを指定 */
height: 70vh;
min-height: 480px;
max-height: 750px;
overflow: hidden;
background-color: #f0f0f0; /* 画像読み込み前のチラつきを防ぐ背景色 */
}
.main-visual-img {
width: 100%;
height: 100%;
/* --- 1. アスペクト比を維持して枠いっぱいにトリミング表示 --- */
object-fit: cover;
/* --- 2. 被写体の見切れ防止(基準位置の指定) --- */
/* 人物の顔や主要な被写体が「上部」にある場合、中央ではなく上端を優先して維持 */
object-position: center top;
display: block;
}
/* 画像上に重ねるテキストエリアの配置 */
.main-visual-content {
position: absolute;
bottom: 0;
left: 0;
width: 100%;
padding: 32px 20px;
/* 下部にグラデーションを敷いて文字の可読性(コントラスト)を高める */
background: linear-gradient(to top, rgba(0,0,0,0.7) 0%, rgba(0,0,0,0) 100%);
color: #ffffff;
}
.main-visual-content .title {
font-size: 1.5rem;
font-weight: bold;
line-height: 1.4;
}
実務での失敗例と改善のアドバイス
デザイン制作時、画像の中に「キャッチコピーの文字」を直接焼き込んで作成してしまうケースがあります。これを行うと、スマホの画面幅が変わって画像がトリミングされた際に、文字の一部がカットされて読めなくなったり、縮小されて極小化し読めなくなるトラブルが発生します。
実務では、画像自体には背景や写真のみを配置し、キャッチコピーやボタンは必ずHTML/CSSのテキスト要素として画像の上にレイヤーで重ねる構成にしましょう。
まずは無料体験・説明会に参加を♪【Winスクール】LP・コーポレートサイトでファーストビューの高さは変えるべき?
結論から言うと、Webサイトの目的に応じてファーストビューの高さ設定とレイアウトの設計思想は明確に変えるべきです。コンバージョン(購入・問い合わせ等)の獲得を最重要目的とするランディングページ(LP)では、スクロール不要で行動を起こせる「ファーストビュー完結型・CTA重視」の設計が求められます。一方、企業の信頼性構築や事業理解を目的とするコーポレートサイトでは、画面上の高さにとらわれず「情報量・ナビゲーション・余白感」を優先した設計が適しています。

LPはCTAを含めて最初の画面を設計する
ランディングページ(LP)に訪れるユーザーは、広告や検索から特定の課題意識を持って流入してきます。そのため、ページを開いた瞬間の数秒間で「自分に関係があるか」「信頼できるか」を瞬時に判断し、興味を持てなければすぐに離脱してしまいます。
LPのファーストビュー設計では、次の4要素を初期表示領域内に確実に収めるのが基本ルールです。
- ターゲットを惹きつけるメインキャッチコピー(ベネフィットの明確化)
- 直感的に価値が伝わるメインビジュアル(商品・人物写真など)
- 即座に行動を起こせるCTAボタン(「無料体験」「資料請求」など)
- 下にコンテンツが続くことを伝える「ちら見せ(スクロール誘導)」
ちら見せ(Scroll Trigger)の設計テクニック
LPでよくある失敗が、ファーストビューを画面枠内に完璧に収めすぎた結果、ユーザーが「ここでページが終わっている」と錯覚してスクロールせずに去ってしまう現象(フォールス・フッター)です。
これを防ぐため、次セクションの画像やテキストの上端(10〜30px程度)をファーストビューの最下部に意図的に割り込ませたり、スクロールを促す下向き矢印(「Scroll Down」アニメーション)を配置したりして、自然な下方向への視線誘導を組み込みます。
実務視点でのアドバイス
広告運用を行っているLPの場合、初回表示時にCTAボタンが画面内に入っているかどうかでCVR(コンバージョン率)が10〜30%近く変わることがあります。スマホの画面高さが低い端末(iPhone SE等)であっても、キャッチコピーとCTAボタンがスクロールなしで同時表示されるレイアウト(または画面下部への追従型Float CTAの併用)を最優先で設計しましょう。
コーポレートサイトは高さより情報量を優先する
コーポレートサイト(企業サイト)のファーストビューに求められるのは、即座のコンバージョン誘導ではなく「企業のブランド価値の伝達」「信頼感の訴求」「目的のページへのスムーズな誘導」です。
そのため、LPのようにCTAボタンを前面に押し出す必要はなく、無理に要素を1画面内に詰め込む必要もありません。
コーポレートサイトのファーストビューでは、以下のポイントを重視して設計します。
- グローバルナビゲーションのアクセシビリティ: ハンバーガーメニューや主要導線(事業内容、会社概要、採用情報など)が見やすくタップしやすい位置にあるか。
- ブランドの世界観を伝える美しいビジュアルと余白: 文字詰まりを起こさず、洗練された印象を与える十分なホワイトスペース(余白)を確保する。
- 企業の姿勢を示すコピー: 企業のパーパス(存在意義)やビジョンを伝える短く力強いステートメント。
コーポレートサイトの場合、高さを特定のピクセル数(750pxなど)に無理やり抑え込もうとすると、フォントサイズや余白が窮屈になり、企業の印象を損ねる原因になります。高さの数値に縛られず、コンテンツとしての美しさと視認性を優先させましょう。
「100vh」か固定高さかを目的に応じて決める
CSSでファーストビューの高さを指定する際、実務では「100vh(全画面表示)」「固定高さ(px指定)」「min-height(可変最小高さ)」の3つのアプローチが存在します。
プロジェクトの目的やデザイン仕様に合わせて、以下の選択基準を参考にプロパティを選定してください。
| 指定方法 | 主な仕様と挙動 | メリット | デメリット・注意点 | 推奨されるサイト種別・用途 |
|---|---|---|---|---|
min-height (可変最小高さ)例: min-height: 100svh; または min-height: 520px; | 最小限の高さを確保しつつ、コンテンツが増えた場合は自動で伸びる | 文字あふれや要素の突き抜け(オーバーフロー)が発生せず、最も事故が少ない(最推奨) | 高さが端末によって可変するため、絶対的な一画面レイアウトにはならない | すべてのサイトで汎用的に推奨(特にテキスト量が多いLPやコーポレートサイト) |
100vh / 100svh (全画面固定)例: height: 100svh; | 端末の画面表示エリアいっぱいにぴったり固定表示する | 画面全体を使ったダイナミックで没入感のある演出(インパクト重視)ができる | スマホ画面が極小の場合、中のテキストやボタンが上下に突き出て見切れるリスクがある | ブランドグロース型の特設サイト 写真・動画を主役にするコーポレートヒーロー |
| 固定高さ (px指定) 例: height: 600px; | 端末の高さに関わらず常に一定の高さ(px)に固定する | デザイナーの意図通りの縦横比やトリミング表示を厳密に再現しやすい | 縦長の大型スマホでは画面下に無駄な空きスペースが生じ、小型スマホでは見切れる | ヘッダー下のコンパクトなメインビジュアル 下層ページ(下層ヒーローエリア) |
フロントエンドエンジニアとしての実装結論
実務で最もトラブルが少なく安全な構成は、min-height と svh を組み合わせた記述です。
.hero-section {
width: 100%;
/* 画面いっぱいに広げつつ、画面が小さすぎる場合は最低500pxを確保して見切れを防ぐ */
min-height: 100svh;
/* 万が一フォントが大きくなったり要素が増えても枠を破綻させない */
height: auto;
}
この実装にしておけば、大画面スマホではスタイリッシュな全画面表示を提供しつつ、画面高さの低い特殊な端末でもコンテンツが潰れたり見切れたりする悲劇を完璧に回避できます。
業界最安級、実績・口コミ多数!仕事に繋がるWebスキルを身につけるなら『デイトラ』よくある質問
-
スマホのファーストビューは750pxで作ればいい?
-
結論: デザインカンプの配置安全ゾーン(目安枠)として「750px」を使うのは適切ですが、CSSで
height: 750pxと固定指定するのは避けてください。理由: 実際に見えるファーストビューの高さは、閲覧端末の画面サイズやブラウザのアドレスバー・ツールバーの表示状況によって約600px〜800pxの間で常に変動するからです。
補足: 「750px」はあくまで主要なキャッチコピーやボタンをスクロール前に収めるためのガイドラインとして扱い、実装時は
min-height: 100svhなどを活用した可変設計を行いましょう。
-
スマホサイトの幅は375pxと390pxのどちらを基準にすればいい?
-
結論: 小型端末での崩れを防ぐ安全策なら「375px」、最新iPhoneの主流に合わせるなら「390px(または393px)」を基準にします。
理由: 375pxはiPhone SEや旧世代モデルなどの最小幅を確実にカバーでき、390px/393pxはiPhone 12〜16シリーズの標準ディスプレイサイズにジャストフィットするためです。
補足: 迷った場合は「375px」のアートボードでデザインを作成し、画面幅が390px〜430pxへ広がってもレイアウトが破綻しないようレスポンシブに調整するのが最も堅実です。
-
ファーストビューは100vhとdvhのどちらを使えばいい?
-
結論: 従来の
100vhの単独指定は避け、要素の見切れを防ぐ100svh(または100dvh)を使用するのが現代のベストプラクティスです。理由: 従来の
100vhはツールバーが隠れた状態の高さで計算されるため、初期表示時に画面下部のCTAボタンやテキストがツールバーの下に隠れてしまう「100vh問題」が発生するからです。補足: アドレスバーの伸縮に伴う画面のガタつき(レイアウトシフト)を防ぎたいファーストビューでは、最小表示域で安定する
min-height: 100svhの指定が実務で最も推奨されます。
まとめ
スマートフォンにおけるファーストビュー(スクロールせずに最初に表示される領域)は、Webサイトの第一印象とユーザーの離脱率・コンバージョン率(CVR)を大きく左右する最重要エリアです。
スマホのファーストビューサイズを設計・実装する際の要点は、以下の4点に集約されます。
- 標準サイズの考え方: デザインカンプは横幅 375px または 390px を基準とし、高さは 750px 前後 を「スクロール前に見せたい要素の安全範囲(ガイドライン)」として設定する。
- 画面解像度とビューポートの区別: 物理解像度(例: 1179px)ではなく、レイアウトの基準となる CSSのviewport幅(例: 393px) で設計・開発を行う。
- 100vh問題とCSS実装:
height: 100vhによるアドレスバーでの見切れを防ぐため、min-height: 100svhやenv(safe-area-inset-*)を使用した可変対応を行う。 - 画像とアスペクト比: メインビジュアルは表示サイズの2〜3倍(横幅750〜1125px前後、WebP/AVIF推奨)で用意し、3:4 や 4:3 のアスペクト比と
object-fit: cover/object-positionで見切れを防ぐ。
「迷ったらこの設定」推奨プリセット値
Web制作の現場で「スマホのファーストビューサイズ設定に迷った際の実務推奨値」をまとめました。制作指示書やテンプレート設計の標準値としてご活用ください。
| 設計・実装項目 | 推奨プリセット設定値 | 実務での留意点 |
|---|---|---|
| デザインカンプ(Figma/XD) | アートボード幅: 375px(または 390px) 高さ基準枠: 750px | 375px幅で文字の折り返しや崩れがないか確認し、750px高の枠内に主要キャッチコピーとCTAを収める。 |
| CSSヒーローエリア高 | min-height: 100svh; | アドレスバーが表示されていても見切れない svh を指定。万が一の旧環境用に min-height: 100vh; を直前にフォールバックとして記述。 |
| セーフエリア(ノッチ・バー対応) | padding-bottom: calc(20px + env(safe-area-inset-bottom)); | viewport-fit=cover を設定したうえで、下部固定ボタンやヒーロー下端にセーフエリア余白を付与する。 |
| メインビジュアル画像 | 解像度: 1125 × 1500 px(3:4縦長) フォーマット: WebP / AVIF |
フォーマット: WebP / AVIF(150KB以内) | <picture> タグでレスポンシブ切り替えを行い、fetchpriority="high" を付与してLCP描画速度を最適化する。 |
正しい数値根拠とレスポンシブな可変設計の考え方を持っておくことで、どんな端末で閲覧されてもメッセージがまっすぐ伝わる高品質なスマホサイトを構築できます。


