レスポンシブデザイン：画面サイズではありません

2012年3月、Guy Podjarnyは、4つの異なる画面解像度を持つデバイスでの数百の新しいレスポンシブサイトのパフォーマンスを比較するテストを実施しました。 結果は非常に残念でした。

2年後の応答性の高い設計の後に、想像できるデザイナーや開発者がこの列車に飛び乗ると、さまざまな解像度での性能テストが適応理論の非常に基本的なものを揺るがしました。

Guyは、ほとんどすべてのレスポンシブサイトが太りすぎていることを証明しました。

「私たちはそのイメージでインターネットを作りました...重いです」ジェイソン・グリッグスビー。

しかし、さらに重要なことは、デスクトップユーザーのようなモバイルユーザーがキロバイトの混雑にさらされていたことです。

Webコミュニティの代表者は、このデータに対して異なる反応を示しました。 レスポンシブデザインはあらゆる場合の解決策ではなく、現時点で設計者が直面するすべての課題に対処するのに十分に開発されていない可能性があると述べる人もいます。

幸いなことに、Webコミュニティには常に雄牛をつかんで状況をひっくり返す人々がいます。

Brad Frost、Luke Wroblewski、Christian Heilmannのような現代のウェブの達人は、他の人々が危機によって恐ろしくなり、問題をコミュニティの利益に変えることができる機会を見ました。

「サイトの重量が15MBの場合、これはHTML5ではありません。 これはナンセンスです」とクリスチャン・ハイルマン。

オフェンスはありませんが、開発者の専門用語で最もよく説明されているものを犠牲にして、Webでのパフォーマンスが伝統的に達成されています。 GZIP-ing、uい、ミニフィケーション、DNSルックアップ、ファイル連結などの用語...これらすべてのあいまいな言葉は、デザイナーを見えないようにします。

しかし、コミュニティの賢い人々は、それでも問題の根本がより深いことに気づきました。 実際、画像を超高解像度で最適化するか圧縮するかは問題ではありませんが、同時に表示するためにこの画像をダウンロードする必要があるモバイルユーザーからは単に非表示にするだけです。

「優れたパフォーマンスは優れたデザインです」とBrad Frost氏。

本当に軽量なサイトを作成するには、 生産性を気にせず、代わりに、 生産性を設計要素の1つとして考慮する必要があります 。

パフォーマンスは他のものと同じくらい重要です。 優れたパフォーマンス結果を達成するサイトは、最初からこのアプローチを順守しています。 そして、これを見落とす人は、ダウンロード速度が遅いことに苦しむことになります。

「生産性は尊重されます。 ユーザーを尊重し、彼らは再び戻ってきます。」-Brad Frost。

なぜこれが起こっているのですか

直帰率

3秒以上ロードされた場合に57％のユーザーがサイトを離れるという調査があります。

Google、ページスピード、SEO

2010年の春、Googleはサイトをランク付けする際に速度を考慮し始めました。 平均読み込み速度のサイトの位置に大きな影響はありませんが、ページが一定時間読み込まれない場合、検索アルゴリズムはそのようなサイトにペナルティを適用します。

これは、ユーザーエクスペリエンスに関しては、速度に注意を払う必要があることを再度証明しています。

速度に関する考慮事項

人々はしばしばモバイルコンテキストのかなり抽象的な概念について話します。 Googleの有名な理論によると、モバイルユーザーは3つのタイプに分類されます。

• 今すぐ繰り返し ：携帯電話を使用して、継続的な繰り返しの変更（スポーツ結果、Facebookフィードの更新、株式市場のダイナミクス）に遅れずについていく人々。
• 今退屈 ：イベントを待っている間に電話をかけるユーザー。
• 緊急（緊急）

真実のようですね。

実際、これは現実とは関係ありません。 「モバイルコンテキスト」はありません。 人々は、路上を歩いたり、家でくつろいだり、電車で旅行したりする際に携帯電話を使用します。 彼らはすべてを同時に行います！

電話は、どこにいても人々を追跡します。 したがって、人々はどこでもそれらを絶対に使用します。

「モバイルコンテキストは重要なことですが、まず、それが一体何であるかを理解する必要があります」とティムカドレック。

Luke Wroblewskiは、いくつかの本当に興味深い統計を提供しています。

