レスポンシブ(レスポンシブデザイン / レスポンシブ Web デザイン)
1 つの HTML(中身のデータ)を使って、画面幅(PC・タブレット・スマホ)に応じてレイアウトを自動的に可変させる設計手法。CSS のメディアクエリ(画面幅に応じてデザインを切り替える指示書)を使い、「スマホの幅になったら横並びを縦並びにする」「メニューをハンバーガーボタン(ハンバーガーメニュー)(三本線)に折りたたむ」といった切り替えを行う。PC 用とスマホ用で別々の URL・別々の HTML を作る「セパレート型」の反対概念。
運用の要点:Google の評価基準「MFI」とコンテンツ量の統一
2010 年代後半以降、Google が「スマホ版のサイトを基準にして検索順位を決める」というモバイルファーストインデックス(MFI)を導入したため、レスポンシブ実装は現代の標準(必須要件)となった。ここで初心者がやりがちなのが「スマホだと長くて読みづらいから、スマホ版だけテキストを非表示にして削ろう」という判断。これをやると、Google から「コンテンツが薄いサイト」と評価されて SEO順位が落ちるため、PC とスマホで本文の量を揃えるのが鉄則。
実務でのチェックポイントと「タブレットの罠」
担当者は、公開前に「PC・タブレット・スマホ縦」の 3 つの幅で、ヘッダー・ファーストビュー・ボタン・フォームが破綻していないかを確認する。ブラウザの検証機能(エミュレータ)はあくまで「ざっくり確認用」であり、最後は必ず自分の実機(本物のスマホ)で触って確認するのがプロの仕事。
タブレット幅の事故:制作会社は予算の都合上、デザインカンプ(完成見本の画像)を「PC 用」と「スマホ用」の 2 枚しか作らないことが多々ある。その結果、間のタブレット幅のレイアウトがコーダー(実装者)の想像に丸投げされ、半端で崩れたレイアウトになる事故が多発する。
現場でよくある「落とし穴」:レスポンシブ ≠ スマホ最適化
最も恐ろしい罠は、「レスポンシブ = スマホ最適化」ではないということ。
- 「縮んだだけ」の使いにくいサイト:画面の幅に合わせて「ギュッと縮んで全部画面に入った」だけで満足してしまう。実際には、リンク同士が近すぎて誤タップ(タップ領域)してしまう、スマホを片手で持った時にボタンに指が届かない、フォームの入力欄が小さすぎてイライラするといった問題が放置されている。
レスポンシブ実装されているかは単なる前提に過ぎない。「スマホの実機でストレスなく CV(コンバージョン)(購入やお問い合わせ)が取れるか」を最終評価軸にするのが、Web 担当者の正しい見方。
言葉をよく利用する人
- デザイナー
- コーダー / フロントエンドエンジニア
- Web 担当者(発注側)
- ディレクター
会話上での使用例
業者からPC版優先で作ってスマホは後でと提案された場面
-
業者ディレクター
まずPC版のデザインを固めて、あとからスマホへレスポンシブで展開していきます。
-
Web担当者
うちはスマホからの流入が7割なので、スマホ版を先に固めてからPCを作る順番でお願いできますか。検索エンジンもスマホ版を基準に評価しますし。
-
業者ディレクター
了解しました。スマホ縦のワイヤーフレームから出し直します。
実機チェックで見つけた不具合をコーダーに連絡する場面
-
Web担当者
iPhoneの実機で見たら、最初の画面のボタンがキーボードを出したときに隠れてしまいます。レスポンシブの表示自体は崩れていないんですが、使い勝手としてはまずいです。
-
コーダー
了解です。ボタンを画面に張り付ける形をやめて、フォームの下に置き直します。タブレット幅でも崩れないか確認してから直したものを出します。