ワンサイズで一部に対応：レスポンシブWebデザイン画像ソリューションのガイド

公開: 2022-03-11

モバイルデバイスとタブレットデバイスが最終的な世界支配の達成に近づくにつれ、Webデザインとテクノロジーは、増え続ける画面サイズに対応するための競争にさらされています。ただし、この現象の課題に対応するためのツールを考案すると、まったく新しい一連の問題が発生し、最新の流行語の1つが「レスポンシブウェブ」になります。これは、ユーザーエクスペリエンスを低下させることなく、すべてではないにしてもほとんどのデバイスでWebを機能させるという課題です。デスクトップやラップトップに合うようにコンテンツを設計する代わりに、携帯電話、タブレット、またはWebに接続された任意の表面で情報を利用できるようにする必要があります。ただし、このレスポンシブWebデザインの進化は、困難で、時には苦痛を伴うものであることが証明されています。

テキスト情報に対応するのは簡単なことですが、レスポンシブ画像、インフォグラフィック、ビデオなど、かつてはデスクトップのみを念頭に置いて設計されたコンテンツを考慮すると、注意が必要です。これにより、コンテンツを正しく表示するだけでなく、コンテンツ自体がさまざまなデバイスを使用してどのように消費されるかという問題が発生します。スマートフォンのユーザーは、デスクトップのユーザーとは異なります。データプランや処理速度なども考慮する必要があります。グーグルは検索結果でモバイルフレンドリーなサイトを強調し始めており、そのようなサイトのページランクを大幅に上げることにつながるとの見方もある。以前のソリューションでは、モバイル専用のサブドメイン（およびリダイレクト）を展開することでこれに対処していましたが、これにより複雑さが増し、すぐに時代遅れになりました。（すべてのサイトがこのルートを利用できるわけではありません。）

レスポンシブWeb画像の探求について

レスポンシブウェブデザインの画像は、現代の一般的なデバイスに合わせて拡大縮小する必要があります。

この時点で、開発者と設計者は、モバイルサイトにいるユーザーに合わせてWebサイトの負荷が最適化されていることを確認する必要があります。現在、Webトラフィックの20％以上がモバイルユーザーであり、その数は増え続けています。ページコンテンツデータの最大のシェアを占める画像では、この負荷を減らすことが優先事項になります。サーバーサイドソリューションとフロントエンドソリューションの両方を含め、レスポンシブデザインイメージのサイズ変更を簡素化するためにいくつかの試みが行われました。これらのレスポンシブ画像ソリューションについて説明するには、まず現在の画像リンクの欠点を理解する必要があります。

<img>タグには、画像自体に直接リンクしているsource属性のみがあります。アドオンがないと、必要な正しいタイプの画像を判別する方法がありません。

HTMLにすべての画像サイズを含め、CSSルールを使用してdisplay:none 。これは、完全な論理世界で最も論理的なソリューションです。このようにして、ブラウザは表示されていないすべての画像を無視し、理論的にはそれらをダウンロードしません。ただし、ブラウザは一般的なロジックを超えて最適化されています。ページのレンダリングを十分に高速化するために、必要なスタイルシートやJavaScriptファイルが完全に読み込まれる前に、ブラウザーはリンクされたコンテンツをプリフェッチします。デスクトップ向けの大きな画像を無視する代わりに、すべての画像をダウンロードしてしまうため、ページの読み込みがさらに大きくなります。 CSSのみの手法は、背景画像として意図された画像に対してのみ機能します。これは、これらがスタイルシート内で設定できるためです（メディアクエリを使用）。

それで、ウェブサイトは何をするのですか？

バックエンドレスポンシブ画像スケーリングソリューション

バックエンドソリューションは、レスポンシブWebデザインの状況で画像サイズを処理するのに最適です。

モバイル専用サイト/サブドメインを除いて、ユーザーエージェント（UA）をスニッフィングし、それを使用して正しいサイズの画像をユーザーに提供する必要があります。ただし、開発者は誰でも、このソリューションの信頼性がいかに低いかを証明できます。新しいUA文字列が常に表示されるため、包括的なリストの維持と更新に手間がかかります。そしてもちろん、これは、そもそも簡単になりすましのUA文字列の信頼性の低さを考慮に入れていません。

アダプティブイメージ

ただし、一部のサーバー側ソリューションは検討に値します。アダプティブイメージは、バックエンドのレスポンシブイメージ修正を好む人にとって素晴らしいソリューションです。特別なマークアップは必要ありませんが、代わりに小さなJavaScriptファイルを使用し、バックエンドファイルで大部分の重い作業を実行します。 PHPとnginxで構成されたサーバーを使用します。また、UAスニッフィングに依存せず、代わりに画面幅をチェックします。アダプティブイメージは、画像の縮小に最適ですが、大きな画像にアートディレクションが必要な場合、つまり、単に拡大縮小するだけでなく、トリミングや回転などの手法による画像の縮小にも便利です。

センチャタッチ

Sencha Touchは、もう1つのバックエンドレスポンシブデザインイメージソリューションですが、サードパーティソリューションと呼ぶ方がよいでしょう。 Sencha Touchは、UAをスニッフィングすることにより、それに応じて画像のサイズを変更します。以下は、サービスがどのように機能するかの基本的な例です。

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

Senchaが画像のサイズを自動的に変更したくない場合に備えて、画像サイズを指定するオプションもあります。

結局のところ、サーバー側（およびサードパーティ）のソリューションでは、正しい画像を送り返す前にリクエストを処理するためのリソースが必要です。これには貴重な時間がかかり、要求と応答の移動が遅くなります。より良い解決策は、デバイス自体が直接要求するリソースを決定し、サーバーがそれに応じて応答する場合です。

