レスポンシブデザインでは不十分です。レスポンシブパフォーマンスが必要です

最近、パフォーマンスの問題がたくさんあるレスポンシブWebサイトに出くわしました。 それらのほとんどで、問題は非常に明白であるため、最新世代のスマートフォン以外ではほとんど役に立たない。 概念としての応答性がより多くの聴衆に到達することを目的としているという事実を考えると、これはかなり逆効果のように思われます。

この問題の最大の原因は、依然として普及しているデスクトップファーストの設計パラダイムです。 モバイルファーストの観点から考えると問題は解決するようですが、それだけでは満足のいくパフォーマンスが保証されるわけではありません。 私たちは皆、多かれ少なかれ優雅な劣化に頼りすぎているようです。 不足している機能を有効にするために、シムとポリフィルに依存しています。 迅速な開発を可能にし、ブラウザーの互換性が問題になる場合に備えて、ライブラリに依存しています。

「なぜ心配するの？」 あなたは尋ねるかもしれません。 「私たちの訪問者のほとんどは、最新のOSバージョンを実行している高性能のスマートフォンを持っています。 彼らは私たちのサイトを扱うことができます。 分析は私たちにそう教えてくれます。」

ストローマンの議論については申し訳ありませんが、あなたのサイトを使用できる人があなたのユーザーの大多数になることを大声で述べる価値があると思います。 分析にAndroid2.3が表示されない場合、それはそれらのデバイスを使用しているユーザーがいないことを意味しますか？ それとも、あなたのサイトにはそれらのユーザーに提供するものが何もないということですか？ その世代の多くのデバイスがまだ棚にあり、今日でも新品で購入されていることを考慮してください。 昨年のテクノロジーとしてそれを完全に却下するべきではありません。

そこで、Web開発の理想的な事例と実際の目標についてお話したいと思います。 そして、それらの目標に私たちを近づける実践とパラダイムについて。

ブリックファーストの設計パラダイム

年間の電話販売のかなりの部分は、依然としてフィーチャーフォンによって占められています。 人口のさらに多くの部分が毎年電話を購入していませんが、それにもかかわらず、いくつかのWeb対応デバイスを所有しています。 これらの数に、現在も使用されている最新世代のスマートフォンを追加し、Kindleやその他のWebセミ対応デバイス（WAPデバイス、テレビ、トースター、Tシャツ、レンガ）を追加します。 それらをすべて合計すると、驚異的な合計に達する可能性があります。

このオーディエンスのユースケースを検討してください。 彼らは自分のデバイスで長い記事を読んだり、閲覧したり、調査したりするつもりはありません。 しかし、テンキーでURLを入力し、方向キーを使用してページをナビゲートして電話番号にアクセスしたり、その場でアドレスを再確認したりするという恐怖を経験する可能性があります。

それでは、機能とパフォーマンスの特定のしきい値を下回るデバイスにその情報のみを提供するサブモバイルファーストのレイアウトを実装するのはどれほど難しいでしょうか。

優雅な改善

最小限のベストプラクティスとして優雅な劣化を使用して、それを超えて考えることを（ある程度）妨げるキャッチオール原則を作成しました。 優雅な劣化が起こったら、私たちは確かに私たちの仕事が完了し、うまくいったと言うことができます。 使用中のさまざまなフレームワークやライブラリによってすでにカバーされているため、ますます多くの場合、それについて考える必要はありません。 そして最後に、ポリフィルとシムは、場合によっては機能低下の必要性を完全に取り除きます。

この機能がますます容易に利用できるようになるにつれて、それについて考える必要性は（それを超えて）ますます遠くなります。

この記事の観点からは、次のように分類できます。

不当な劣化：機能がすぐに利用できない場合、実装は失敗し、使用できなくなったり、非常に非現実的な方法で使用できるようになります。

グレースフルデグラデーション：機能がすぐに利用できない場合でも、許容できるユーザビリティを可能にする方法で機能が失敗します。

