ある記事 によれば、レスポンシブ Web デザインを採用するサイトの 72% が、デスクトップとモバイルに同じリソースが使われているそうです。またそれらリソースの 60% 以上が画像 という統計や、モバイル用に画像を最適化すれば、データ量を 72.2% 削減できる という調査結果もあります。

ということで、レスポンシブ画像のことを調べていていましたが、その技術進化というか、紆余曲折も含めて色々とある様です。

最新技術を素早く取り入れることはもちろん大事ですが、特に過渡期においては、変化に強いサイトを作るためにも技術の先行きを見極めることが重要です。そこでタイトルのような視点で、これまでの経緯をつらつらと辿ってみました。

自分としてのテーマは、「じゃあ、今、どうするか？」だったのですが…。読んで下さる方の何かに役立つかどうかは甚だ心もとない記事です。

ちなみに今回記事で取り上げた話題については、レスポンシブ画像のデモ に、もう少し掘り下げて展示しています。そちらもぜひ覗いてみて下さい！

レスポンシブ画像をめぐる要求の変化

レスポンシブ画像とは従来、ビューポートや画面解像度（時には印刷時の解像度）などに適した画像を表示することを指し、

• ビューポートや回線速度に適した画像を提供し、モバイル環境での通信量低減を図る
• Retina などピクセル密度の高い表示デバイスには、解像度の高い画像を提供する

などが主な関心事項でした。

一方 W3C コミュニティ・グループ の1つである RICG が考える理想的なレスポンシブ画像とは「ユーザーのコンテキストに適した画像」です。彼らはその ユースケース として、上記に加え次のような要求があると考えています。

• 省電力モードでは低品質の画像を選択し、通信時の消費電力を抑える
• 端末のサイズに合わせ、ユーザーに対する訴求に最適な画像を提供する

特に後者は Art Direction（広告、宣伝、グラフィックデザインなどにおいて、主に視覚的表現手段を計画し、総括、監督すること）と呼ばれ、例えばモバイル用には単なる縮小画像ではなく、ユーザーに訴求したいエリアを切り出し拡大して見せる ことを要求します。

RICG はこれらレスポンシブ画像をめぐる様々な要求を、以下のように、既存規格の拡張で実現できるよう検討を進めています。

• HTML の拡張
  • ビューポートとデバイス・ピクセル比に応じて適切な画像が選択できるよう、ユーザーエージェントにヒントを与えるマークアップ仕様
• HTTP の拡張
  • ユーザーエージェントの表示能力を HTTP リクエストに載せ、サーバーとのコンテンツ・ネゴシエーションにより適切な画像を提供する仕組み

ビューポートとデバイス・ピクセル比は、スタイルやレイアウトで扱うべきと要素と考えられており、従来から CSS3 メディア・クエリ で扱えます。

しかしアート・ディレクションの例でも分かる通り、もはやレスポンシブ画像に関する要求はコンテンツ自体の問題となり、ビューポートやデバイス・ピクセル比を HTML でも扱えるようにする必要が出てきた言えます。

いずれにしても当初言われていた「ワンソースでマルチデバイスに対応」というレスポンシブデザインの謳い文句は、もはや画像に関しては「死語」に近く、要求が複雑化していくと共に、今後はマルチソースの方向になると思われます。

Retina 用の画像は低画質で良い！ – Retina 革命

2012年の初頭は、レスポン Web シブデザインが Future-Ready なコンテンツ で Future Friendly なサイトを作る技術としてもてはやされていた頃です。

ところが Retina の出現をキッカケに「画像のボケ」が問題になり、そのクオリティを保つため、通信量の増加には目をつぶり、デバイス・ピクセル比に応じて縦横2倍の画像を提供するよう、コンテンツを修正せざるを得なくなりました。

以降、相当数の「レスポンシブな画像を実現する手段」が提案されてきましたが、どの手法を使えば良いのか、未だ決定打がない状態が続いていると思います。

