モバイルデバイスと タブレット 彼らがようやく世界の支配に近づくにつれ、ウェブ技術は画面サイズの増え続ける数に対応するための競争にあります。ただし、この現象に対応するためのツールを考案すると、まったく新しい一連の問題が発生し、最後の言葉の1つが浮かび上がります。 「ウェブレスポンシブ」 。これは、ユーザーエクスペリエンスの品質を低下させることなく、すべてではないにしても大多数のデバイスでWebを機能させるという課題です。デスクトップやラップトップに収まるコンテンツを設計する代わりに、情報は携帯電話、タブレット、またはWebに接続された任意の表面で利用できる必要があります。ただし、この進化 レスポンシブウェブデザイン それは困難で、時には痛みを伴うことが証明されています。

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

Webのレスポンシブ画像検索

この時点で、開発者と設計者は、モバイルサイトのユーザー向けにWebサイトの読み込みが最適化されていることを確認できます。 Webトラフィックの20％以上 現在はモバイルユーザーから来ており、その数は増え続けています。データコンテンツの最大のチャンクの中に画像が取り込まれるため、サーバー側およびフロントエンドソリューションを含め、サイズ設定が優先事項になりました。これらのサイズ変更修正ソリューションについて説明するには、まず、画像をリンクする際の現在の欠点を理解する必要があります。

ソース属性が画像自体に直接リンクされているだけです。追加せずに必要な正しいタイプの画像を決定する方法はありません。

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

では、ウェブサイトは何をすべきでしょうか？

画像のスケーラビリティのためのバックエンドソリューション

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

カスタマイズ可能な画像

ただし、一部のセカンダリサーバーソリューションは検討する価値があります。 カスタマイズ可能な画像 これは、バックエンドで優先されるレスポンシブ画像アレイに最適なソリューションです。何も必要ありません マークアップ 特別ですが、一方で、小さなJavaScriptファイルを使用し、バックエンドファイルの面倒な作業のほとんどを実行します。 PHPと構成済みのnginxサーバーを使用します。また、UAトラッキングに依存せず、代わりに画面の幅をチェックします。アダプティブイメージは、画像のスケーリングに適していますが、大きな画像が必要な場合にも役立ちます アートディレクション たとえば、スケーリングだけでなく、トリミングや回転などの手法による画像の縮小。

煎茶をタッチ

センチャタッチ レスポンシブデザインイメージのもう1つのバックエンドソリューションですが、アウトソーシングソリューションと呼ばれるのが最適です。 Sencha Touchは、UAを追跡するときに、それに応じて画像のサイズを変更します。以下は、このサービスがどのように機能するかの基本的な例です。

Senchaにサイズを自動的に変更させたくない場合に備えて、サイズを指定するオプションもあります。結局のところ、セカンダリサーバー（およびアウトソーシング）ソリューションは、正しいイメージを送り返す前に、リクエストを処理するためのリソースを必要とします。これには貴重な時間がかかるため、要求と応答の過程が遅くなります。より良い解決策は、デバイス自体が直接呼び出すリソースを決定し、サーバーが正しく応答する場合です。

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

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

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

の場合もあります 属性srcset属性 これは、 要素のさまざまなブラウザベースのWebKitsで利用できます。これはJavaScriptなしで使用でき、webKit以外のブラウザーが無視される場合に最適なソリューションです。これは、他のソリューションでは不十分なまれなケースに適した一時的なリソースですが、包括的なソリューションと見なすべきではありません。

SQLServerデータベースのパフォーマンスチューニング

ピクチャーフィル

ピクチャーフィル 書店です ポリフィル 要素のために。これは、画像のスケーラビリティと関連する問題のための一連のフロントエンドソリューションの中で最も人気のあるライブラリの1つです。 2つのバージョンがあります。 Picturefill v1は、spanを使用して要素を模倣します。 Picturefill v2は、すでにそれを持っているブラウザの中で要素を使用し、提供します ポリフィル レガシーのものの場合（たとえば、IE> = IE9の場合）。いくつかあります 制限と干渉 、特にAndroid2.3の場合-ちなみにこれはimg srcsetの例です。救助に来る。これがサンプルです マークアップ Picturefill v2を使用する場合：

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