人々はどこでモバイルデバイスを使用しますか？

• 自宅で84％
• 日中の自由時間の80％
• ラインおよび待機プロセスで76％
• ショッピングプロセスの69％
• 仕事で64％
• テレビ番組を見ているときの62％（代替研究では84％の数値が得られます）
• 仕事の準備で47％

新しい可能性のある状況の出現、新しい市場の発展、人々の新しい習慣の出現により、モバイルコンテキストは必然的に変化します。 人々がモバイルデバイスを使用している限り、 モバイルコンテキストの概念は引き続き重要であると想定できます。

これにより、インターネットの速度を詳しく調べることができます。 ユーザーに重いWebサイトを提供し、問題が発生しないようにする方法は1つしかありません。ユーザーが自宅で高速インターネットを使用しているときにMacbook Proで開く場合です。

ただし、非常に多くの他の状況に備える必要があります。 人々は無数のデバイスを使用して、毎日市場に出てサイトを表示します。

「彼らはあなたのサイトをどのデバイスから見るのかわかりません。 これがユーザーが決めることです。」-カレンマクグレイン

数年前にスマートフォンがあまりなかった国でさえ、その数は今や途方もないペースで増加しています。

「素材、コンテンツ、情報、製品、サービスがモバイル環境で利用できない場合、これらの人々にとってはまったく存在しません」-Karen McGrain。

さらに重要な点は、人々があなたのサイトに来る場所です。 そのため、インターネットの速度を考慮する必要があります。 一部のユーザーは、カバレッジの質が低い遠隔地に住んでいることさえありません。 人々は職場から、100 Mb / sのチャネルがある家から、自宅から、2から30 Mb / sの速度が利用可能な、3Gおよび4Gなどを介してサイトにアクセスします。

直接言えば、レスポンシブデザインはもはや画面サイズに関する話ではなく 、さまざまなシナリオであり、その解決策は柔軟性があり、「元から先」に考えられるべきです。

そしてどうやって？

あなたが尋ねた良いこと。

前述のように、パフォーマンスは、運命のサイトを保存するためにサーバー側で起動される自動化されたタスクのセットと見なされるべきではありません。 このような問題を克服し、競争上の優位性に変える方法さえあります。

避けるべきこと

Guy Podjarnyは、多数のヘビーアダプティブサイトが存在する3つの主な理由を特定しています。

• 読み込みと非表示：多数の要素が読み込まれますが、ユーザーには表示されません
• ダウンロードとトリミング：高解像度画像がダウンロードされ、ユーザー画面に合わせてトリミングされます
• 過剰なDOM：解析を回避する方法はなく、ブラウザがすべてのDOMゾーン（非表示ゾーンを含む）を処理します

積極的なアプローチ

サイトが常にパフォーマンスの期待に応えることができない理由に関する豊富な情報があります。 ほとんどの専門家は、「最初から順応しなければならない」と言っています。

以下で説明する手法はすべて新しいものではありません。 ここで興味深い点は、それらがどのように組み合わされて絡み合い、欠陥を滑らかにし、互いのメリットを強調するかです。

進歩的な改善

この手法の意味は、Web上のサイトを使用してエクスペリエンスを提供することであり、これは最も重要なサイトによってのみ制限されます。

数年前、この理論は主に「ブラウザ」の観点から認識されていました。 HTML5、CSS3、jQueryなどの技術の開発とともに 開発者はユーザーのことを忘れているようです。 それらの多くは不完全なWebサイトを作成し、これらの新しいテクノロジーに頼りすぎました。

Webkit、Firefoxなどに基づいたブラウザが市場で大きなシェアを獲得した今、別の問題が発生しました-iPhoneまたはSamsungの機能を持たないブラウザを備えた膨大な数のモバイルデバイス。 進歩的な改善は、まず忘れられたこれらすべてのプレイヤーの能力を考慮に入れ、その後、より洗練されたデバイスに向かって進む唯一のアプローチです。

モバイルファースト開発

2009年、Luke Wroblewskiは、3つの理由からMobile Firstと呼ばれる開発アプローチを提案しました。

• モバイル市場は猛烈なペースで成長を続けています。
• モバイル環境では、集中することができます（画面スペースが大きすぎることによる混乱を取り除くことができます）。
• モバイル環境は機能を拡張します（GPS、ジオロケーション、マルチタッチジェスチャ、加速度計、カメラなどの技術のおかげ）。

