• CREATIVE

May 29.2019

レスポンシブWebデザインのブレークポイントの決め方|コンテンツ・デバイスベースの利点・欠点まとめ

breakpoint

こんにちは、フロントエンジニアのはるかです。

今回は、レスポンシブWebデザイン対応において、ブレークポイントの決めるための2つの考え方について、紹介したいと思います。

レスポンシブWebデザインにおける「ブレークポイント」とは

レスポンシブWebデザインとは、スマートフォン、タブレット、デスクトップPCなど、あらゆるデバイスでコンテンツが見やすいように調整されたWebサイトを指します。

レスポンシブ対応においては、メディアクエリ、とりわけ画面サイズに応じたCSSやJavascriptの調整によって表示を最適化することが、一般的となっています。

この時、各デバイスに応じて表示内容を切り替えるために、適宜設定される画面サイズの基準点が「ブレークポイント」となり、その定め方はWebサイトの制作者側の判断に委ねられています。

筆者は、ブレークポイントの設定において、「コンテンツベース」「デバイスベース」という2つの基準があると考えています。

コンテンツベースでのブレークポイント設定の利点と欠点

「コンテンツベース」によるブレークポイント設定は、Google社がレスポンシブデザイン対応のガイドラインにて提唱している手法です。

Webデベロッパー向けのガイドラインにて、Google社はブレークポイントの決め方を、次のように説明しています。

ブレークポイントは、デバイスクラスを基準に設定しないでください。現在使用されている特定のデバイス、製品、ブランド名、オペレーティング システムを基準にブレークポイントを設定すると、メンテナンスが非常に大変になる可能性があります。代わりにコンテンツ内容に基づいて、コンテナに合ったレイアウト方法を決定するようにしてください。

このように、Google社はデバイスのカテゴリーではなく、コンテンツの表示内容に準じてレイアウトが切り替わるタイミングをメジャーブレークポイントとして設定し、その上で適宜表示の調整が必要なタイミングで、マイナーブレークポイントを追加していくことを推奨しています。

デバイスに依らず、コンテンツファーストでブレークポイントを設定することは、コンテンツを常時最適な状態で表示する、という目的においては、理想的な手法です。

各デバイスのサイズは機種によって様々であり、今後も一般的とされるサイズは変化し続けると予想されます。

コンテンツ自身のサイズ・内容を基準とすれば、デバイスサイズの変動による影響を、意識する必要はありません。

デバイスサイズをベースとしたブレークポイント設定

一方で、デバイスの一般的な区分けであるスマートフォン(モバイル)、タブレット、デスクトップ(PC)という3タイプにそれぞれ適合するよう、ブレークポイントを設定するのが「デバイスベース」の考え方です。

各デバイスの画面サイズをベースとしてブレークポイントを設定する場合、「デバイスサイズの変動による影響を受けやすい」欠点はあるものの、手間をかけ過ぎずに、大抵のデバイスのレスポンシブ対応が可能となります。

まずは、今日における各デバイスタイプの特徴を確認しながら、シンプルかつ幅広く対応できるブレークポイントを検討します。

スマートフォン(モバイル)

2019年現在、Webの利用において最も利用されているデバイスが、スマートフォンです。

サイトのカテゴリーによって多少の差はありますが、全体の5割から8割程度のアクセスは、スマートフォンから行われています。

スマートフォンの画面サイズは端末によってまちまちですが、Web利用においては、動画を視聴する場合などを除き、端末を縦向き(Portrait)の状態で使用することが一般的となっています。

主要端末の画面の横幅は 320 ~ 424px の範囲内に収まるため、メディアクエリを少なくとも max-width: 480px 程度に設定すれば、縦向きでのスマートフォン利用シーンに対応することができます。

横向き(Landscape)への対応については、優先度は非常に低いと考えていいでしょう。

最近では画面が大型化すると共に、縦横比も黎明期の4:3から16:9、18:9のような縦長の形状へとトレンドが変化しています。

このような縦長の端末を横向きにして、スマートフォン向けのWebページをブラウジングすることはおそらく想定されていないでしょう。

デスクトップ(PC)

デスクトップ(PC)におけるブレークポイント設定は、今日ではデザインのレイアウトパターンによって、様々な値に設定されるようになっています。

が、ここはあえてデバイスのサイズにフォーカスをあてて、考察します。

