1

現在、プログレッシブ エンハンスメントは、javascript を使用するブラウザー (拡張バージョン) と、javascript を使用しないブラウザー (単純なバージョン) に対応しているとほとんどの人が話しています。

しかし、ブラウザー間で JavaScript のパフォーマンスに大きな違いがあるため、ブラウザー間で JavaScript ベースの機能を選択する際に、この用語を適用すると便利な場合があります。

必須ではない多数の機能 (およびアニメーション) を備えた複雑な Web アプリでは、たとえば、これらの機能のセットはすべてのブラウザーで動作し、これらの機能のセットは Chrome と Safari でのみ動作するように、それらを封鎖することを検討する価値がありますか? 、およびこれらは Firefox と Chrome、Safari と Opera などにあります。これは、特定のブラウザーで特定の機能を有効にすると時間がかかりすぎるためです。

特定の重要でない機能にアクセスできなければ、ユーザー エクスペリエンスが向上するのではないかと感じることがあります。たとえば、Chrome ユーザーがサイズ変更できる特定のパネルのサイズを IE ユーザーが変更できないようにします。

4

7 に答える 7

1

私はこれを自分で行ったことはありませんが、予算が許せば非常に理にかなっていることがわかります (また、ユーザーのブラウザーの選択を制御することはできません)。

結局のところ、IE ユーザーは遅いブラウザーを使用しているかもしれませんが、それでもあなたのユーザーです。したがって、すべてのユーザーに可能な限り最高のユーザー エクスペリエンスを提供したい場合は、IE ユーザーに別のバージョンのアプリケーションを提供して、より高いレベルのパフォーマンスを提供することに時間を費やす価値があるかもしれません。

99% のユーザーにとって高速なアプリケーションは、30% のユーザーだけにとって高速なアプリケーションよりも間違いなく優れています。唯一の問題は、ユーザー エクスペリエンスと開発時間のどちらがより重要かということです (数年後には、平均的なユーザーがより高速なコンピューターでより高速なブラウザーを実行するようになることを考慮してください)。

ただし、私の経験では、コードのどの部分が遅く、どの部分が速いかに驚かされることが多いため、そのような作業はベンチマークによって推進する必要があります。

余談ですが、Lombardi Blueprintには非常に興味深いアプローチがありますが、GWT 以外ではおそらく非現実的です。Java で記述されたレイアウト アルゴリズムがあり、クライアント側 (GWT 経由) とサーバー側 (標準の jvm 経由) の両方で実行できるように記述されています。その結果、ブラウザのベンチマーク パフォーマンスに基づいて、クライアント側でのレイアウトの実行 (高速なブラウザの場合) とサーバー側でのレイアウトの実行 (遅いブラウザの場合) を動的に切り替えることができます。

于 2009-09-01T04:36:36.677 に答える
0

答えは、ブラウザの機能だけでなく、コードを速度のカテゴリに分類する必要があるということだと思います。

言い換えれば、サイトに機能の層を与えます。最初の層は基本的なhtml、2番目の層はjavascriptの使いやすさの向上、3番目の層はjavascriptアニメーションの目玉です。

次に、ユーザーが必要なときにいつでも階層を下げることができるようにする、「クリックしてアニメーションをオフにする」、「クリックしてアニメーションをオンにする！」、「クリックして基本的なHTMLで表示する」、デフォルトで速度上の理由からブラウザに基づく特定の速度カテゴリ（たとえば、IE7が完全なアニメーションをオンにした状態で速度の問題を示しているように見える場合は、デフォルトで2番目の「javascriptユーザビリティの向上」層に設定します）。

于 2010-02-10T19:43:33.177 に答える
0

では、まともなサイズのアプリケーションを構築するとしましょう。どの機能がオンになり、どの機能がオフになるかを判断するために、ブラウザ スニッフィングが豊富にあります。あなたは Opera 9.x を嗅ぎつけましたが、今 (実際には今日) Opera 10 が出てきました。すべてのページのすべてのスニファーを更新する必要があります。そして、すぐに別のブラウザが登場します...そして別のブラウザ。どのブラウザーをサポートし、どの機能をサポートするかを決定するために、すべての時間を費やすことになります。

1日に複数のブラウザを使用しています。そのため、あなたのサイトにアクセスすると、3 つの異なるインターフェイスが表示されます。そこにあると思っていた機能、または期待していた動作がそこにないので、私は混乱します。最終的にはイライラして、あなたのサイトには二度と行かなくなります。

また、一部の JavaScript の実行速度は、ブラウザーだけではありません。Firefox 3.5 を実行している古い Pentium をまだ持っています。場合によっては、痛々しいほど遅くなることがあります。

于 2009-09-01T12:52:02.900 に答える
0

それはメンテナンスの悪夢のように聞こえます。

HTML バージョンを使用する意味がない Web アプリケーションがいくつかあることに気付きました。そうは言っても、可能であれば、最初にすべてのページの html バージョンを作成することから始め、次に JavaScript を使用してユーザー エクスペリエンスを向上させたいと思います。

IE は、JS に関しては Safari、Chrome、および FF よりもパフォーマンスが劣ります。私はそれを見たことがありません-実際には、さまざまなJS実装が十分に高速であると思います.

于 2009-09-01T03:49:14.743 に答える
0

最近のブラウザには 2 つの異なる問題があります。

  1. スピード。私の経験では、IE 7 は問題なく動作しますが、他のものよりもはるかに遅いだけです。私の修正は、より頻繁に UI の進行状況をユーザーに更新することです。UI の更新には時間がかかるため、高速なブラウザーでの更新を最小限に抑えています。たとえば、IE では、さらに 50 個のイベントを処理した後、より多くのフィードバックで画面を更新します。他のブラウザの場合、200 イベントを処理した後。

  2. 機能の欠如。例えばキャンバス。しかし、複数のサイトを構築するには多額の費用がかかります。そして、それらもテストします。そのため、現在のすべてのデスクトップ ブラウザーに対して 1 つのバージョンに予算を費やしています。モバイル esp iPhone 用の追加サイトを作成します。

HTH、

ラリー

于 2009-09-01T03:50:34.167 に答える
0

私がしていることは、共通の機能を持つ基本的な javascript ファイルを作成することです。次に、より新しいバージョンの JavaScript 用の他のファイルを用意します。これらのファイルは、JavaScript オブジェクトの関数を置き換えて、サポートを徐々に追加できるようにします。

canvas タグを使用する場合は、IE と Firefox/Opera/Safari では canvas 要素の作成方法が異なるため、別のファイルに追加できます。

これはメンテナンスの喜びではありませんが、新しい html/javascript 機能を使用したい場合は、これが最適なモデルのようです。

于 2009-09-01T03:53:56.077 に答える
0

私はアンディに同意します。異なるブラウザに異なるバージョンのアプリケーションを提供することは、今後メンテナンスの問題になる可能性があります。私は常に、すべてのブラウザーで動作する 1 つのバージョンのアプリを提供する方が良いと考えています。たとえば、ブラウザ スニファを回避しようとします。このアプリケーションは最もクールなものではないかもしれませんが、誰にとっても機能し、保守も容易です。

この種の作業は、ブラウザの違いの一部を抽象化する気の利いた Javascript ライブラリのおかげで簡単になりました。その上、古いブラウザでも多くのことができます。それは単に「異なって」行われます;）

于 2009-09-01T06:05:56.717 に答える