Server_html/css_WEB-ITnose の YUI フロントエンドの最適化-htmlチュートリアル-php.cn

パート 2. Web サイトサーバー: コンテンツ配信ネットワークを使用して、ファイルヘッダーの Expires または Cache-ControlGzip 圧縮ファイルコンテンツを指定し、GET を使用して AJAX リクエストを完了します

11。コンテンツ配信ネットワークを使用する

ユーザーとあなた Web サイトサーバーの近さは、応答時間の長さに影響します。 Web サイトのコンテンツを地理的に異なる場所にある複数のサーバーに分散すると、ダウンロードを高速化できます。しかし、まず何をすべきでしょうか?

Web サイトのコンテンツを地理別に配置する最初のステップは、配布サーバー上で適切に動作するように Web サイトを再構築しようとすることではありません。アプリケーションのニーズに応じて Web サイトの構造を変更します。これには、サーバー間のセッションステータスの同期やデータベース更新のマージなど、より複雑なタスクが含まれる場合があります。ユーザーとコンテンツサーバー間の距離を縮めるために、これらのアーキテクチャ上の手順は避けられない場合があります。

エンドユーザーの応答時間の 80% ～ 90% は、画像、スタイルシート、スクリプト、Flash などのページコンテンツのダウンロードに費やされることに留意することが重要です。これはウェブサイトのパフォーマンスの黄金律です。アプリケーションのアーキテクチャを再設計するというより困難なタスクに取り組むよりも、最初に静的コンテンツを配布する方が良いでしょう。これにより、応答時間が短縮されるだけでなく、コンテンツ配信ネットワークへの実装も容易になります。

コンテンツ配信ネットワーク (CDN) は、地理的に異なる場所に分散された一連の Web サーバーで構成され、Web サイトのコンテンツの送信速度を向上させます。ユーザーにコンテンツを配信するために使用されるサーバーは、主にネットワーク上のユーザーへの近さに基づいて指定されます。たとえば、ネットワークホップが最も少なく、応答時間が最も速いサーバーが選択されます。

一部の大手インターネット企業は独自の CDN を持っていますが、Akamai Technologies、Mirror Image Internet、Limelight Networks などの CDN サービスの使用コストは非常に高くなります。立ち上げたばかりの企業や個人の Web サイトには CDN を使用するためのコスト予算がない可能性がありますが、ターゲットユーザーベースが拡大し続け、よりグローバルになるにつれて、迅速な対応を実現するには CDN が必要になります。 Yahoo の場合、CDN に転送した Web サイトプログラムの静的コンテンツにより、エンドユーザーの応答時間が 20% 以上節約されました。 CDN を使用すると、コードを変更するだけで Web サイトのアクセス速度を大幅に向上させる比較的簡単な方法です。

12. ファイルヘッダーに Expires または Cache-Control を指定します

このルールには 2 つの側面が含まれます:

静的コンテンツの場合: ファイルヘッダーの有効期限の値を「期限切れにしない」に設定します

動的コンテンツの場合: 適切なキャッシュを使用します- ブラウザーによる条件付きリクエストの作成を支援するファイルヘッダーの制御

Web コンテンツのデザインはますますリッチになっており、ページにはより多くのスクリプト、スタイルシート、画像、Flash を含める必要があります。ユーザーが初めてページにアクセスするときは、複数の HTTP リクエストを行うことになりますが、Expires ヘッダーを使用すると、このコンテンツをキャッシュ可能にすることができます。これにより、その後のページ訪問時に不要な HTTP リクエストが回避されます。 Expires ヘッダーは画像ファイルによく使用されますが、スクリプト、スタイルシート、Flash などを含むすべてのコンテンツに使用する必要があります。

ブラウザ (およびプロキシ) はキャッシュを使用して HTTP リクエストのサイズと数を減らし、ページアクセスを高速化します。 Web サーバーは、HTTP 応答の Expires ヘッダーを使用して、コンテンツをキャッシュする必要がある期間をクライアントに伝えます。以下の例は、より長い Expires ファイルヘッダーであり、この応答は 2010 年 4 月 15 日まで有効期限が切れないことをブラウザーに伝えます。

有効期限: Thu, 15 Apr 2010 20:00:00 GMT

Apache サーバーを使用している場合は、ExpiresDefault を使用して、現在の日付を基準にして有効期限を設定できます。次の例では、ExpiresDefault を使用して、リクエスト時刻から 10 年後に期限切れになるファイルヘッダーを設定します。

ExpiresDefault "access plus 10 years"

Expires ファイルヘッダーを使用する場合、ページが更新されたときにコンテンツを変更する必要があることに注意してください。内容のファイル名が変わります。 Yahoo! によると、コンテンツのファイル名にバージョン番号を追加するというこの手順をよく使用します (例: yahoo_2.0.6.js)。