一方で、Daan Jobsis さん の2012年7月27日の記事 Retina 革命 が大きな反響を呼びました。彼は、Retina 用の高解像度画像なら画質をかなり落としても、十分綺麗に見えるということを明らかにしたのです。

例えば、320×240 の画像なら Retina 用には 640×480 の画像を作るわけですが、その際 jpeg の画質を 80 とか 90 にする必要はなく、20 か 30 で十分で、かつ非 Retina 用画像に比べてファイルサイズが 75% 程度で済むというのです。

同時にその画像は、非 Retina デバイスで見ても遜色ないことや、元ファイルの解像度が足りない場合でも Photoshop で拡大した画像の方が良い結果が得られることも明らかにしています。

つまり、Retina 用と非 Retina 用に画像ファイルを分ける必要がなく、常に2倍の（低画質な）高解像度画像を提供すればイイというワケです。

どのデバイスでも、ファイルサイズが小さく、より高品質だなんて、あり得ない！

彼はデザイナーとしての視点から、ハードウェアの技術革新が従来の常識を覆したことに、純粋に驚いたのでしょう。これが「Retina 革命」とタイトル付けされた理由です。

もちろん、このような画像のレンダリングは電力を余計に消費するため、通信時間の短縮とを天秤にかける必要があるかも知れません。それでも、読み込みとレンダリングを最悪2回実行してしまう Retina.js を使うよりは、はるかにマシでしょう。

むしろ Daan さんの発見は単なるテクニックではなく、デバイスピクセル比の問題を HTML 外で解決する道を示唆しているとも考えられます。

現に 複数のレイヤーに解像度毎の画像を差分として載せ、圧縮率を高めるレスポンシブ画像コンテナ や ページ中の全画像を同時並列に読み込み、レンダリングするプログレッシブ・ダウンロード の研究などが進んでいます。

また Google の開発者は 将来 webp で 3D 画像を扱いたい と語っていますし、そのうち 3D 表示デバイスなどがもっと一般化するかもしれません。これらの研究成果は、新しいメディア・タイプの出現を予感させます。

特に過渡期においては Daan さんの様なテクニックやハックの類いが必ず出現するものですが、RWD に関する要求の複雑化を念頭に置けば、標準規格の整備と共に、ブラウザの進化が不可欠な状況にあると思います。

ブラウザの漸進的な進化

レスポンシブな画像を実現する 様々な手法 の中には、異なるサイズの画像を二重に読み込み、サイト速度の低下や電池の消耗を引き起こすものがあります。

例えば JavaScript を使う手法では、<img> 要素の src 属性を差し替える前（つまり HTML 解析時）に ブラウザの先読み機能 が働いてしまいます。

また回線速度に応じた画像を選ぶ場合も、 foresight.js 等のスクリプト読み込み後ではなく、Navigation Timing を元に、 HTML 解析時に選ぶのが理想的です。

このような レスポンシブ画像が抱える様々な課題を解決する には、その手段が ブラウザのネイティブな機能として取り込まれることが必須 です。

このため2011年台から、 <picture> 要素が提案 されてきたワケですが、ここにきてようやく <img> 要素の srcset 属性 が Chrome 34 に実装 されました。その元になった RICG の仕様案は以下の通りです。

srcset="url [descriptor] [, url ...]"

url

画像への URL

descriptor

device pixel ratio

小数点を含むデバイス・ピクセル比（DPR）に "x" を付加

image dimension

正の整数である画像の幅に "w" を付加

例えば次のマークアップでは、DPR に適した画像が選択されます。

<img src="small.jpg" srcset="small.jpg 1x, medium.jpg 2x" alt="...">

さて、ここで私が注目したいのは DPR を直接指定する第1の書式ではありません。ビューポートが絡むと、例えばスマホ用 small.jpg の 2x が、デスクトップ用 medium.jpg の 1x と同になったりする可能性もあり、この書式では表現できないからです。

かつては 第1と第2の書式が混在した仕様案 もありましたが、最近の仕様案 では、両者は区別されています。

