Webフロントエンド
レスポンシブデザインでは不十分です。レスポンシブパフォーマンスが必要です
最近、私はたくさんのことに遭遇しています レスポンシブウェブサイト と たくさん パフォーマンスの問題の。それらのほとんどで、問題は非常に明白であるため、最新世代のスマートフォン以外ではほとんど役に立たない。その事実を考慮して 即応性 概念は到達することを目的としているので より広い 聴衆、これはかなり逆効果のようです。
この問題の最大の原因は、依然として普及しているデスクトップファーストの設計パラダイムです。モバイルファーストの観点から考えると問題は解決するようですが、それだけでは満足のいくパフォーマンスが保証されるわけではありません。私たちは皆、多かれ少なかれ優雅な劣化に頼りすぎているようです。不足している機能を有効にするために、シムとポリフィルに依存しています。迅速な開発を可能にし、ブラウザーの互換性が問題になる場合に備えて、ライブラリに依存しています。
レスポンシブウェブサイトを装った、ゆるい電話キラー。 つぶやき
「なぜ心配するの？」あなたは尋ねるかもしれません。 「私たちの訪問者のほとんどは、最新のOSバージョンを実行している高性能のスマートフォンを持っています。彼らは私たちのサイトを扱うことができます。分析はそう言っています。」
ストローマンの議論については申し訳ありませんが、それは大声で述べるに値すると思います できる あなたのサイトを使用することはあなたのユーザーの大多数になります。分析にAndroid2.3が表示されない場合、それはそれらのデバイスを使用しているユーザーがいないことを意味しますか？それとも、あなたのサイトにはそれらのユーザーに提供するものが何もないということですか？その世代の多くのデバイスがまだ棚にあり、今日でも新品で購入されていることを考慮してください。昨年のテクノロジーとしてそれを完全に却下するべきではありません。
そこで、Web開発の理想的な事例と実際の目標についてお話したいと思います。そして、それらの目標に私たちを近づける実践とパラダイムについて。
ブリックファーストの設計パラダイム
年間の電話販売のかなりの部分は、依然としてフィーチャーフォンによって占められています。人口のさらに多くの部分が毎年電話を購入していませんが、それにもかかわらず、いくつかのWeb対応デバイスを所有しています。これらの数に、現在も使用されている最新世代のスマートフォンを追加し、Kindleやその他のWebセミ対応デバイス（WAPデバイス、テレビ、トースター、Tシャツ、レンガ）を追加します。それらをすべて合計すると、驚異的な合計に達する可能性があります。
このオーディエンスのユースケースを検討してください。彼らは自分のデバイスで長い記事を読んだり、閲覧したり、調査したりするつもりはありません。しかし、テンキーでURLを入力し、方向キーを使用してページをナビゲートして電話番号にアクセスしたり、その場でアドレスを再確認したりするという恐ろしさを経験するかもしれません。
それでは、機能とパフォーマンスの特定のしきい値を下回るデバイスにその情報のみを提供するサブモバイルファーストのレイアウトを実装することはどれほど難しいでしょうか。
ブロックチェーンゲームとは
優雅な改善
最小限のベストプラクティスとして優雅な劣化を使用して、それを超えて考えることを（ある程度）妨げるキャッチオール原則を作成しました。優雅な劣化が起こったら、私たちは確かに私たちの仕事が完了し、うまくいったと言うことができます。使用中のさまざまなフレームワークやライブラリですでにカバーされているため、考える必要がなくなることがよくあります。そして最後に、ポリフィルとシムは、場合によっては機能低下の必要性を完全に取り除きます。
この機能がますます容易に利用できるようになるにつれて、それについて考える必要性は（それを超えては言うまでもなく）ますます遠いものになります。
この記事の観点からは、次のように分類できます。
不潔な劣化： 機能がすぐに利用できない場合、実装は失敗し、使用できなくなったり、非常に非実用的な方法で使用できるようになります。
優雅な劣化： 機能がすぐに利用できない場合でも、許容できるユーザビリティを可能にする方法で失敗します。
不潔な改善： 機能がすぐに利用できない場合は、ポリフィルまたはシムによってエミュレートされます。
そこで、問題は解決しました。
同じローエンドデバイスのパフォーマンスを考慮しない限り、まあ。
若い兄弟の処理能力とデータ機能が不足しているため、彼らははるかに大きな負荷を運ぶように求められています。ポリフィルをソリューションとして採用すると、すべての最新機能がすべてのデバイスで利用可能になり、心配することなく使用できるという幻想が生まれます。
そして、あなたは実装します 近代化 万が一に備えて、すべてをポリフィルします。能力が最も低いデバイスは、最終的に最大量のデータをロードし、最大量の処理を実行します。したがって、「最高の」エンドユーザーエクスペリエンスを保証します。
w2 vsc2cレート計算機シブ、シム、ポリフィル？ほとんどのスマートフォンはFlashをサポートしていません。 つぶやき
優雅な改善のアイデアは、最低の機能要件から始めて、デバイスの機能に基づいてパフォーマンスとユーザビリティのバランスが最適になるまでアップグレードをロードすることによって、概念を逆転させます。したがって、データトラフィックと処理の要件は、それらを処理するのに最適なデバイスに移動されます。
確かに、現時点では、概念は非常に複雑です。ほとんどのフレームワークとライブラリでサポートされておらず、ほとんど議論されておらず、そのようなプラクティスへの参照はほとんどなく、離れており、マイクロ機能にローカライズされています。しかし、ある時点で、それはすべての概念と機能でそのようになりました。
できますが、そうする必要がありますか？
Web開発のもう1つのベストプラクティスは、デバイスをアクティブ化する前に、その機能がデバイスで利用可能かどうかを確認することです。
ただし、古いAndroidスマートフォンに最新バージョンのGoogle Chromeをインストールできることを考慮に入れると、実行可能であると主張されます。 CSSアニメーション 、 WebGL 、背景視差効果、および他の多くの機能。しかし、それは本当に、 本当に 、できません。ブラウザがクラッシュし、デバイス全体が応答しなくなり、制御を取り戻すために再起動する必要があります。
この問題は最近影響を及ぼし始めています Androidアプリケーション 大きな意味で（ユーザーの観点から）。この意味で最も顕著な劣化の1つは、Googleトーク/ハングアウトアプリのアップグレードに影響を及ぼし、古いデバイスのパフォーマンスの問題により、サービスが利用可能な最も軽量なチャットアプリケーションからほとんど使用できないアプリケーションに変わりました。 （この点をもう一度強調してください。ここで「古い」とは、ほとんどすべての店舗で新品の既製のものを購入できることを意味します）。同じ問題 YouTubeアプリに影響を与えました とTwitterアプリ（私の経験では）と明らかに他の多く。
したがって、計画段階のある時点で、最先端の構成に対する高性能のコア機能の価値を評価してください。または、少なくとも、レガシーユーザーが何らかの形でアプリ/サービス/コンテンツの最後の世代を利用できるようにしておきます。そういえば…
ユーザーにブリーディングエッジからオプトアウトさせる
古いデバイスから、または接続不良でGmailを使用しようとしたことがありますか？それ 「基本的なHTMLを読み込む」リンク 確かに重宝します。
最先端のレスポンシブでアニメーション化されたタッチ指向のオンラインストアフロントにその機能がないのはなぜですか？
考えてみてください。より多くの潜在的な顧客にリーチできるように、応答性を要求しました。あなたは最高の第一印象を残すためにそれを最先端にしました。その結果、潜在的な顧客があなたやあなたのサービスに関する基本的な情報にさえ到達することができなくなります。優雅な改善があなたにとってコストがかかりすぎる概念である場合、少なくとも訪問者にあなたのコンテンツのテキストのみのバージョンにアクセスするオプションを提供しませんか？ 「WOW」バージョン 彼らのデバイスには多すぎます。
あなたは本当に図書館全体が必要ですか？
最後に、標準を少し超えてプッシュしてもらいたい最後のベストプラクティスは、「使用するか失うか」です。どのライブラリとモジュールが実際に使用されているかを追跡し、それらだけを含めるのは面倒な場合がありますが、ツールセット全体をすべてのページに保持するのは面倒です。
最近、ライブラリを含めた後、実際に使用する機能の量を追跡するようになりました。そして、私が最も頻繁に使用するツールは jQuery 。多くの場合、1つまたは2つの機能（$ .extendや$ .readyなど）を使用したことがあります。さらに悪いことに、クラスまたはIDで要素を取得するためだけに使用したこともあります。そのままにしておくこともあれば、コードに戻って依存関係を削除または分離することもあります。
adobe xdvsスケッチ2018
結果に基づいて、ライブラリの何がどれだけ使用され、重量が減ったかを自動的に分析できたら、それは素晴らしいことではないでしょうか。
多くのライブラリとアプリケーションには、ロードアウトを使用する前にカスタマイズするオプションがあります。しかし、私は、ライブラリで自動化された「使用するか失うか」のビルドアーキテクチャを標準化することは、私たちの手の届く範囲からそれほど遠くないはずだと感じ続けています。
「すべてを含める」アプローチにアレルギーがあります。しかし、そのような機能と組み合わせて使用すると、プロトタイピングボードに似たアプローチに変わる可能性があります。構文だけでなく実際の機能自体も縮小される非常に柔軟な開発ツールです。
必要なのは、依存機能の単体テストを通じて、使用された機能のトレースを可能にし、最小限の依存関係または少なくとも使用率のスケールを出力するライブラリの開発専用バージョンです（たとえば、jQueryを8％含めたかどうかを尋ねるなど）その機能の80％）。次に、依存関係の出力を使用して、本番用の出力をチェリーピック、集約、および最小化できます。
しかし、私はそれについて何ができますか？
まず第一に、 問題に取り組む 。それについて考え、仲間と話し合い、現実のシナリオで問題を見つけてください。
やってみよう。 あなたがどこかの引き出しに隠しておいたその最後の世代の電話を掘り出しなさい。自分のWebサイトで使用してみて、コンテンツがリモートでも使用できるかどうかを確認してください。田舎にいる時代遅れの親戚を訪ねて、彼らの技術伝道者になってみてください。テクノロジーの採用における彼らの遅れが、アクセシビリティの問題によって実際に促進されているかどうかを確認してください。
あなたが買い手なら ウェブサイトを試運転するときは、この問題について（少なくとも）低レベルのサポートを依頼してください。注意：目標は、すべての機能を低レベルのデバイスに完全に移植することではありません。求められているのは、それらのユーザーがデバイスをクラッシュさせるのではなく、連絡先情報を取得することだけです。
このための実際のリソースを取っておきます。この問題の最も簡単な解決策は、1日か2日以上、前向きな考えを持ってはいけません。そもそもウェブサイトを作成する最も基本的な理由を覚えておいてください（レスポンシブサイトを作成することは言うまでもありません）。
パッケージ開発者の場合 ライブラリ、フレームワーク、バンドル、またはその他の埋め込み可能なソフトウェアに取り組んでいます。ここで最大の違いを生み出すことができるのはあなたです。これらの概念を促進したり、プラットフォームに組み込んだりできれば、Web開発の全体像に影響を与えることになります。パッケージデザインに組み込む場合は、お知らせください。伝道します。
そして最後に、**あなたが 開発者 または デザイナー** 、ベストプラクティスだけにとどまらないでください。常にその地平線を少しだけ見渡すようにしてください。クライアントとユーザーの利益のためにサポートされておらず、文書化されていない、まだ誰も求めていないこれらの概念を推進するのは大変な作業です。
最終的に、誰かがこれについて何時間も続けて、近くにいるのを聞きたい場合 ザグレブ 、 お知らせ下さい。私たちは一杯のコーヒーを飲みに行くことができました。
