プリロードの利点は、Web ページをより速くユーザーに表示できることです。欠点は、無駄なリクエストが増加する可能性があることです (ただし、CSS や JS などの静的ファイルはキャッシュされる可能性があります)。ユーザーがアクセスするページに js が含まれ、画像がプリロードされるため、ユーザーはページをより速く開くことができ、ユーザー エクスペリエンスが向上します。いくつかの大きな画像を表示に使用する場合、大きな画像を事前にロードすることは、画像をより速くユーザーに表示できるようにするための非常に良い方法です。フロントエンド包囲マスターとして、私が行ったテストと結果を共有しましょう。
まず、知っておく必要があるサーバーから返されるステータス コードについて説明します。
ステータス コード: 200 - クライアント リクエストは成功しました。
ステータス コード: 304 - ファイルはすでにブラウザ内にあります。サーバーは、バッファされたドキュメントが引き続き使用できることが判明したことをクライアントに伝えます。
この記事は、ファイルがキャッシュされているかどうかを判断するためにテストされ、304 が返されるかどうかを判断するために使用されます。
以下は、主に new Image()、object、iframe などの img/js/css をさまざまなブラウザにロードすることによる、いくつかのプリロード メソッドのテストです。次の読み込みテスト用の js、css、および画像ファイルは、いくつかのポータル Web サイトから見つかりました (なぜいくつか見つけたのでしょうか? できるだけ多くの特殊な状況をテストするためであり、テスト中に実際にそれらの状況に遭遇しました)。
1. テスト用に new Image() をプリロードします
1.1. new Image() をロードします
コードをコピーします
説明: IE のキャッシュは Expires を設定する必要があります (また、設定時刻は現在時刻より大きくなければなりません)。FF は new Image() を使用したプリロードをサポートしていません。
1.3. new Image() を使用して js をロードするテスト
コードをコピーします
CM/OP、どちらも 304
FF を返しますが、5 だけが 304 を返し、5 だけの HTTP ヘッダーが最も単純です (日付、サーバー、有効期限、キャッシュ制御を含む)。
他の応答ヘッダーにはさらに多くのコンテンツがありますが、それらはすべて 5 つのセットに含まれています。パターンを探していると、他のいくつかの応答ヘッダーには Content-Type: text/javascript があることがわかりましたが、5 にはこれがありません。
IE、2/5 は 304 を返し、1/3/4 は 200 を返しました。応答ヘッダーを比較すると、IE の 2/5 では Content-Type の影響を受けるはずです。
さらに、Andrew Zhang (http://www.cnblogs.com/AndyWithPassion/) が、JS をプリロードしている画像を IE の httpwatch で表示すると、リソースのロードが完了していないことについて言及してくれたことに感謝します。ここでの私のテストでも同じことが当てはまります。テストではバイト制限があるようですが、2 つは完全なデータを返しましたが、5 つは内容の一部が失われました。したがって、新しいイメージを使用して JS をロードすることはまったくお勧めできません。
ここで要約すると、 new Image() を使用して画像をプリロードしても、互換性に問題はありません。ただし、css/js で動作できるのは OP/CM のみで、IE/FF は基本的に無効です（IE/FF はこれを暗黙の了解としています）。
2. オブジェクトのプリロードをテストします
var doc = document,
obj = doc.createElement('object');
//obj.data = '123.js'; //追記: この方法での記述は OP では無効になります。 (データが変更されます。コンテンツはオブジェクト タグのテキスト ノードとして使用されます)
// obj.setAttribute('data', '123.js'); ;top:-1px;width:1px;高さ：1px; ';
;トリガーロードのためにオブジェクトタグを挿入する必要があります。 / FF/OP/Webkit対応(データが画像の場合IE9も可能)
次に、オブジェクト内のデータを含むファイルをロードし、タグを作成して、テスト用に HTML に追加します。
FF/OP/CM: img/js/cssいずれでも304が返ります。
IE6-8: オブジェクトを使用して img/js/css をロードします。これは直接中止されます。IE9 は特別です:
IE9 は js/css をロードし、最初にリクエストして HTTP200 を返し、次にリクエストして中止します。ここでは実際には 1 つのリクエスト (2 回目は中止) を示します。
IE9 が img を読み込むとき、最初に HTTP200 を要求して返し、次に画像を要求して返すため、画像を 2 回要求する必要があります。
IE9 の最初のリクエストによって返されるコンテンツは空です (通常、ブラウザはこの時点でスタックするか直接応答を失います)。 IE9 はまず URL を要求し、ファイルの種類を取得します。JS/CSS の場合は中止され、画像の場合はロードされます。
興味深いことに、object を使用して JS をロードすると、IE9 がそれをロードできる場合があります。つまり、最初のリクエストではファイルが JS であるかどうかが判断されません (これを確認したいかどうかは運次第のようです)ネットワーク速度が遅い場合に発生する可能性があります)
以前、IE はファイルの種類を判断するためにファイルのサフィックスに依存していましたが、その後、HTTP ヘッダー情報を使用して判断したと言われていますが、これらは偽造される可能性があるため、IE ではオブジェクトにセキュリティ上の問題があります。
IE6/7では、ファイルの拡張子が.js/.cssの場合はリクエストが送信されません http://xxx/test.js?123.pngに変更するとリクエストが送信されます。送信して、scriptタグでインポートしたところ、キャッシュできることがわかりました(cssでもOK^^)。
余談: 上記のことから、IE のアップグレードによりセキュリティがますます高くなっていることがわかります。
したがって、ここでの結論は次のとおりです。FF/OP/CM ではオブジェクトのプリロードを使用できますが、IE では決して使用しないでください。
3. iframe のプリロードをテストします
まずページ a.html を作成し、次の js を追加します。
