2

連結のポイントは、ダウンロードするファイルを 1 つだけにすることでパフォーマンスを向上させることですが、これは、独自の JavaScript を少し変更するたびに、変更されていない jQuery のような大きなライブラリを含め、パッケージ全体が再コンパイルされ、フィンガープリントが取得されることを意味します。個別にダウンロードできる場合はキャッシュされますが、統合された application.js の一部として毎回 jQuery が再ダウンロードされます。

ここで何が欠けていますか？2 つのマニフェストを作成するのが最善の方法ではないでしょうか? 1 つは独自のファイル (小さくて頻繁に変更される) 用で、もう 1 つはライブラリ (大きくて頻繁に変更されない) 用です。

4

1 に答える 1

4

私はそれを試してみます、その中にいくつかの憶測があります...

まず、JQuery は Rails 自体によって提供され、レイアウトによっては CDN から取得されます。それでは、時間の経過とともに変化する可能性のあるライブラリを見てみましょう。ここでのシナリオは何ですか？

  • ユーザーが初めて Web サイトにアクセスします。彼のブラウザー (タイプによって異なります) は、その下にあるものを表示する前に、すべての Javascript ファイルをロードする必要があります (したがって、最後に移動します)。ブラウザによっては、一度に 2 つ、4 つ、6 つ、または 8 つのリソースをロードする場合があります。サイトが数十または数百のリソースで構成されている場合、プレゼンテーションが遅くなります。
  • ユーザーが Web サイト (このページ) に 2 回目にアクセスしています。通常、同じ日、時間、または分です。全体がキャッシュされ、キャッシュされたものを使用できるという要求が 1 つだけあり、その場合は非常に高速です。すべてのリソース (数百) が次々に読み込まれる場合、キャッシュが有効な場合、数百のリクエストが発生します。
  • ユーザーが Web サイトに 2 回目にアクセスしており、その間に一定の時間がありました (15 日間としましょう)。変更されたリソースは 1 つだけで、他のすべてはキャッシュして再利用できました。それはどのくらいの確率ですか？
  • ユーザー (開発者) は、開発中に自分の作業にアクセスしています。すべての変更はすぐに通知される必要があるため、アセット パイプラインやキャッシュは使用されません。

したがって、Web サイトの観点からは、シナリオ 3 のみが (少し) 遅くなる可能性があり、最も可能性が低いと思います。通常、非常に多くのリクエストのオーバーヘッドは、リクエストのサイズよりもはるかに重要です。

時間があれば、すべてのリソースの読み込み時間を表示するツールを試してみてください。1 つのリソースが頻繁に変更されるため、アセット パイプラインに含めるべきではないエッジ ケースが存在する場合がありますが、通常、すべての変更には多数のリソースが含まれており、それらを 1 ビット BLOB としてキャッシュすると、多くのリクエストを回避するのに役立ちます。

これについて説明している文献への参照を次に示します。

于 2012-07-14T17:20:43.513 に答える