デスクトップでは、小型のモバイルPCから大型の液晶を利用する端末まで、画面サイズのパターンが非常に多いため、現在利用されているデスクトップの画面サイズの分布は、下図の通りバラつきがありますが、横幅を1280px以上有する端末の割合が多くなっています。

StatCounter-resolution-JP-monthly-201904-201904-bar
2019年4月におけるデスクトップ端末の画面解像度の割合

出展:StatCounter Global Stats

よって、ブレークポイントの上限は1200px程度に設定すると、小型のPCでもブラウザウィンドウを最大化すれば、全体を閲覧できるサイズに調整しやすくなります。

タブレット

タブレット向けのブレークポイント設定においては、初期のiPadの画面横幅である”768px”を基準とする事例が、過去に多く見られました。

しかし現在は、同じiPad系列にてサイズがより大きい端末も徐々に普及しており、768pxという数値にこだわる理由は薄れています。

2019年5月現在、iPadの画面サイズは「768px × 1024px」から「1024px × 1366px」までの範囲となります。

また、Android系タブレットの画面サイズは「600px × 960px」 から「800px × 1280px」の範囲に収まる機種が大半です。

また、タブレットはスマートフォンと比べ、縦横どちらの向きでも利用される端末であり、とりわけ横向きではデスクトップと同等のサイズとなる場合もあるので、どのようにブレークポイントで線引きをするのかを判断する必要があります。

例えば、ブレークポイントを1024pxに設定する場合、9.7型iPadの縦横、大型のタブレットの縦向きまでが「タブレット」として対応する形となり、834pxに設定すれば、11型までのiPadおよびAndroidタブレットの縦向きを「タブレット」、横向き時は全て「デスクトップ」として調整する、という形での対応が想定されます。

このあたりの線引きの判断は、タブレットでの表示内容をスマートフォン寄りにするのか、デスクトップ寄りにするのかという、コンテンツベースでの観点も加味して判断すると良いでしょう。

ただ、Web全体におけるタブレット端末の利用率は数パーセント程度であることや、現時点ではモバイルフレンドリーテストの対象となっていないことを踏まえると、スマートフォン、デスクトップPCと比べて、タブレット対応の重要性はやや低いといえます。

そのため、「タブレットではデスクトップ向けの表示を縮小表示させる」という対応を取ることで、コストを抑えるという考え方もできます。

以上の各デバイスの推奨値をまとめたブレークポイントの設定例は下記の通りとなります。

・スマートフォン:320px〜480px
・タブレット:481px〜1024px
・デスクトップ:1025px〜

コンテンツベース・デバイスベースの利点と欠点

コンテンツベースでブレークポイントを設定する場合、先述の通り、デバイスサイズに影響されず、常時見やすいレイアウト表示が実現しやすくなる点が、メリットとなります。

しかし、「常に見やすいレイアウト構成」をイメージしながら、デザイン・コーディングすることは易しい作業ではありません。

デバイスサイズをベースとする場合、目安となるブレークポイントが事前に設定されるので、それに応じてページ内の各要素を組み替えることで対応することができます。

しかし、コンテンツベースであればその基準点が元から存在しないので、画面サイズに応じた見え方の変化を追いながら、自身でブレークポイントを設定することになります。

また、ブレークポイントをある程度の数に抑えなければ、コーディング時の表示内容の調整にかかる工数や、ページ更新にかかる手間が膨らむことになります。

一方でデバイスサイズを基準とする場合、ブレークポイントが初期段階から定まりやすいので、コンテンツベースほどの時間をかけずにデザインを進めることができるでしょう。

しかし、画面サイズの遷移に応じて表示内容をどのように調整するのかを、全く考慮していなければ、レスポンシブ対応の難易度が非常に高まる可能性があります。

また、デバイスサイズのトレンドの変化は早いので、Webサイト公開の数年後に、そのサイズへブレークポイントを再調整する必要が生じる可能性もあるでしょう。

いずれの設定方法にも強みと弱みがあるので、案件の内容や状況に応じてこれらの対応法を使い分けましょう。

レスポンシブデザイン対応は奥深い!

今回はブレークポイントの設定方法をテーマとする記事となりましたが、記事を書きながら、改めてレスポンシブデザイン対応の難しさと奥深さを実感しました。

筆者自身も、ここ最近はデバイスベースでブレークポイントを設定しながら、細かくブレークポイントを追加して微調整を行う機会が増えていたので、そのあたりをコンテンツベースに切り替えてうまく処理できないか、検討してみたいと思います。