不愉快な改善：機能がすぐに利用できない場合は、ポリフィルまたはシムによってエミュレートされます。

そこで、問題は解決しました。

同じローエンドデバイスのパフォーマンスを考慮しない限り、そうですね。

彼らの若い兄弟の処理能力とデータ能力を欠いて、彼らははるかに大きな負荷を運ぶように求められます。 ポリフィルをソリューションとして採用すると、すべての最新機能がすべてのデバイスで利用可能になり、心配することなく使用できるという幻想が生まれます。

そのため、万が一に備えて、modernizrを実装し、すべてをポリフィルします。 能力が最も低いデバイスは、最終的に最大量のデータをロードし、最大量の処理を実行します。 したがって、「最高の」エンドユーザーエクスペリエンスを保証します。

優雅な改善のアイデアは、最低の機能要件から始めて、デバイスの機能に基づいてパフォーマンスとユーザビリティのバランスが最適になるまでアップグレードをロードすることによって、概念を逆転させます。 したがって、データトラフィックと処理の要件は、それらを処理するのに最適なデバイスに移動されます。

確かに、現時点では、概念は非常に複雑です。ほとんどのフレームワークとライブラリでサポートされておらず、ほとんど議論されておらず、そのようなプラクティスへの参照はほとんどなく、離れており、マイクロ機能にローカライズされています。 しかし、ある時点で、それはすべての概念と機能でそのようになりました。

できますが、そうする必要がありますか？

Web開発のもう1つのベストプラクティスは、デバイスをアクティブ化する前に、その機能がデバイスで使用可能かどうかを確認することです。

ただし、Google Chromeの最新バージョンを古いAndroidスマートフォンにインストールできることを考慮に入れると、CSSアニメーション、WebGL、背景視差効果、およびその他の多くの機能を実行できると主張されます。 しかし、それは本当に、本当に、できません。 ブラウザがクラッシュし、デバイス全体が応答しなくなり、制御を取り戻すために再起動する必要があります。

この問題は最近、Androidアプリケーションに大きな影響を及ぼし始めています（ユーザーの観点から）。 この意味で最も顕著な劣化の1つは、Googleトーク/ハングアウトアプリのアップグレードに影響を及ぼし、古いデバイスのパフォーマンスの問題により、サービスが利用可能な最も軽量なチャットアプリケーションからほとんど使用できないアプリケーションに変わりました。 （この点をもう一度強調してください。ここで「古い」とは、ほとんどすべての店舗で新品の既製のものを購入できることを意味します）。 同じ問題がYouTubeアプリとTwitterアプリ（私の経験では）、そして明らかに他の多くのアプリに影響を及ぼしました。

したがって、計画段階のある時点で、最先端の構成に対する高性能のコア機能の価値を評価してください。 または、少なくとも、レガシーユーザーが何らかの形でアプリ/サービス/コンテンツの最後の世代を利用できるようにしておきます。 そういえば…

ユーザーが出血エッジからオプトアウトできるようにする

古いデバイスから、または接続不良でGmailを使用しようとしていることに気付いたことがありますか。 その「基本的なHTMLのロード」リンクは確かに便利です。

最先端のレスポンシブでアニメーション化されたタッチ指向のオンラインストアフロントにその機能がないのはなぜですか？

考えてみてください。より多くの潜在的な顧客にリーチできるように、応答性を要求しました。 あなたは最高の第一印象を残すためにそれを最先端にしました。 その結果、潜在的な顧客があなたやあなたのサービスに関する基本的な情報にさえ到達する可能性が低くなります。 優雅な改善があなたにとってコストがかかりすぎる概念である場合、「WOW」バージョンが彼らのデバイスにとって多すぎる場合、少なくともあなたの訪問者にあなたのコンテンツのテキストのみのバージョンにアクセスするオプションを提供しませんか。

あなたは本当に図書館全体が必要ですか？