それ以来、Webデザインは常にこのアプローチに移行しています。 多くのデザイナーと開発者は、モバイルバージョンのサイトを最初に構築すると、主にデスクトップ開発が提供されることに注意しています（上記の2番目のポイントで非常によく説明されています）。 進歩的な改善とMobile Firstアプローチも密接に関連しています。 開発者は、モバイルデバイス用のWebサイトの作成を開始し、徐々に改善し、最初は小さな画面サイズに大きな解像度を追加しました。

ジョーダンムーアは、モバイルファーストを使用する理由の優れたリストをまとめました 。 彼は、接続速度に完全に頼ることができないという事実のために、「適応型Webデザイナー」は最低のエントリポイントから動作を開始する必要があると言います。接続速度が遅く、段階的に開発中のサイトのモバイルバージョンより高速な接続のためのブレークポイント。 将来的には、高速接続に頼ることができるようになりますが、今のところは、通信の質の低さを当然のこととして取る価値があり、急いで踏み出すことはありません。

おわりに

小さな許可と機能を期待してサイトを設計します。 最初から進歩的な改善手法を使用します。 追加の機能、強化された視覚効果、意味のある場所で対話する方法を追加します。

RESS：レスポンシブWebデザイン+サーバー側コンポーネント

多くの人によると、レスポンシブデザインには1つの大きな欠点があります。これは、画面の幅を決定することに完全に依存します。

タッチスクリーンを備えたラップトップのようなハイブリッドを含む、ますます多くの種類のデバイスの出現により、レスポンシブデザインにおいて画面解像度の決定は非常に重要になりました。 この機能を提供するライブラリ（主にModernizr ）は文字通り繁栄しており、現在ほとんどのプロジェクトで使用されています。 開発者は、ユーザーのブラウザがこの機能をサポートしているか、その機能をサポートしているかを理解し、それに応じて提供することができます。 しかし、多くの場合、ブラウザに依存することは良い考えではありません。多くの場合、ブラウザは特定の機能を部分的にしかサポートできず、完全なサポートを「宣言」しているためです。

この問題を解決するために、RESSが作成されました。 Mobile Firstと同様に、RESSという用語は2011年にルークウォロブスキーによって造られました。 これは、デバイスの種類、評価、および関連するユーザーエクスペリエンスの提供に基づいています。 このタスクを達成するために、 WURFL 、 DeviceAtlasのような重いツールと、 ブラウザーエージェントのようなより軽いツールがあり、ユーザーエージェントの行を読み取り、この情報に基づいて動作します。

デバイスのタイプを評価することには、他の利点もあります。 開発者は、ユーザーのデバイスに応じて異なるサイトテンプレートを使用できます。 非常に大きなサイトを作成し、モバイルナビゲーションを簡素化するとします。 何かを表示または非表示にすることで「コンテンツを再生」したり、JavaScriptコードを使用してdivを移動したり、モバイル版とデスクトップ版の異なるテンプレートを使用したりできます。

BBCの代表者は、RESSと進歩的な改善が別々に機能する方法について話します。 アプローチは、マスタードをカットと呼ばれています！ それは、あらゆるデバイスで動作するサイトの基本バージョンを作成することにあります。 その後、デバイスはサーバーによって評価され、「マスタードをカットオフ」しているかどうかが判断されます。 答えが「はい」の場合、サイトの改良版が使用されます。 デバイスに必要なパラメーターがない場合でも、ユーザーにはメインコンテンツが表示されます。

条件付きダウンロード

「モバイルユーザーは、メニュー、営業時間、電話の配信を確認したいと考えています。 デスクトップユーザー自身は、誰かがサラダを笑う1 MBの写真を見たいと思っています。」- Matt "Wilto" "Marquis 。

いくつかの観点を考慮してください。

1）モバイルユーザーは、デスクトップユーザーと同じくらいコンテンツを求めています。

「コンテンツがURLでアクセス可能な場合、モバイルデバイスから確実に表示されます」-Brad Frost。

2）モバイル環境により、集中できます。 同じコンテンツを同様に適切に提供するために、設計者が受け入れる必要がある特定の制限（接続速度や画面サイズなど）があります。

