6

Rails 3.1 には、HTTP ストリーミングを有効にして、ページを分割して表示できるようにするオプションがあります。この機能に関する Railscast で、Ryan は、これを有効にして、ページの残りの部分がまだレンダリングされている間に CSS と JavaScript をプルダウンできるようにすることをお勧めしました。

私は常に、すべてのページ コンテンツが読み込まれた後にスクリプトをページの下部に配置して、読み込み時間を短縮するというガイドラインに従ってきましたが、これを行うことで HTTP ストリーミングを利用することはありません。

今のベストプラクティスは何だと思いますか？

4

3 に答える 3

2

これは素晴らしい質問だと思います。私が答えを求めてグーグルに強いられたと感じたもの。

スクリプトアセットをページの下部に配置するための議論は、ページの残りの機能がロードされている間、ユーザーをビジー状態に保つために画面にピクセルをペイントする可能性のあるブラウザーのレンダラーをブロックしないようにすることでした。HTTPストリーミングでは、サーバーがボトルネックになっていることについて何かできることについて話しています。これらの高価なデータベースクエリとバックエンドサービス呼び出しがすべて完了するのを待つ間、JS/CSSアセットをロードできます。

アセットを<head>するか、<head>しないかという転換点があるように思われます。これは、サーバーが残りの応答を準備する前にJS / CSSアセットをダウンロードできる場合にのみ、正味のパフォーマンスの向上になります。

次の場合は、ページのアセットを<head>しないでください。

  • サーバー側のキャッシュからページを提供しています
  • サーバーの応答時間は、JS / CSSの実際のアセットのロード時間よりも高速です（ロード時間を計算するときは、それらのアセットがクライアント側ですでにキャッシュされている可能性があるかどうかを慎重に検討してください）

次の場合は、ページのアセットを<head>してください。

  • サーバーは、待機中にすべてのJS/CSSアセットをロードするよりも応答に時間がかかります

それは正しいと思いますか？

于 2011-06-16T18:24:30.953 に答える
2

一般的なケースでは、残念なことに、彼らはまだ底を打っていると思います。その理由は、Mac 用の Safari は、アセットのリクエストの発行を開始する前に 1024 バイトをバッファリングするためです (iPhone および iPad 用の Safari は 512 バイトをバッファリングします)。

通常、ドキュメントのヘッドは小さいので、Safari ユーザーは通常の悪い経験をします。

Hongli Lai と一緒に行ったテストによると、Firefox、Opera、および IE8 はバッファリングせず、Chrome は 252 バイトをバッファリングします。

私はまだこれについて研究を行っていますが、これを書いている時点ではこれが私の結論です。

于 2011-06-16T19:04:30.247 に答える
1

主観的な質問に対する主観的な答え:

  • ライブラリ (および head 内の関数定義) はすべて静的アセットとして提供されるため、キャッシュできます。
  • スクリプト ブロックのページの下部にあるコールバックなどへの「トリガー」。
于 2011-05-24T20:34:53.080 に答える