実は RICG の案には「sizes」という属性があります。これはデバイス・ピクセル比に振り回されることなく、レイアウト指向でマークアップできるようにするためのもので、ブラウザが最適な画像を選択できるようヒントを与える役割りを果たすものです。

簡単化のために <img> 要素の例でちょっと説明します。

<img src="small.jpg" alt="..."
	sizes="(min-width: 40em) 45vw, 90vw"
	srcset="small.jpg 480w, medium.jpg 960w, large.jpg 1920w">

sizes 属性には 45vw とか 90vw などの ビューポートに対する表示幅の百分率 を指定します（% も指定可）。

一方 srcset 属性には 1x とか 2x の代わりに 480w とか 960w などが指定されています。これらは一見すると ビューポート幅 を指しているようですが、実は各画像ファイルの横幅（CSS ピクセル値）を表します。

これらによりブラウザは、次式で算出される値を元に srcset 属性の中から最適な幅を持つ画像ファイルを選択します。

最適な画像ファイルの幅 = ビューポートに対する表示幅の百分率 / 100 × ビューポート幅 × デバイス・ピクセル比

この書式であれば、純粋にレイアウト上の計算から導かれる選択肢をマークアップすれば OK で、ブラウザは、自らのビューポート幅やデバイス・ピクセル比に適した画像を選択することが出来るのです。

残念ながら Chrome 34 でこの書式は実装されていません。ですが RICG の 実装状況リスト にあるように、 <picture> 要素とのセットでリリースされるのではないかと思っています。

少しずつかも知れませんが、 RICG の活動が実を結ぶとイイですネ。

コンテンツとスタイルの境界

そもそも <picture> 要素の仕様案 は <video> 要素と相関性のある案 を元に策定されました。例えば以下のマークアップでは、ブラウザが適切なフォーマットを選ぶことができます。

<video poster="firstframe.jpg">
	<source src="sample.mp4" type="video/mp4; codecs='...'">
	<source src="sample.ogv" type="video/ogg; codecs='...'">
</video>

ここまではコンテンツ側の問題であり、特に違和感はありません。これに対し、<picture> では、例えばこんな感じです。

<picture>
	<source media="(min-width: 480px)" srcset="small.jpg medium.jpg 2x">
	<source media="(min-width: 960px)" srcset="medium.jpg, large.jpg 2x">
	<img src="small.jpg" alt="...">
</picture>

この仕様であれば、新しいメディア・タイプの出現やアート・ディレクションの要求を受け入れることが出来るでしょう。

一方、サイトのブレークポイントと上記 media 属性とが一致していないと、意図したリソースが選ばれないという問題が出てきます。こうなるともはや、「ドキュメント（HTML）とスタイル（CSS）の分離」という Web の原則や常識は、どこに行っちゃたの？ と疑いたくなります。

この仕様案に関しては、下位互換性のためとは言え、それ自体でコンテンツを表示しない画像系のタグが増えることに、ブラウザ・ベンダーが反対していたという話があったようです（すみません、出典は失念しました）。

最初の章でも書きましたが、実のところ、ドキュメントとスタイルの境界が極めて曖昧になる、というか、両者の結び付きが強まることが、今後の大きな課題だと思います。

先に「<picture> 要素はいずれ実装される」などと無責任な予測を書きましたが、この課題がどう決着されるのかは見ものです。これまでのように、そこそこの期間を要する可能性もあると思いますが、皆さんはどうお考えでしょうか？

さて過渡期の今、どう対処するか？

ハッキリ言って、分かりません（オィ、コラァ！）。少なくとも今回、記事に貼る画像をデスクトップでの表示幅の2倍かつ画質 0 で作成してみました。まぁ、jpeg ならそれなりに減量効果はあります。

次回は、レスポンシブ画像を実現する様々な手法を取り上げながら、世界の人たちがどう対処しているのかを見ると共に、レスポンシブ画像に要求される近々の要件を整理しながら、さらに掘り下げてみたいと思います。

ご期待ください（するかぁ！？）。