「アグレッシブエンハンスメント」とも呼ばれるこの手法により、デザイナーは主要なコンテンツに集中し、大画面向けに徐々に改善することができます。 特定のコンテンツへの基本的なアクセスを意味し、場所が表示されたときにページで補足できます。

「おそらく、条件付きロードのより正確な定義は、コンテンツ優先アプローチと呼ばれます。 この場合、サイドバーや、美しくはあるが機能的ではないコンテンツを含む多数のコラム-あなたには手に入らない贅沢です。」-ジェレミーケイト。

CSSの動作を模倣し、JavaScriptで画面サイズを推定する優れたMatchMediaツールを使用できます。

遅延読み込み

モバイル環境の最適化が必要な場合、外観と使用が重いサイト（Facebook、Twitter、Pinterest）は、より良いユーザーエクスペリエンスを提供するために遅延読み込み手法を使用します。 初めてページを読み込むと、一定数の投稿が読み込まれます。 ページを下にスクロールすると、デザイナーはさらにコンテンツを表示することを想定しているため、Ajaxを使用してページに挿入されます。 これにより、ページの読み込みが大幅に高速化され、DOMの冗長性が回避されます。

パフォーマンス予算を設定する

Tim Kadlecは、最大ページウェイトの設定とこのメトリックの制御が、ページの読み込み時間を短縮する主な方法であると主張しています。 「目標を設定し、それらのために努力します。」 既に予算を超過している場合、Steve Soudersには3つの選択肢があります。

• 既存の機能またはアイテムを最適化する
• 既存の機能またはアイテムを削除する
• 新しい関数またはアイテムを追加しないでください

かなり急進的に聞こえますが、このアプローチにより、各新機能がサイトの全体的なパフォーマンスにどのように影響するかに集中できます。

さらに、より技術的で概念的ではないレベルで機能する多くの方法があります。

イメージング技術

ウェブサイトは約60％が画像で構成されています。 また、接続速度が不明なデスクトップサイズの画像をモバイルユーザーに表示する場合は、ダウンロード速度の問題でサイトを破滅させます。

この問題を解決する方法は、画面サイズまたはデバイスタイプに応じて異なるバージョンの画像を表示することです。 したがって、携帯電話からサイトにアクセスすると小さな画像が表示され、デスクトップユーザーには高解像度の画像が表示され、HiDPIデバイスの場合は2倍の大きな画像が表示されます。

レスポンシブ画像

世界中のデザイナーと開発者は、HTML仕様にレスポンシブ画像を含めることに苦労しています。 Matt 'Wilto' Marquisは、このアイデアの最も著名な支持者の1人です。 戦いはまだ勝利していませんが 、望ましい結果を達成するのに役立つJavaScriptベースのソリューションが登場しました。

Filament Groupの Scott Jehlは、コミュニティによって提案されたマークアップを模倣するプラグインを作成し、素晴らしい機能を発揮します。それはPictureFillです。

画像圧縮

オランダのデザイナーDaan Jobsisは、Photoshopで画像を圧縮するときに非常に奇妙な現象を発見しました。 彼は次の一連のアクションを実行することができました：彼は画像を取得し、そのサイズを2倍（200％）にし、元の品質の25％以下に圧縮してから、ブラウザーの画像サイズを元のサイズ（100％）に戻しました。 その結果、画像は明るくなっただけでなく、ピクセル密度の重複によりHiDPIスクリーン用に最初に最適化されました。

ここで見つかった唯一の問題は、ブラウザが元のサイズで2倍の画像をレンダリングするのが難しい場合があることです（特に、メディアコンテンツが多数あるサイトの場合、これを何百回も行う必要がある場合）。 このソリューションの最適性を検証するには、テストに時間をかける必要があります。

ベクトルとビットマップ

優れた選択肢はSVG画像です。 これらは完全にスケーラブルなので、どの画面でもうまく機能します。 この場合のフォールバックの実装は、Modernizrを使用すると非常に簡単になります。

アイコンフォント

技術的には、実際にはベクトル画像であり、フォント形式でのみ表示されます。 クリス・コイヤーが言うように、「アイコンのフォントは素晴らしい」と言うのは：