Expires ヘッダーの使用は、ユーザーがすでに Web サイトにアクセスしている場合にのみ機能します。ユーザーが最初にサイトにアクセスしたときは、ブラウザーのキャッシュが空であるため、これは HTTP リクエストの数を減らすのには効果がありません。したがって、この方法による Web サイトのパフォーマンスの改善は、「事前キャッシュ」が存在する場合 (「事前キャッシュ」にはページ上のすべてのコンテンツがすでに含まれています) のページのクリック頻度に依存します。 Yahoo! は一連の測定方法を確立しており、全ページビューの 75 ～ 85% が「事前キャッシュ」されていることがわかりました。 Expires ヘッダーを使用すると、ブラウザーにキャッシュされるコンテンツの量が増加し、ユーザーを通じてリクエストを 1 バイトも送信しなくても、ユーザーからの後続のリクエストで再利用できるようになります。

13. Gzip 圧縮ファイルのコンテンツ

ネットワーク送信における HTTP リクエストと応答時間は、フロントエンドメカニズムによって大幅に改善できます。実際、エンドユーザーの帯域幅、インターネットプロバイダー、ピア交換ポイントへの近さなどは、Web サイト開発者が判断できるものではありません。ただし、応答時間に影響を与える要因は他にもあります。 HTTP 応答のサイズを減らすことで、HTTP 応答時間を節約できます。

HTTP/1.1 以降、Web クライアントはデフォルトで HTTP リクエストの Accept-Encoding ファイルヘッダーを使用した圧縮形式をサポートします:

Accept-Encoding: gzip、deflate

Web サーバーが要求されたファイルヘッダーコードで上記を検出した場合、応答コンテンツは、クライアントによってリストされた方法で圧縮されます。 Web サーバーは、応答ファイルヘッダーの Content-Encoding を通じて圧縮方法をブラウザに返します。

Content-Encoding: gzip

Gzip は、現在最も人気があり、最も効果的な圧縮方法です。これは GNU プロジェクトによって開発され、RFC 1952 によって標準化されました。他に圧縮形式はdeflateしかありませんが、利用範囲が限られており、効果も若干劣ります。

Gzip を使用すると、応答サイズを約 70% 削減できます。現在、ブラウザを通じて送信されるインターネット交換の約 90% が gzip 形式をサポートしています。 Apache を使用している場合、gzip モジュールの構成はバージョンによって異なります。Apache 1.3 は mod_zip を使用し、Apache 2.x は moflate を使用します。

ブラウザーとプロキシの両方にこの問題が発生します。ブラウザーが期待する受信内容と実際に受信する内容の間に不一致が発生します。幸いなことに、古いブラウザの使用が減少するにつれて、この特定のケースは減少しています。 Apache モジュールは、適切な Vary 応答ファイルヘッダーを自動的に追加することで、この状況を回避します。

サーバーはファイルの種類に基づいて gzip 圧縮する必要があるファイルを選択しますが、これにより圧縮できるファイルが過度に制限されます。ほとんどの Web サーバーは HTML ドキュメントを圧縮します。スクリプトとスタイルシートを圧縮することも行う価値がありますが、多くの Web サーバーにはこの機能がありません。実際、XML や JSON を含むあらゆるテキストタイプの応答を圧縮する価値があります。画像や PDF ファイルはすでに圧縮されているため、gzip 圧縮できません。これらのファイルを gizp しようとすると、CPU リソースが無駄になるだけでなく、ファイルサイズも増加します。

考えられるすべてのファイルタイプの Gzip 圧縮は、ファイルサイズを削減し、ユーザーエクスペリエンスを向上させる簡単な方法です。

14. ETag を設定する

エンティティタグ (ETag) (エンティティタグ) は、ブラウザキャッシュ内のコンテンツがサーバー内の元のコンテンツと一致するかどうかを判断するために Web サーバーとブラウザによって使用されるメカニズムです (「エンティティ」とは「コンテンツ」を意味します) 、画像、スクリプト、スタイルシートなどを含みます）。 ETag を追加すると、「最終変更日」を使用するよりも柔軟なエンティティ検証メカニズムが提供されます。 Etag は、コンテンツのバージョン番号を識別する一意の文字列です。形式上の唯一の制限は、二重引用符で囲む必要があることです。オリジンサーバーは、ETag ファイルヘッダーを含む応答を通じてページコンテンツの ETag を指定します。

HTTP/1.1 200 OK

Last-Modified: 火曜日、12 Dec 2006 03:03:59 GMT

ETag: "10c24bc-4ab-457e1c1f"

Content-Length: 12195

後で、ブラウザへファイルを検証すると、If-None-Match ファイルヘッダーを使用して ETag をオリジンサーバーに返します。この例では、ETag が一致すると 304 ステータスコードが返され、12195 バイトの応答が節約されます。 GET /i/yahoo.gif HTTP/1.1

