この投稿を読み終えたところです: https://developer.yahoo.com/performance/rules.html#flushで、ページの上部 (head、css、top banner/search/nav) が読み込まれた後にフラッシュを既に実装しています。 .
フラッシュでパフォーマンスに影響はありますか? やりすぎということはありませんか？ベストプラクティスは何ですか?
データの外部 API をヒットする場合、ユーザーがそのデータが戻ってくるのを待たずに、少なくともいくつかのデータを事前に取得できるように、事前にフラッシュすることは理にかなっていますか?
説明されている手法は良さそうに見えますが、いくつかの落とし穴があります。
1) PHP スクリプトの開始から終了までの時間が送信時間に比べて短い。また、ソースによると、これによりユーザーは約0.5秒節約されます。それはあなたにとってかなりの時間ですか？
2) この手法は、gzip 出力バッファリングでは機能しません。
3) 頻繁にフラッシュすると、フラッシュ時にほとんど空のパケットを送信することになり、実際には読み込み時間が長くなる可能性があります (低速でノイズの多い接続では)。
4) フラッシュすると、それ以上ヘッダーを送信できなくなります
5) (軽微な問題) サーバーの応答はチャンク エンコーディングで送信されます。つまり、クライアントは事前にサイズを認識できません (したがって、ファイルのダウンロード時に「x% 完了」とは表示されません)。
一方、スクリプトが非常に長い時間 (20 秒以上) 実行されることが予想される場合は、ブラウザーが接続をタイムアウトにしないようにするために、データ (スペースなど) を送信する必要がある場合があります。
欠点は、コンテンツを gzip するだけでなく、フラッシュすることもできないことです。
より多くのデータをパディングすることはあまり役に立たないように思われるため、これは考えられません。
フラッシュは本当に微調整メカニズムだと思います。ブラウザーは、コンテンツのダウンロードに約 8 スレッドしか使用しません (ブラウザーによって異なります)。15 個の画像がある場合、ブラウザは 8 個の画像のダウンロードを開始し、そのうちの 1 つが完了するまで他の画像をダウンロードしません。その後、次の画像のダウンロードを開始します。ヘッダーの後にフラッシュすることで、基本的にブラウザに何を伝えますか?ダウンロードを開始できます。ページの残りの部分が配信されるまでに (つまり 0.5 秒後)、ブラウザーは css ファイルと javascript ファイルのダウンロードを既に終了している可能性があります。これにより、他のコンテンツのダウンロード スレッドが解放されます。
おそらく、ヘッダーの直後以外の場所でフラッシュを使用したくないでしょう。ブラウザーは通常、閉じられていない html タグをレンダリングしないため、部分的なページを配信しても、表示が速くなりません。古いバージョンの IE では、一定量のデータが受信されるか、ページの配信が完了するまで、何も表示されません。
Piskvor の指摘に従ってください - 20 秒以上の待機が予想される場合は、基本的なページ (gzip できる) を提供し、遅いプロセスが終了したときに Ajax を使用してページを更新する方がよい場合があります。ただし、静的 html の基本的な有用性を侵害し始めています。