要約: 仕事でも面接でも、Web フロントエンドのパフォーマンスを最適化することは非常に重要です。では、どのような側面から最適化を始める必要があるのでしょうか?フロントエンドの最適化では Yahoo の 34 の Catch-Rules に従うことができますが、現在では 35 になっているため、フロントエンドの最適化では Yahoo の Catch-35 であると言えます。分類されているので、最適化の方向性が明確になります。
コンテンツ部分1. HTTP リクエストの数を最小限に抑えるエンドユーザーの応答時間の 80% はフロントエンドで費やされており、その時間のほとんどは、画像、スタイルシート、スクリプト、Flash など、ページ上のさまざまなコンポーネントのダウンロードに費やされています。コンポーネントの数を減らすと、必然的にページによって送信される HTTP リクエストの数も減ります。これがページを高速化するための鍵です。
ページ コンポーネントの数を減らす 1 つの方法は、ページ デザインを簡素化することです。しかし、応答時間を短縮しながら複雑なページを構築する方法はあるのでしょうか?確かに、ケーキを持って食べる方法もあります。
ファイルを結合すると、すべてのスクリプトを 1 つのファイルにまとめることにより、リクエストの数が減ります。もちろん、すべての CSS を結合することもできます。各ページのスクリプトやスタイルが異なる場合、ファイルの結合は面倒な作業になる可能性がありますが、これをサイト公開プロセスの一部として実行すると、実際に応答時間を短縮できます。 CSS スプライトは、画像リクエストの数を減らすための推奨される方法です。すべての背景画像を 1 つの画像に統合し、CSS の背景画像プロパティと背景位置プロパティを使用して表示する部分を配置します。イメージ マッピングでは、複数のイメージを 1 つのイメージに結合できます。合計サイズは同じですが、リクエストの数が減り、ページの読み込みが高速化されます。画像マッピングは、ナビゲーション バーなど、画像がページ上で連続している場合にのみ役立ちます。イメージ マップの座標を設定するプロセスは退屈で間違いが発生しやすく、ナビゲーションにイメージ マップを使用するのは簡単ではないため、この方法はお勧めできません。インライン画像 (Base64 エンコード) は、 data: URL パターンを使用して画像をページに埋め込みます。これにより、HTML ファイルのサイズが大きくなりますが、(キャッシュされた) スタイル シートにインライン画像を配置すると、ページが重くなるのを回避できます。ただし、現在の主流のブラウザはインライン画像を十分にサポートしていません。ページの HTTP リクエストの数を減らすことが出発点となり、サイトへの最初のアクセス速度を向上させるための重要な指針となります。
2. DNS ルックアップを減らすドメイン名システムは、電話帳の名前と番号間のマッピングと同様に、ホスト名と IP アドレス間のマッピングを確立します。ブラウザに www.yahoo.com と入力すると、ブラウザは DNS リゾルバに問い合わせてサーバーの IP アドレスを返します。 DNS にはコストがかかり、特定のホスト名の IP アドレスを検索するには 20 ～ 120 ミリ秒かかります。 DNS ルックアップが完了するまで、ブラウザはホスト名から何もダウンロードできません。
DNS ルックアップは、ユーザーの ISP (インターネット サービス プロバイダー) またはローカル ネットワークによって特別なキャッシュ サーバーにキャッシュされると、より効率的にキャッシュされますが、個々のユーザーのコンピュータにキャッシュすることもできます。 DNS 情報は、オペレーティング システムの DNS キャッシュ (Microsoft Windows の DNS クライアント サービス) に保存されます。ほとんどのブラウザには、オペレーティング システムから独立した独自のキャッシュがあります。ブラウザがこのレコードをキャッシュに保持している限り、オペレーティング システムに DNS を問い合わせることはありません。
DnsCacheTimeout レジストリ設定に記述されているように、IE はデフォルトで DNS ルックアップを 30 分間キャッシュします。 Firefox は 1 分間キャッシュします。これは network.dnsCacheExpiration 構成項目を使用して設定できます。 (Fasterfox はキャッシュ時間を 1 時間に変更しました。PS Fasterfox は FF の高速化プラグインです)
クライアントの DNS キャッシュ (ブラウザおよびオペレーティング システムを含む) が空の場合、DNS ルックアップの数は、ページ URL、画像、スクリプト ファイル、スタイル シート、Flash オブジェクトなどを含む、ページ上のさまざまなホスト名の数と同じになります。ホスト名、異なるホスト名を減らすと、DNS ルックアップが減少します。
異なるホスト名の数を減らすと、ページが並行してダウンロードできるコンポーネントの数も減り、DNS ルックアップを回避すると応答時間が短縮されますが、並行ダウンロードの数を減らすと応答時間が長くなります。私のルールは、コンポーネントを 2 ～ 4 つのホスト名に分散することです。これは、DNS ルックアップの削減と、大量の同時ダウンロードの許可との間の妥協点です。
3. リダイレクトを避けるリダイレクトでは 301 および 302 ステータス コードが使用されます。次に、301 ステータス コードを含む HTTP ヘッダーを示します。
HTTP/1.1 301 Moved Permanently場所: http://example.com/newuriContent-Type: text/html
ブラウザは、[場所] フィールドに指定された URL に自動的にジャンプします。リダイレクトに必要な情報はすべて HTTP ヘッダーに含まれており、応答本文は通常は空です。実際、Expires や Cache-Control などの追加の HTTP ヘッダーもリダイレクトを表します。リダイレクトにはメタ タグと JavaScript を更新するという他の方法もありますが、リダイレクトを実行する必要がある場合は、主に「戻る」ボタンが適切に機能するように、標準の 3xx HTTP ステータス コードを使用するのが最善です。
リダイレクトによってユーザー エクスペリエンスが低下する可能性があることに注意してください。ユーザーと HTML ドキュメントの間にリダイレクトを挿入すると、HTML ドキュメントが配信されるまでページ上のすべての処理が遅延し、コンポーネントのダウンロードが開始されません。ブラウザ。
リソースを非常に無駄にする一般的なリダイレクトがありますが、Web 開発者は通常それに気づいていません。これは、URL の末尾にスラッシュが欠けている場合です。たとえば、http://astrology.yahoo.com/astrology にジャンプすると、http://astrology.yahoo.com/astrology/ にリダイレクトする 301 応答が返されます (末尾のスラッシュに注意してください)。 Apache では、Alias、mod_rewrite、または DirectorySlash 命令を使用して、不要なリダイレクトをキャンセルできます。
リダイレクトの最も一般的な用途は、古いサイトを新しいサイトに接続することです。また、同じサイトの異なる部分に接続し、ユーザーのさまざまな状況 (ブラウザーの種類、ユーザー アカウントの種類など) に応じて何らかの処理を実行することもできます。 。リダイレクトを使用して 2 つの Web サイトを接続するのが最も簡単で、必要な追加コードはほんの少量だけです。このようなときにリダイレクトを使用すると、開発者の開発の複雑さは軽減されますが、ユーザー エクスペリエンスは低下します。別の方法は、両方のコード パスが同じサーバー上にある場合、Alias と mod_rewrite を使用することです。ドメイン名が変更されるためにリダイレクトが使用される場合は、Alias または mod_rewrite ディレクティブと組み合わせて CNAME を作成する (エイリアスとして別のドメイン名を指す DNS レコードを作成する) ことができます。
4. Ajax をキャッシュ可能にするAjax の利点の 1 つは、バックエンド サーバーから情報を非同期に要求できるため、ユーザーに即時にフィードバックを提供できることです。ただし、Ajax では、非同期 JavaScript および XML 応答が返されるのを待っている間、ユーザーが退屈しないという保証はありません。多くのアプリケーションでは、ユーザーが待機できるかどうかは、Ajax の使用方法によって異なります。たとえば、Web ベースの電子メール クライアントでは、ユーザーは検索条件に一致する電子メール メッセージを見つけるために、Ajax リクエストによって返された結果に注目し続けることになります。非同期とは即時を意味するわけではないことに留意することが重要です。
パフォーマンスを向上させるには、これらの Ajax 応答を最適化することが重要です。 Ajax のパフォーマンスを向上させる最も重要な方法は、Expires または Cache-Control HTTP ヘッダーの追加で説明されているように、応答をキャッシュ可能にすることです。 Ajax には次の追加ルールが適用されます。
Ajax を使用してユーザーのアドレス帳をダウンロードし、オートコンプリート機能を備えた Web 2.0 電子メール クライアントの例を見てみましょう。ユーザーが最後に使用してからアドレス帳を変更しておらず、Ajax 応答がキャッシュ可能で、有効期限が切れていない Expires または Cache-Control HTTP ヘッダーがある場合、以前のアドレス帳をキャッシュから読み取ることができます。ブラウザーは、以前にキャッシュされたアドレス帳応答を引き続き使用するか、新しいアドレス帳応答を要求するかを通知する必要があります。これは、ユーザーのアドレス帳の最終変更時刻を示すタイムスタンプをアドレス帳の Ajax URL に追加することで実現できます (例: &t=1190241612)。前回のダウンロード以降アドレス帳が変更されておらず、タイムスタンプが変更されていない場合、アドレス帳はブラウザのキャッシュから直接読み取られるため、追加の HTTP ラウンド トリップが回避されます。ユーザーがアドレス帳を変更した場合、タイムスタンプによって、新しい URL がキャッシュされた応答と一致しないことが確認され、ブラウザは新しいアドレス帳エントリを要求します。
Ajax 応答は動的に作成され、単一のユーザーのみが使用できる場合でも、キャッシュすることができるため、Web 2.0 アプリケーションが高速になります。
5. コンポーネントの遅延ロードページをよく見て、「そもそもページをレンダリングするには何が必要か?」と自問してください。残りは待つことができます。
JavaScript は、onload イベントの前後を分離するのに理想的な選択肢です。たとえば、ドラッグ アンド ドロップとアニメーションをサポートする JavaScript コードとライブラリがある場合、ページが最初にレンダリングされた後にドラッグ アンド ドロップ要素が発生するため、これらは待機する可能性があります。遅延読み込みできるその他のセクションには、非表示のコンテンツ (インタラクションの後に表示されるコンテンツ) や折りたたまれた画像などがあります。
ツールは作業負荷の軽減に役立ちます。YUI Image Loader は折りたたまれた画像を遅延ロードでき、YUI Get ユーティリティは JS と CSS を簡単に取り込むことができます。 Yahoo! のホームページは一例です。Firebug のネットワーク パネルを開いて詳しく見てみましょう。
パフォーマンスの目標を、プログレッシブ エンハンスメントなどの他の Web 開発のベスト プラクティスと一致させることが最善です。クライアントが JavaScript をサポートしている場合、ユーザー エクスペリエンスを向上させることができますが、JavaScript がサポートされていない場合でもページが適切に動作することを確認する必要があります。したがって、ページが適切に動作していることを確認したら、遅延読み込みスクリプトを使用してページを強化し、ドラッグ アンド ドロップやアニメーションなどの派手な効果をサポートできます。
6. コンポーネントのプリロード
プリロードは遅延ロードの反対のように見えるかもしれませんが、実際には異なる目的があります。コンポーネントをプリロードすると、ブラウザのアイドル時間を最大限に活用して、将来使用されるコンポーネント (画像、スタイル、スクリプト) をリクエストできます。ユーザーが次のページにアクセスするとき、ほとんどのコンポーネントはすでにキャッシュ内にあるため、ユーザーの観点からはページの読み込みが速くなります。
実際のアプリケーションでは、次のタイプのプリロードがあります。
ページが複雑な場合、ダウンロードするバイト数が多くなり、JavaScript を使用して DOM にアクセスすると時間がかかります。たとえば、イベント ハンドラーを追加する場合、ページ上の 500 個の DOM 要素をループするのと、5,000 個の DOM 要素をループするのとでは違いがあります。
多数の DOM 要素は、ページ上にクリーンアップが必要な無関係なマークアップがあることを示しています。レイアウトにネストされたテーブルを使用していますか?それとも、レイアウトの問題を解決するためだけに <div> を大量に追加したのでしょうか?おそらく、より適切なセマンティック マークアップを使用する必要があります。
YUI CSS ユーティリティはレイアウトに非常に役立ちます。grids.css は全体的なレイアウトに使用され、fonts.css とreset.css はブラウザのデフォルトの書式設定を削除するために使用できます。これは、改行をレンダリングするためではなく、意味的に意味がある場合にのみ <div> を使用するなど、マークアップについてクリーンアップして考え始める良い機会です。
DOM 要素の数は、Firebug コンソールに次のように入力するだけで簡単にテストできます。
document.getElementsByTagName('*').lengthでは、多すぎる DOM 要素はいくつあるのでしょうか?たとえば、Yahoo! のホームページは非常に多いページですが、要素 (HTML タグ) は 700 未満です。
8. コンポーネントのクロスドメイン分離コンポーネントを分離すると、並列ダウンロードを最大化できますが、DNS ルックアップのペナルティがあるため、使用するドメインは 2 ～ 4 つまでにしてください。たとえば、HTML と動的コンテンツを www.example.org にデプロイし、静的コンポーネントを static1.example.org と static2.example.org に分離できます。
9. iframe の使用はできる限り少なくするiframe を使用すると、HTML ドキュメントを親ドキュメントに挿入できます。iframe の仕組みを理解し、効率的に使用することが重要です。
<iframe> の利点:
<iframe> の欠点:
HTTP リクエストは高価です。無駄な応答 (404 Not Found など) を取得するために HTTP リクエストを使用する必要はありません。ユーザー エクスペリエンスが低下するだけであり、何のメリットもありません。
一部のサイトでは、便利な「404 - xxx のことですか?」を使用しています。 , これはユーザーエクスペリエンスには有益ですが、サーバーリソース（データベースなど）も無駄にします。最悪の場合は、リンク先の外部 JavaScript にエラーが発生し、結果が 404 になることです。まず、このダウンロードは並列ダウンロードをブロックします。次に、ブラウザは 404 応答本文を解析しようとします。これは、404 応答本文が JavaScript コードであり、そのどの部分が利用可能かを調べる必要があるためです。
CSS部分11. CSS 式の使用を避けるCSS 式を使用して CSS プロパティを動的に設定することは、強力かつ危険な方法です。 IE5 からサポートされていますが、IE8 からは非推奨になりました。たとえば、CSS 式を使用して、時間ごとに背景色が切り替わるように設定できます。
背景色: 式( (new Date()).getHours()%2 ? #B8D4FF : #F08A00 );12. <link> を選択して @import を破棄します
ベスト プラクティスについては前述しました。プログレッシブ レンダリングを実現するには、CSS を先頭に配置する必要があります。
IE で @import を使用すると、下部にある <link> を使用したのと同じ効果があるため、使用しないことをお勧めします。
13. フィルターの使用を避けるIE 独自の AlphaImageLoader フィルターを使用すると、IE7 より前のバージョンでの半透明の PNG 画像の問題を修正できます。画像の読み込みプロセス中に、このフィルターはレンダリングをブロックし、ブラウザをフリーズし、メモリ消費量を増加させます。また、各画像ではなく各要素に適用されるため、多くの問題が発生します。
最善の方法は、AlphaImageLoader を使用せず、代わりに IE で十分にサポートされている PNG8 画像を使用するように正常にダウングレードすることです。 AlphaImageLoader を使用する必要がある場合は、IE7 以降のユーザーへの影響を避けるために、アンダースコア hack:_filter を使用する必要があります。
14. スタイルシートを一番上に置きますYahoo! でパフォーマンスを調査したところ、ドキュメントの HEAD セクションにスタイル シートを配置すると、ページの読み込みが速くなったように見えることがわかりました。これは、スタイル シートを head に配置すると、ページを徐々にレンダリングできるためです。
パフォーマンスを懸念しているフロントエンド エンジニアは、ページを段階的にレンダリングすることを望んでいます。言い換えれば、ブラウザーには既存のコンテンツをできるだけ早く表示する必要があります。これは、ページ上に大量のコンテンツがある場合、またはユーザーのインターネット接続が非常に遅い場合に特に重要です。ユーザーにフィードバック (進捗状況インジケーターなど) を表示することの重要性は広く研究され、文書化されています。私たちの場合、HTML ページが進行状況インジケーターです。ブラウザーがページ ヘッダー、ナビゲーション バー、トップ ロゴなどを徐々に読み込むと、これらはページの読み込みを待っているユーザーによるフィードバックとして使用され、全体的なユーザー エクスペリエンスを向上させることができます。
js部分15. 重複したスクリプトを削除する重複したスクリプト ファイルを含むページは、予想以上にパフォーマンスに影響を与える可能性があります。米国の上位 10 の Web サイトを調査したところ、重複したスクリプトが含まれていることが判明したのは 2 つのサイトだけでした。単一ページに重複したスクリプトが表示される可能性が高まる主な理由は 2 つあります。それは、チームの規模とスクリプトの数です。この場合、重複したスクリプトにより不要な HTTP リクエストが作成され、役に立たない JavaScript コードが実行され、ページのパフォーマンスに影響を与えます。
IE は不要な HTTP リクエストを生成しますが、Firefox は生成しません。 IE では、キャッシュ不可能な外部スクリプトがページによって 2 回導入されると、ページの読み込み時に 2 つの HTTP リクエストが生成されます。スクリプトがキャッシュ可能であっても、ユーザーがページをリロードすると追加の HTTP リクエストが生成されます。
無意味な HTTP リクエストを生成するだけでなく、スクリプトを複数回評価すると時間が無駄になります。スクリプトがキャッシュ可能かどうかに関係なく、Firefox と IE では冗長な JavaScript コードが実行されるためです。
同じスクリプトを誤って 2 回インポートすることを避ける 1 つの方法は、テンプレート システムにスクリプト管理モジュールを実装することです。スクリプトを導入する一般的な方法は、HTML ページで SCRIPT タグを使用することです。
<script type=text/javascript src=menu_1.0.17.js></script>16. DOM アクセスを最小限に抑える
JavaScript を使用して DOM 要素にアクセスすると非常に時間がかかるため、ページの応答性を高めるには、次のことを行う必要があります。
頻繁に実行されるイベント ハンドラーが DOM ツリーのさまざまな要素に追加されすぎているため、ページの応答性が十分でないように感じることがあります。これが、イベントの委任が推奨される理由です。 div 内に 10 個のボタンがある場合、ボタンごとに 1 つではなく、イベント ハンドラーを 1 つだけ div コンテナに追加する必要があります。イベントはバブルアップする可能性があるため、イベントをキャプチャして、どのボタンがイベントのソースであるかを知ることができます。
18. スクリプトを一番下に置きますスクリプトは並列ダウンロードをブロックします。公式の HTTP/1.1 ドキュメントでは、イメージが複数のホスト名から取得される場合、ブラウザーは 2 つを超えるコンポーネントを並列ダウンロードしないことが推奨されています。スクリプトをダウンロードしている場合、ブラウザは、別のホスト名であっても他のダウンロード タスクを開始しません。
場合によっては、スクリプトを一番下に移動するのが簡単ではないことがあります。たとえば、document.write を使用してスクリプトがページ コンテンツに挿入されている場合、それをさらに下に移動する方法はありません。スコープに関する問題が発生する場合もありますが、ほとんどの場合は解決できます。
一般的な提案は、遅延スクリプトを使用することです。DEFER 属性を持つスクリプトは、document.write を含めることができず、レンダリングを続行できることをブラウザーに通知することを意味します。残念ながら、Firefox は DEFER 属性をサポートしていません。 IE では、スクリプトは遅延される可能性がありますが、期待どおりには遅延されません。スクリプトを延期できる場合は、スクリプトをページの下部に移動すると、ページの読み込みが速くなります。
JavaScript、CSS 19. JavaScript と CSS を外部に置く多くのパフォーマンス原則は外部コンポーネントの管理方法に関係していますが、これらの懸念が生じる前に、より基本的な質問をする必要があります。JavaScript と CSS は外部ファイルに配置するべきか、それともページに直接記述するべきか?
実際、外部ファイルを使用すると、JavaScript ファイルと CSS ファイルがブラウザーにキャッシュされるため、ページが高速化されます。 HTML ドキュメント内のインライン JavaScript と CSS は、HTML ドキュメントが要求されるたびに再ダウンロードされます。そうすることで、必要な HTTP リクエストの数は減りますが、HTML ドキュメントのサイズは増加します。一方、JavaScript と CSS が外部ファイルにあり、ブラウザによってキャッシュされている場合は、HTTP リクエストの数を増やすことなく HTML ドキュメントを小さくすることに成功しました。
20. JavaScript と CSS を縮小する圧縮では、特にコードから不要な文字を削除してサイズを削減し、読み込み速度を向上させます。コードの最小化とは、すべてのコメントと不要な空白文字 (スペース、改行、タブ) を削除することを意味します。これを JavaScript で実行すると、ダウンロードされるファイルが小さくなるため、応答性が向上します。最も一般的に使用される 2 つの JavaScript コード圧縮ツールは JSMin と YUI Compressor で、CSS も圧縮できます。
難読化はオプションのソース コード最適化手段であり、圧縮よりも複雑であるため、難読化プロセスによってバグが発生する可能性も高くなります。米国の上位 10 の Web サイトを対象とした調査では、圧縮によってサイズを 21% 削減でき、難読化によってサイズを 25% 削減できます。難読化により高度な削減が可能になりますが、圧縮よりもリスクが高くなります。
外部スクリプトとスタイルの圧縮に加えて、インラインの <script> ブロックと <style> ブロックも圧縮できます。 gzip モジュールが有効になっている場合でも、最初に圧縮するとサイズを 5% 以上削減できます。 JavaScript や CSS が使用されることが多くなっているため、コードを圧縮すると良い効果が得られます。
写真21. 画像を最適化するGIF 形式を PNG 形式に変換して、スペースが節約されるかどうかを確認してください。すべての PNG 画像に対して pngcrush (または他の PNG 最適化ツール) を実行します。
22. CSSスプライトの最適化HTML で幅と高さを設定できるからといって、必要以上に大きな画像を使用しないでください。必要に応じて
<img width=100 height=100 src=mycat.jpg ホスト: us.yimg.com If-Modified-From: 火曜日、12 Dec 2006 03:03:59 GMT If-None-Match: 10c24bc-4ab-457e1c1f HTTP/ 1.1 304 未変更32. Ajax に GET リクエストを使用する
Yahoo! メールボックス チームは、XMLHttpRequest を使用する場合、ブラウザの POST リクエストが 2 段階のプロセスを通じて実装されることを発見しました。最初に HTTP ヘッダーを送信し、次にデータを送信します。したがって、(Cookie が多すぎる場合を除いて) TCP メッセージを送信するだけでよい GET リクエストを使用するのが最善です。 IE の最大 URL 長は 2K であるため、送信するデータが 2K を超える場合、GET は使用できません。
POST リクエストの興味深い副作用は、GET リクエストと同様に、実際にはデータが送信されないことです。 HTTP ドキュメントで説明されているように、GET リクエストは情報を取得するために使用されます。したがって、そのセマンティクスは GET リクエストを使用してデータをリクエストするだけであり、サーバーに保存する必要があるデータを送信することではありません。
33. できるだけ早くバッファをクリアするユーザーがページをリクエストすると、サーバーは HTML ページを組み立てるのに約 200 ～ 500 ミリ秒かかります。その間、ブラウザはアイドル状態になり、データの到着を待ちます。 PHP には、準備された HTML 応答の一部をブラウザに送信できる flash() 関数があり、ブラウザは残りの部分をバックグラウンドで準備しながらコンポーネントの取得を開始できるため、主に利点が反映されます。非常にビジーなバックグラウンドまたは非常に軽いフロントエンドの場合 (PS つまり、応答時間が主にバックグラウンドにある場合に利点が最もよく反映されます)。
バッファをクリアする理想的な場所は HEAD の後です。通常、HTML の HEAD 部分は生成が簡単で、CSS ファイルや JavaScript ファイルを導入できるため、バックグラウンドでの処理中にブラウザが並行してコンポーネントのフェッチを開始できるからです。 。
例えば：
... <!-- css, js --> </head> <?phplush() ?> <body> ... <!-- content -->;34. CDN (コンテンツ配信ネットワーク) を使用する
サーバーからユーザーの物理的な距離も応答時間に影響します。地理的に分散した複数のサーバーにコンテンツを展開すると、ユーザーはページをより速く読み込むことができます。しかし、どうやってそれを行うのでしょうか？
地理的に分散されたコンテンツを実現するための最初のステップは、分散構造に対応するために Web アプリケーションを再設計しようとしないことです。アプリケーションによっては、構造の変更には、セッション状態の同期やサーバー間でのデータベース トランザクションのレプリケーションなどの困難なタスクが含まれる場合があります (翻訳は正確ではない可能性があります)。ユーザーとコンテンツとの距離を縮めるための提案は、この難しさのために遅れたり、単に通過できなかったりする可能性があります。
エンド ユーザーの応答時間の 80% ～ 90% は、画像、スタイル、スクリプト、Flash などのページ コンポーネントのダウンロードに費やされることに注意してください。これはパフォーマンスの黄金律です。アプリケーションの構造を最初から再設計するよりも、まず静的コンテンツを分散させる方が良いでしょう。これにより、応答時間が大幅に短縮されるだけでなく、CDN の貢献を実証するのも容易になります。
コンテンツ配信ネットワーク (CDN) は、ユーザーにコンテンツをより効率的に配信するために、地理的に異なる場所に分散された Web サーバーのグループです。通常、コンテンツを配信するサーバーは、ネットワーク距離の尺度に基づいて選択されます。たとえば、ホップ数が最小であるか、応答時間が最も速いサーバーを選択します。
35. Expires または Cache-Control HTTP ヘッダーを追加するこのルールには 2 つの側面があります。
Web デザインはますますリッチになっており、ページ上にはより多くのスクリプト、画像、Flash が存在します。サイトへの新規訪問者は引き続きいくつかの HTTP リクエストを送信する必要がありますが、有効期限を使用することでコンポーネントがキャッシュ可能になり、その後の閲覧セッション中に不要な HTTP リクエストが回避されます。有効期限 HTTP ヘッダーは通常、画像で使用されますが、スクリプト、スタイル、Flash コンポーネントを含むすべてのコンポーネントで使用する必要があります。
ブラウザ (およびプロキシ) はキャッシュを使用して HTTP リクエストの数とサイズを減らし、ページの読み込みを高速化します。 Web サーバーは、Expiration HTTP 応答ヘッダーを使用して、ページの各コンポーネントをキャッシュする期間をクライアントに伝えます。遠い将来の時刻を有効期限として使用すると、この応答が 2010 年 4 月 15 日まで変更されないことがブラウザに伝わります。
有効期限: 2010 年 4 月 15 日(木) 20:00:00 GMT
Apache サーバーを使用している場合は、ExpiresDefault ディレクティブを使用して、現在の日付を基準にして有効期限を設定します。次の例では、リクエスト時点から 10 年間の有効期間を設定します。
期限切れデフォルトのアクセスに加えて 10 年
以上がこの記事の全内容です。皆様の学習のお役に立てれば幸いです。また、VeVb Wulin Network をご支援いただければ幸いです。