• サイズ変更が簡単
• 色を変えるのは簡単
• フォント形状の設定が簡単
• 透明なPNGとは異なり、IE6で機能します。
• 画像の場合と同じことができます。
• 無制限のタイポグラフィルームを提供します。

HiDPI画像

Dave Bushellは最近、 HiDPI画像について考えた非常に興味深い記事を書きました。 彼は、iPhone、iPad、またはこれらのデバイスの機能に一致する他の最新デバイスの画像をユーザーに表示できるとしても、これがサイトに害を及ぼさないと考えるのはまだ早すぎると主張します。

「高速でピクセル密度が高いということは、ユーザーがより高品質の画像を見たいということですか？」 ギガバイト数に制限のあるパケット料金の場合、それはありそうにありません。」-Dave Bushell。

次は？

Googleは最近、新しい画像形式-WebPを開発しました。 画像を損失することなく圧縮できるため、PNGに比べて3倍小さいファイルを取得できます。

現在、WebP形式との間で画像を変換できるシンプルで軽量なJavaScriptライブラリがあります。 最新のGoogle製品の影響を考えると、多数の画像を含むサイトのパフォーマンスを改善するためにWebPで実験を開始することは、すでに良い考えかもしれません。

アイテムをダウンロードする

慎重かつ順番にアイテムをダウンロードしてください。 この側面を制御することには大きな利点があり、最初にページに基本的なコンテンツを表示してから改善することができます。

CSS、画像

メディアクエリ、条件付きまたは遅延読み込みを使用してダウンロードを制御し、適応/圧縮画像技術を適用します。

Javascript

asyncやdeferなどのHTML5機能を使用します。 さらに、 RequireJSなどの「ブートアシスタント」があり、ロードと依存関係を制御できます。

広告、ソーシャルウィジェット、サードパーティの要素

読み込み後にページに貼り付けてください 。

オールドスクールのパフォーマンス改善テクニック

彼らはかなり長い間知られていますが、彼らはまだうまく機能します。

HTTPリクエストの数を減らす

これを実現するには、開発者は努力する必要がありますが、これを実現する方法はいくつかあります。

• すべてのCSSファイルに連結を使用するか、CSSプリプロセッサーを使用してそれらを単一のファイルにコンパイルします。
• ページのレンダリングを実際にブロックする必要がない限り、JSプラグインを同じファイルにまとめて常にフッターにロードします（フッターにTypekitフォントをダウンロードすると、有名なFOUT効果または「 スタイルなしテキストの爆発 」が発生します）。
• PNG画像を使用する必要がある場合は、スプライトを使用します。 すべての画像を1つにまとめ、CSSを使用して必要な部分に「切り取り」ます。
• 可能であれば、URLデータスキーム（ ロシア語 、 英語 ）を使用して、画像を文字列データとして含め、HTTPヘッダーの数をさらに減らすことができます。

バイト数を減らす

ページから呼び出される各スクリプトまたはCSSファイルを縮小します。 サーバーでGZIP圧縮/拡張を構成し、それらをすべての要素に適用します。

おわりに

レスポンシブデザインの誕生以来、Webパフォーマンスの重要性は非常に誇張されてきました。

設計者と開発者は、ネットワークへのさまざまなアクセス速度、さまざまなデバイス、さまざまなユーザーの場所が出現し始めた要素として、適応パズルの組み立てに焦点を当てています。

明日の問題に備えるには、生産性に多くの注意を払う必要があります。なぜなら、デックストップ指向のウェブは目の前で消えてしまうからです。 モバイルユーザーは迅速かつ簡単で、コンテンツにアクセスする際の障害を克服できません。また、毎日多くのサイトがあることを考えると、 高速であることは先を行くことを意味します。

あなたも好きかも[en] ...

• 画像とマルチメディア用の20個のjQueryプラグイン 。
• 20のプラグイン交換レッスン、ヒント、スニペット、およびWordPressソリューション 。
• Webデザイナーと開発者向けの50の無料ツールとアプリケーション 。
• 3 0素晴らしい新しいjQueryプラグイン 。
• コードにどのライセンスを選択しますか？
• CSS3およびボタン構築技術に関する20のレッスン。

PS翻訳に関するコメントはPMで受け付けています。

PPSまた、ユーザビリティとUXの世界で興味深い出版物のダイジェストをブログに投稿し始めました 。 突然、誰が気にします。