Imager.js

Imager.js のチームによって作成されたライブラリです BBCのニュース レスポンシブ画像がPicturefillで使用されているものとは異なるアプローチを持っていることを達成するために。 Imager.jsは、サポートされていないブラウザにアイテムを持ち込もうとしている間、ネットワーク速度を確認しながら適切な画像のみをダウンロードすることに集中しています。また、外部委託されたライブラリに依存することなく、遅延読み込みを組み込んでいます。それはの要素を置くことによって機能します プレースホルダー そしてそれらを 要素に置き換えます。以下に示すコードは、この動作を示しています。

new Imager({ availableWidths: [480, 768, 1200] });

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

new Imager({ availableWidths: [480, 768, 1200] });

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

ソースシャッフル

ソースシャッフル 他のフロントエンドライブラリとは少し異なる角度からこの問題に取り組みます。これは、「モバイルファースト」の学校の考え方から外れたもののように見えます。デフォルトでは、可能な限り最小の解像度を提供します。画面が大きいデバイスを検出することで、画像ソースを大きいものに変更します。それはより多くのように感じます ハック 完全に成長した本屋のようではありません。これは主にモバイルサイトにとって優れたソリューションですが、デスクトップやタブレットのリソースを二重にダウンロードすることは避けられないことを意味します。

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

• HiSRC -レスポンシブ画像用のjQueryプラグイン。 jQueryに依存することは問題になる可能性があります。

• Mobify.js -画像、スタイルシート、さらにはJavaScriptを含む、レスポンシブコンテンツ用の一般的なライブラリ。リソースがロードされる前にdOMを「キャプチャ」します。 Mobifyは強力で包括的なライブラリですが、レスポンシブな画像を作成するだけの場合はやり過ぎになる可能性があります。

要約すれば

結局のところ、で使用するアプローチを決定するのは開発者次第です。 レスポンシブウェブデザイン あなたのユーザーベースのための画像の。これは、データの収集とテストにより、どのアプローチを使用するかについてのより良いアイデアが得られることを意味します。

締めくくりとして、レスポンシブ画像の適切な解決策を決定する前に、以下の質問のリストを検討すると役立つ場合があります。

• レガシーブラウザは問題ですか？そうでない場合は、より最新の近似を使用することを検討してください（たとえば、Picturefill、属性srcset）。

• 応答時間は重要ですか？そうでない場合は、バックエンドまたはアウトソーシングソリューションを選択してください。

• ソリューションは内部にあるべきですか？アウトソーシングされたオプションは明らかに問題外です。

• レスポンシブ画像に移行しようとしているサイトにたくさんの画像がありますか？検証またはセマンティックラベル（または非セマンティックラベル）について懸念がありますか？これには、画像リクエストをアダプティブイメージのようなものに導くためのバックエンドソリューションが必要になります。

• アートディレクションは問題ですか（特に情報量の多い大きな画像の場合）？ Picturefillのようなライブラリは、このようなシナリオに適したソリューションかもしれません。また、どのバックエンドソリューションも同様に機能する可能性があります。

• JavaScriptについて何か心配はありますか？フロントエンドソリューションは問題外であり、UAトラッキングに依存するバックエンドやアウトソーシングなどのオプションが残ります。

• モバイルの応答時間とデスクトップの応答時間の優先順位はありますか？その場合は、ソースシャッフルのようなライブラリが最も適切です。

• 画像だけでなく、サイトのあらゆる側面にレスポンシブな行動を提供する必要がありますか？ Mobifyの方がうまくいく可能性があります。

• 完璧な世界に到達しましたか？したがって、CSS近似のみを使用してくださいdisplay:none！

  プライベートエクイティへのファミリーオフィス投資