ホスト: us.yimg.com

If-Modified-From: 火曜日、12 Dec 2006 03:03:59 GMT

If-None-Match: "10c24bc-4ab -457e1c1f"

HTTP/1.1 304 Not Modified

ETag の問題は、Web サイトが配置されているサーバーを識別できる一意の属性に基づいて ETag が生成されることです。ブラウザーが 1 つのサーバーからページコンテンツを取得し、それを別のサーバーで検証すると、ETag が一致しないという状況は、サーバーグループを使用してリクエストを処理する Web サイトでは非常に一般的です。デフォルトでは、Apache と IIS の両方が ETag にデータを埋め込むため、複数のサーバー間のファイル検証の競合が大幅に減少します。

Apache 1.3 および 2.x の ETag 形式は inode-size-timestamp です。ファイルが異なるサーバーの同じディレクトリにあり、ファイルサイズ、権限、タイムスタンプなどがまったく同じである場合でも、その内部コードもサーバーが異なると異なります。

IIS 5.0 と IIS 6.0 には、ETag を処理するための同様のメカニズムがあります。 IIS の ETag 形式は Filetimestamp:ChangeNumber です。 ChangeNumber を使用して IIS 構成の変更を追跡します。 ChangeNumber は、Web サイトで使用される IIS サーバーごとに異なります。異なるサーバー上の Apache と IIS によって生成される ETag は、まったく同じコンテンツであっても異なります。ユーザーは小さくて高速な 304 応答を受信せず、通常の 200 応答を受信してコンテンツ全体をダウンロードします。 Web サイトが 1 台のサーバー上にのみ配置されている場合、この問題は発生しません。ただし、Web サイトが複数のサーバー上にセットアップされており、Apache と IIS を使用してデフォルトの ETag 構成を生成している場合、ユーザーがページを取得するのに時間がかかり、サーバーはより多くのコンテンツを送信し、より多くの帯域幅を占有することになります。また、キャッシュも行われません。ウェブサイトのコンテンツを効果的に。コンテンツに Expires ヘッダーがある場合でも、ユーザーが [更新] または [再読み込み] ボタンをクリックするたびに、対応する GET リクエストが送信されます。

ETag が提供する柔軟な検証モードを使用しない場合は、すべての ETag を単純に削除することをお勧めします。 Last-Modified ファイルヘッダーの検証は、コンテンツのタイムスタンプに基づいて行われます。 ETag ファイルヘッダーを削除すると、応答と次のリクエストのファイルサイズが小さくなります。 Microsoft のこのサポートドキュメントでは、ETag を削除する方法が説明されています。 Apache では、次のコード行を構成ファイルに追加するだけです:

FileETag none

15. できるだけ早く出力バッファをフラッシュします

ユーザーがページをリクエストすると、200 ～ 500 時間がかかります。とにかくバックグラウンドで HTML ファイルを処理するためのミリ秒。この期間中、ブラウザはアイドル状態のままになり、データが返されるのを待ちます。 PHP では、flush() メソッドを使用できます。これにより、HTML 応答ファイルのコンパイルされた部分を最初にブラウザーに送信できるようになり、同時にブラウザーはファイル内のコンテンツ (スクリプトなど) をダウンロードできます。背景を同時に処理し、残りの HTML ページを処理します。この影響は、バックグラウンドでトラブルが発生したり、フロントデスクがアイドル状態になったりしたときに、より顕著になります。

出力バッファリングを適用する最適な場所はの直後です。これは、HTML のヘッダー部分は生成が簡単で、ヘッダーには CSS および JavaScript ファイルが含まれることが多いため、ブラウザーは残りの HTML をコンパイルできるからです。背景同時に並行してダウンロードします。例:

...

このテクノロジーを使用するメリットを証明するために、Yahoo! 検索は率先して調査を行い、ユーザーテストを完了しました。

16. GET を使用して AJAX リクエストを完了する

Yahoo! Mail チームは、XMLHttpRequest を使用する場合、ブラウザの POST メソッドは「2 段階」のプロセスであることを発見しました。最初にファイルヘッダーを送信し、次にデータを送信します。したがって、送信する必要があるのは 1 つの TCP パケットのみであるため、GET の使用が最も適切です (大量の Cookie がある場合を除く)。 IEのURLの最大長は2Kなので、2Kを超えるデータを送信したい場合はGETは使用できません。

興味深い違いは、POST は実際には GET のようにデータを送信しないことです。 HTTP 仕様によれば、GET はデータを「取得する」ことを意味するため、データを取得するだけの場合は GET を使用し、逆にサーバー側でデータを送信して保存する場合は POST を使用する方が (意味的に) 理にかなっています。