Mobile & Multi-Device Optimization Guidelines
Created: 2026-02-04
建設業LPテンプレート（Type-Trust）におけるモバイル最適化の鉄則まとめ。「見やすさ」「崩れにくさ」「使いやすさ」の3点を担保するための技術基準です。
1. コンテンツ幅の確保（攻め vs 守り）
スマホ画面では「余白」よりも「文字の可読領域」を優先します。
| 項目 |
モバイル (Mobile) |
デスクトップ (Desktop) |
意図 |
| 画面端の余白 |
px-6 (24px) or px-4 |
px-12 (48px) |
スマホは物理幅確保を最優先。 |
| 装飾線の余白 |
pl-4 (16px) |
pl-8 (32px) |
左線があっても文字を圧迫しない。 |
| カード内余白 |
p-4 (16px) |
p-16 ~ p-24 |
枠内でも文字を大きく見せる。 |
2. タイポグラフィ（見出しと改行）
「巨大すぎて改行崩れ」を防ぎ、かつ「泣き別れ」を回避します。
見出しサイズ
- モバイル:
text-3xl (約30px)
- デスクトップ:
text-5xl ~ text-7xl (意図した迫力を維持)
改行・禁則処理の「ハイエンド（Kiyasuku）基準」
【重要】単価50万円〜のハイエンド案件では、小手先の <br> 隠しは使用禁止とする。
- NG:
<br class="md:hidden"> や <br class="pc-only">
- PCとスマホでは最適な1行の文字数が全く違うため、brタグの表示/非表示だけでごまかすと「て、」「に、」のように1文字だけが改行されるダサい「泣き別れ」が発生する。保守性も最悪。
- OK: 見出しブロック（HTML）の完全分離
<h2 class="pc-only"> と <h2 class="sp-only"> を作り、PC用とスマホ用で「それぞれ最も美しい位置で改行された別の文章ブロック」を用意する。これが最高級のレスポンシブ文字組み。
エディトリアル（高級誌）タイポグラフィの標準値
スマホ画面での圧迫感を取り除き、ハイエンドな「抜け感」を演出するための3原則：
- 行間 (Line Height):
2.1 〜 2.4（通常の1.6では詰まりすぎる）
- 文字間 (Letter Spacing):
0.1em 〜 0.15em（空気をはらませる）
- 文字色 (Text Color): 完全な黒
#000 は避け、#333 や #555 に落とす
3. レイアウト順序（Voiceセクション等）
「誰が発言しているか」を直感的に伝える順序。
- 順序: Image (顔) → Profile (誰) → Quote (内容)
- PCは左右レイアウト可だが、モバイルは上記順序の縦積み（flex-col 等）を厳守。
4. フォントの使い分け（機能 vs 情緒）
- Noto Sans JP (ゴシック): 情報伝達（理念、仕事内容、データ、FAQ）
- Zen Old Mincho (明朝): 情緒・メッセージ（Voice引用、Contact、Culture、見出し）
- ※ Worksセクション見出しも「作品」として扱うため明朝体を推奨。
5. 画像表示の安定化 (Padding Hack)
position: absolute を使うスライダー等で、タブレット幅で高さが0になり画像が消える現象を防ぐ。最新の aspect-ratio プロパティだけでなく、物理的なpaddingで高さを確保する手法を併用する。
6. 操作性の確保 (UI/UX)
- タップ領域: ハンバーガーメニューや閉じるボタンは、見た目以上に判定を大きくする（
p-2以上）。
- 視認性:
backdrop-blur (すりガラス) や bg-white/90 を活用し、背景とのコントラストを確保する。
7. ブレークポイント戦略 (1024pxの壁)
「PCかタブレットか」の境界線は原則 lg (1024px) とし、それ未満はすべてモバイル（縦積み・ハンバーガー）として扱う「広めの安全マージン」を取る。
境界ルール
- < 1024px: モバイル扱い
- ヘッダー：ハンバーガーメニュー
- レイアウト：
flex-colで縦積み
- 余白：
px-6
- ≧ 1024px: PC扱い
- ヘッダー：フルメニュー（横並び）
- レイアウト：
flex-rowで横並び
- 余白：
px-12
ヘッダーメニュー崩れへの鉄則
- タブレット幅（768px～1023px）で無理にヘッダーメニューを横並びにすると、「ロゴと重なる」「リンク文字が改行してレイアウト崩壊」などの事故が多発する。
- 対策: ヘッダーナビゲーションは
hidden lg:flex を徹底し、タブレット幅では潔くハンバーガーメニューを表示する。無理な「タブレット対応」はしない。
8. 鉄板フォント選定 (迷ったらこれ)
| カテゴリ |
推奨フォント |
特徴・用途 |
| 本文 |
Noto Sans JP |
視認性・汎用性最強。迷わずこれ一択。 |
| 見出し(Jp) |
Zen Old Mincho |
信頼・伝統・高級。老舗や地域密着型に最適 (Type-Trust採用)。 |
| 英字(En) |
Oswald |
剛健・インパクト。建設業と相性抜群の縦長ゴシック。 |
|
Jost / Outfit |
知的・モダン。幾何学的ですっきりした印象 (DX・テック系)。 |
9. 技術的パフォーマンス最適化 (PSI 対策)
PageSpeed Insights (PSI) でモバイルスコア 80+ を叩き出すための「技術的実装ルール」。
見た目のリッチさを維持しつつ、モバイルの回線負荷を極限まで減らすための鉄則。
9-1. 重量級メディアの完全遮断 (JS Injection)
- 問題:
display: none で動画を隠しても、ブラウザは「念のため」裏で動画ファイルをダウンロードしてしまう（1.5MB〜の無駄死に）。
- 解決策: HTMLに
<source> タグを書かず、JavaScriptで画面幅判定してから注入する。
<!-- HTML: videoタグの中身は空にしておく -->
<video id="heroVideo" poster="image.webp"></video>
<script>
// 999px以上（PC）の場合のみ動画ソースを注入
if (window.innerWidth > 999) {
const v = document.getElementById('heroVideo');
if (v) {
const s = document.createElement('source');
s.src = 'movie.mp4';
s.type = 'video/mp4';
v.appendChild(s);
v.load();
}
}
</script>
9-2. 脱・外部アイコンライブラリ (No FontAwesome)
- 禁止: FontAwesome 等の外部CDN読み込み。
- たった数個のアイコンのために 200KB〜 のCSSを読み込むのは、レンダリングブロック（描画遅延）の主犯となるため厳禁。
- 推奨: Inline SVG。
- 必要なアイコンだけをSVGコードとしてHTMLに直接埋め込む。通信発生ゼロ、描画待ち時間ゼロ。
9-3. モバイル画像の「攻め」の圧縮基準
スマホ画面は物理サイズが小さいため、画質を下げても粗が目立ちにくい。
| 対象 |
推奨設定 (ImageMagick) |
解説 |
| Desktop画像 |
-quality 75 |
大画面での美麗さを維持。 |
| Mobile画像 |
-quality 50 |
「攻めのQ50」。スマホではQ75との違いはほぼ判別不能だが、容量は劇的に減る（例: 80KB→35KB）。 |
9-4. LCP High-Speed Checklist（最優先3項目）
Largest Contentful Paint (LCP) は、ページの「体感速度」に最も影響する指標。以下の3つを徹底すれば、スコアが劇的に改善する。
| 項目 |
実装方法 |
効果 |
| 1. Hero画像のPreload |
<link rel="preload" as="image" href="hero_sp.webp" media="(max-width: 768px)"> |
必須。ブラウザが「最優先でダウンロード」する。LCP改善の最短ルート。 |
| 2. 初期opacityの禁止 |
Hero要素に opacity: 0, scroll-reveal, js-fade-up などのクラスを付けない |
アニメーション待ちでLCPが数秒遅延する「Hidden Blocker」を回避。 |
| 3. fetchpriority="high" |
<img src="hero.webp" fetchpriority="high"> |
ブラウザに「これは重要」と明示的に指示。他リソースより優先ダウンロード。 |
⚠️ 重要: Preloadのパスと実際の<img>のパスが完全一致していないと、ブラウザが「別ファイル」と認識して二重ダウンロードが発生する（例: hero.webp vs hero_sp.webp）。必ずgrepで検証すること。
9-5. Hidden Blockers（見えないブレーキ）の撲滅
CSS/JSアニメーションが原因で、Hero画像が「読み込み済みなのに画面に表示されない」状態が数秒続く致命的バグ。
典型的な原因クラス
scroll-reveal: スクロールするまでopacity: 0のままjs-fade-up: JavaScript実行完了まで非表示ken-burns: アニメーション開始までディレイ- CSS Keyframe の初期値が
opacity: 0（Type-CのheroSequenceなど）
診断方法
# Hero section にopacity/visibilityブロッカーがないか確認
grep -i "scroll-reveal\|js-fade\|opacity-0" index.html
# 見つかった場合、Hero要素から削除する（下部セクションは残してOK）
修正例
<!-- ❌ NG: Heroセクションでこれをやると LCP が 5秒以上遅延 -->
<div class="hero-content js-fade-up">
<img src="hero.webp" class="scroll-reveal" />
</div>
<!-- ✅ OK: アニメーションクラスを削除、即座に表示 -->
<div class="hero-content">
<img src="hero.webp" fetchpriority="high" />
</div>
9-6. PageSpeed測定の正しい理解
重要: PageSpeed Insightsのスコアは±30点のブレがある。同じサイトでも測定のたびに60点→92点→56点のように大きく変動する。
| 現象 |
原因 |
対策 |
| 同じサイトで92点→56点 |
測定サーバーの負荷、ネットワーク状態のランダム変動 |
3回測定して平均を取る。1回の結果で一喜一憂しない。 |
| 改善したのにスコア悪化 |
測定タイミングの偶然 |
時間を置いて再測定（5分以上間隔を開ける）。 |
| クライアントが測定すると低い |
同上（測定サーバーのランダム性） |
スコアを約束しない。「60点以上を目標」程度に留める。 |
🎯 内部品質基準: モバイル60点以上を安定維持。80点以上は「達成可能」だが、クライアントへの約束としては出さない。不安定な数字を売りにするとクレームリスクになる。
9-7. 製作段階からの軽量化マインドセット
「後から直す」より「最初から作る」方が圧倒的に効率的。以下を制作フローに組み込む。
| フェーズ |
チェック項目 |
具体的アクション |
| デザイン |
画像点数の抑制 |
Hero, Works, Teamなど、セクションごとに画像を3-5枚以内に制限。装飾目的の画像は極力CSS/SVGで代替。 |
| HTML構築 |
Preload/Lazy自動設定 |
Hero画像には必ずpreloadとfetchpriority="high"。2画面目以降はloading="lazy"を標準装備。 |
| アニメーション実装 |
Hero要素に初期opacityを付けない |
scroll-revealなどは2セクション目以降のみ使用。Heroは「即時表示」を厳守。 |
| 画像書き出し |
Quality設定の徹底 |
Desktop: Q75 / Mobile: Q50 を標準値として、最初から圧縮済みで保存。 |
| 公開前 |
Preload一致チェック |
grep "preload"とgrep "<img.*hero"でパスが完全一致しているか機械的に確認。 |
💡 ポイント: 「速度最適化」を最後の仕上げ作業と考えず、設計・デザイン段階から組み込むことで、手戻りゼロで高速なサイトを構築できる。