フロントエンドソリューション

フロントエンドのレスポンシブデザインの画像スケーリングソリューションは、ウェブサイトの負荷を最適化するための優れたオプションです。

最近では、レスポンシブ画像に対応するためにブラウザ側で大幅な改善が行われています。

<picture>要素は、W3CによってHTML5仕様で導入および承認されています。現在、すべてのブラウザで広く利用できるわけではありませんが、ネイティブで利用できるようになるまでそう長くはかからないでしょう。それまでは、要素のJavaScriptポリフィルに依存しています。ポリフィルは、要素が不足しているレガシーブラウザにとっても優れたソリューションです。

<img>要素のいくつかのwebKitベースのブラウザーで使用可能なsrcset属性の場合もあります。これはJavaScriptなしで使用でき、webKit以外のブラウザーを無視する場合に最適なソリューションです。これは、他のソリューションが不足しているという奇妙なケースに役立つ一時的なギャップですが、包括的なソリューションと見なすべきではありません。

ピクチャーフィル

Picturefillは、 <picture>要素のポリフィルライブラリです。これは、レスポンシブ画像のサイズ設定とスケーリングの問題に対するフロントエンドソリューションの中で最も人気のあるライブラリの1つです。 2つのバージョンがあります。 Picturefill v1はspanを使用して<picture>要素を模倣しますが、Picturefill v2はすでに提供しているブラウザーの中で<picture>要素を使用し、レガシーブラウザー（たとえば、IE> = IE9）にポリフィルを提供します。これにはいくつかの制限と回避策があり、特にAndroid 2.3の場合、これは偶然にもimg srcset属性が役立つ例です。以下は、Picturefillv2を使用するためのサンプルマークアップです。

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

データプランが限られているユーザーのパフォーマンスを向上させるために、Picturefillを遅延読み込みと組み合わせることができます。ただし、ライブラリは、パッチに依存するのではなく、より幅広いブラウザサポートを提供し、奇妙なケースに対処することができます。

Imager.js

Imager.jsは、Picturefillで使用されているものとは異なるアプローチでレスポンシブ画像を実現するために、BBCニュースチームによって作成されたライブラリです。 Picturefillは<picture>要素をサポートされていないブラウザに持ち込もうとしますが、Imager.jsは適切な画像のみをダウンロードすることに重点を置き、ネットワーク速度にも注意を払います。また、サードパーティのライブラリに依存せずに遅延読み込みを組み込んでいます。プレースホルダー要素を使用し、それらを<img>要素に置き換えることで機能します。以下のサンプルコードは、この動作を示しています。

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

レンダリングされたHTMLは次のようになります。

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

ブラウザのサポートは、前向きなソリューションよりも実用的なソリューションであるという犠牲を払って、Picturefillのサポートよりもはるかに優れています。

ソースシャッフル

ソースシャッフルは、他のフロントエンドライブラリとは少し異なる角度からレスポンシブイメージの問題にアプローチします。これは、「モバイルファースト」の考え方に似ており、デフォルトで可能な限り最小の解像度を提供します。デバイスの画面が大きいことを検出すると、画像ソースをより大きな画像に交換します。それは、より多くのハックであり、本格的なライブラリではないように感じます。これは主にモバイルサイトに最適なソリューションですが、デスクトップやタブレットのリソースの二重ダウンロードは避けられないことを意味します。

その他の注目すべきJavaScriptライブラリは次のとおりです。

HiSRC-レスポンシブ画像用のjQueryプラグイン。 jQueryへの依存が問題になる可能性があります。
Mobify.js-画像、スタイルシート、さらにはJavaScriptを含むレスポンシブコンテンツ用のより一般的なライブラリ。リソースをロードする前にDOMを「キャプチャ」します。 Mobifyは強力な包括的なライブラリですが、レスポンシブ画像だけを目標とする場合はやり過ぎかもしれません。

概要

結局のところ、どのレスポンシブWebデザインイメージアプローチがユーザーベースに適しているかを判断するのは開発者次第です。これは、データの収集とテストにより、取るべきアプローチについてより良いアイデアが得られることを意味します。

まとめると、以下の質問のリストは、適切なレスポンシブ画像ソリューションを決定する前に検討するのに役立ちます。

レガシーブラウザは問題ですか？そうでない場合は、より最新のアプローチを使用することを検討してください（例：Picturefill、 srcset属性）
応答時間は重要ですか？そうでない場合は、サードパーティまたはバックエンドのソリューションを選択してください。
ソリューションは社内にあるはずですか？サードパーティのソリューションは明らかに除外されます。
レスポンシブ画像に移行しようとしているサイトにすでにたくさんの画像がありますか？検証またはセマンティックタグ（または非セマンティックタグ）について懸念がありますか？これには、画像リクエストをAdaptiveImagesなどにルーティングするためのバックエンドソリューションが必要になります。
アートディレクションは問題ですか（特に情報量の多い大きな画像の場合）？ Picturefillのようなライブラリは、このようなシナリオに適したソリューションになります。また、どのバックエンドソリューションも同様に機能します。
JavaScriptの欠如について懸念はありますか？フロントエンドソリューションはどれも問題外であり、UAスニッフィングに依存するバックエンドまたはサードパーティのオプションが残ります。
デスクトップの応答時間よりもモバイルの応答時間の方が優先されますか？ソースシャッフルのようなライブラリがより適切かもしれません。
画像だけでなく、サイトのあらゆる側面に対応する行動を提供する必要がありますか？ Mobify.jsの方がうまくいくかもしれません。
完璧な世界が実現しましたか？ CSSのみのdisplay:noneアプローチを使用してください！