最後に、標準を少し超えてプッシュしてもらいたい最後のベストプラクティスは、「使用するか失うか」です。 どのライブラリとモジュールが実際に使用されているかを追跡し、それらだけを含めるのは面倒な場合がありますが、ツールセット全体をすべてのページに保持するのは面倒です。

最近、ライブラリを含めた後、実際に使用する機能の量を追跡するようになりました。 そして、私が最も頻繁に使用するツールはjQueryです。 多くの場合、1つまたは2つの機能（$.extendや$.readyなど）を使用したことがあります。さらに悪いことに、クラスまたはIDで要素を取得するためだけに使用したこともあります。 そのままにしておくこともあれば、コードに戻って依存関係を削除または分離することもあります。

結果に基づいて、ライブラリの何がどれだけ使用され、重量が減ったかを自動的に分析できたら、それは素晴らしいことではないでしょうか。

多くのライブラリとアプリケーションには、ロードアウトを使用する前にカスタマイズするオプションがあります。 しかし、私は、ライブラリで自動化された「使用するか失うか」のビルドアーキテクチャを標準化することは、私たちの手の届く範囲からそれほど遠くないはずだと感じ続けています。

「すべてを含める」アプローチにはアレルギーがあります。 しかし、このような機能と組み合わせて使用​​すると、プロトタイピングボードに似たアプローチに変わる可能性があります。構文だけでなく実際の機能自体も縮小される非常に柔軟な開発ツールです。

必要なのは、依存機能の単体テストを通じて、使用された機能のトレースを可能にし、最小限の依存関係または少なくとも使用率のスケールを出力するライブラリの開発専用バージョンです（たとえば、8％のjQueryを含めたかどうかを尋ねるなど）その機能の80％）。 次に、依存関係の出力を使用して、本番用の出力をチェリーピック、集約、および最小化できます。

しかし、私はそれについて何ができますか？

まず、問題に取り組みます。 それについて考え、同僚と話し合い、実際のシナリオで問題を見つけてください。

やってみよう。 あなたがどこかの引き出しに隠しておいたその最後の世代の電話を掘り出しなさい。 自分のWebサイトで使用してみて、コンテンツがリモートで使用できるかどうかを確認してください。 田舎にいる時代遅れの親戚を訪ねて、彼らの技術伝道者になってみてください。 テクノロジーの採用における彼らの遅れが、アクセシビリティの問題によって実際に促進されているかどうかを確認してください。

あなたがウェブサイトを試運転しているバイヤーであるならば、この問題に関して（少なくとも）低レベルのサポートを頼むことを忘れないでください。 注意：目標は、すべての機能を低レベルのデバイスに完全に移植することではありません。 求められているのは、それらのユーザーがデバイスをクラッシュさせるのではなく、連絡先情報を取得することだけです。

このための実際のリソースを取っておきます。この問題の最も簡単な解決策は、1日か2日以上かかることはなく、前向きな考えも必要です。 そもそもウェブサイトを作成する最も基本的な理由を覚えておいてください（レスポンシブサイトを作成することは言うまでもありません）。

ライブラリ、フレームワーク、バンドル、またはその他の埋め込み可能なソフトウェアに取り組んでいるパッケージ開発者の場合、ここで最も大きな違いを生むことができるのはあなたです。 これらの概念を促進したり、プラットフォームに組み込んだりできれば、Web開発の全体像に影響を与えることになります。 あなたがそれをあなたのパッケージデザインに組み込むならば、私に知らせてください、そして私はあなたのために伝道します。

そして最後に、**開発者またはデザイナー**の場合は、ベストプラクティスにとどまらないでください。 常にその地平線を少しだけ見渡すようにしてください。 クライアントとユーザーの利益のためにサポートされておらず、文書化されていない、まだ誰も求めていないこれらの概念を推進するのは大変な作業です。

最終的に、誰かがこれについて何時間も続けて、ザグレブの近くにいるのを聞きたい場合は、私に知らせてください。 私たちは一杯のコーヒーを飲みに行くことができました。