14 Yahoo 最適化原則_html/css_WEB-ITnose

Web アプリケーションのパフォーマンス最適化の黄金律: フロントエンド プログラム (フロントエンド) のパフォーマンスを最初に最適化します。これは、エンドユーザーの応答時間の 80% 以上がここに費やされるためです。

ルール 1: HTTP リクエストの数を減らす
エンドユーザーの応答時間の 80% がフロントエンド プログラムに費やされ、その時間のほとんどは画像、スタイルシート、スクリプト、Flash などのさまざまなページ要素のダウンロードに費やされます。ページ要素を減らすと、HTTP リクエストの数が減ります。これはページを素早く表示するための鍵です。ページ要素の数を減らす 1 つの方法は、ページ デザインを簡素化することです。しかし、豊富なコンテンツと高速な応答時間の両方を実現する他の方法はあるのでしょうか?そのようなテクニックをいくつか紹介します。 イメージ マップ、複数のイメージを 1 つのイメージに結合します。合計ファイルサイズはあまり変わりませんが、HTTPリクエストの数が減り、ページの表示速度が速くなります。この方法は、画像が連続している場合にのみ適しており、座標の定義は面倒で間違いが発生しやすい作業です。 CSS スプライトの方が良い方法です。ページ上の画像を 1 つのファイルに結合し、CSS の背景画像プロパティと背景位置プロパティを使用して画像の必要な部分を実現できます。インライン画像は data: URL スキームを使用してページに画像を埋め込みます。これにより、HTML ファイルのサイズが大きくなります。インライン画像を (キャッシュされた) スタイルシートに結合すると、HTML ファイルのサイズを増やさずに、HTTP リクエストの数を減らすことができます。ファイルを結合すると、複数のスクリプト ファイルが 1 つのファイルに結合されるため、HTTP リクエストの数が削減されます。スタイルシートも同様の方法で処理できます。この方法は単純ですが、大規模には使用されていません。アメリカの Web サイトには、ページごとに平均 7 つのスクリプト ファイルと 2 つのスタイル シートがあります。スクリプトとスタイルシートがページごとに大幅に異なる場合、このアプローチは困難になる可能性がありますが、これを実行すると応答時間を短縮できます。 HTTP リクエストの数を減らすことがパフォーマンス最適化の出発点です。これは、初回訪問の効率を向上させる上で重要な役割を果たします。 Tenni Theurer の記事「ブラウザ キャッシュの使用状況が明らかに?」では、データへの毎日のアクセスの 40 ～ 60% が初回訪問であるため、初回訪問者のページ アクセスを高速化することがユーザー エクスペリエンスの鍵であると説明しています。

ルール 2: CDN (コンテンツ配信ネットワーク、コンテンツ配信ネットワーク) を使用する

Web サーバーからのユーザーの距離も、応答時間に大きな影響を与えます。ユーザーの観点から見ると、地理的に分散した複数のサーバーにコンテンツを展開すると、ページの読み込み速度が効果的に向上します。しかし、どこから始めればよいのでしょうか?

コンテンツの地理的配布に向けた最初のステップとして、配布アーキテクチャに合わせて Web アプリケーションをリファクタリングしようとしないでください。アーキテクチャを変更すると、セッション状態の同期や複数のサーバー間でのデータベース トランザクションの複製など、複数の定期的なタスクが発生します。ユーザーとコンテンツの間の距離を縮めようとするこのような試みは、アプリケーション アーキテクチャの変更によって遅延またはブロックされる可能性があります。また、エンドユーザーの応答時間の 80 ～ 90% が、画像ファイル、スタイルシート、スクリプト、Flash など、ページ内のさまざまな要素のダウンロードに費やされていることも覚えています。システムのリファクタリングという困難な作業に時間を費やす代わりに、まず静的コンテンツを配布します。これにより応答時間が大幅に短縮されるだけでなく、CDN のおかげで静的コンテンツの配布が非常に簡単に実装できます。 CDN は、コンテンツをより効率的に公開するために使用される、地理的に分散された Web サーバーの集合です。特定のユーザーにサービスを提供する Web サーバーは、通常、ネットワークの距離に基づいて選択されます。一部の大規模な Web サイトは独自の CDN を持っていますが、Akamai Technologies、Mirror Image Internet、Limelight Networks などの CDN サービス プロバイダーのサービスを使用する方がコスト効率が高くなります。 Yahoo! では、静的コンテンツを CDN に配信することで、ユーザーへの影響時間が 20% 以上短縮されました。コードを変更して CDN に切り替えるのは簡単ですが、Web サイトの速度を向上させることができます。

ルール 3: Expires ヘッダーを追加する
Web コンテンツはますます豊富になっており、スクリプト ファイル、スタイル シート、画像ファイル、Flash が増えています。初めての訪問者は複数の HTTP リクエストに直面する必要がありますが、Expires ヘッダーを使用することで、これらの要素をクライアント側でキャッシュできます。これにより、その後のアクセス時に不要な HTTP リクエストが回避されます。 Expires ヘッダーは画像ファイルで最も一般的に使用されますが、スクリプト ファイル、スタイルシート、および Flash でも使用する必要があります。ブラウザ (およびプロキシ) はキャッシュを使用して HTTP リクエストの数とサイズを減らし、Web ページの読み込みを高速化します。 Web サーバーは、Expires ヘッダーを通じて要素をキャッシュできる期間をクライアントに伝えます。サーバーが Apache の場合、次のように ExpiresDefault を使用して現在の日付に基づいて有効期限を設定できます。 ExpiresDefault "access plus 10 years" は、有効期限をリクエスト時刻から 10 年に設定します。非常に長い有効期限を使用すると、コンテンツが変更されたときにファイル名を変更する必要があることに注意してください。 Yahoo! では、リリースの段階で名前を変更することがよくあります。バージョン番号は yahoo_2.0.6.js のようにファイル名に埋め込まれます。

ルール 4: ページ要素を圧縮する
HTTP 応答コンテンツを圧縮することで、ページの応答時間を短縮します。 HTTP/1.1 以降、Web クライアントは、HTTP リクエストの Accept-Encoding ヘッダーを通じて、次のようなサポートされている圧縮タイプを示します。

Accept-Encoding: gzip、deflate Web サーバーが Accept-Encoding ヘッダーをチェックすると、クライアントがサポートするメソッドを使用して HTTP 応答を圧縮し、Content-Encoding: gzip などの Content-Encoding ヘッダーを設定します。 Gzip は現在最も一般的で効果的な圧縮方法です。 deflate などの他の方法は効果が低く、十分に普及していません。 Gzip を使用すると、通常、コンテンツは 70% 削減されます。 Apache の場合、バージョン 1.3 では mod_gzip モジュールを使用する必要があり、バージョン 2.x では mod_deflate を使用する必要があります。 Web サーバーは、ファイルの種類に基づいて圧縮するかどうかを決定します。ほとんどの Web サイトは HTML ファイルを圧縮します。ただし、スクリプト ファイルやスタイルシートを圧縮することも価値があります。実際、XML や JSON を含むタスクのテキスト情報を圧縮することには価値があります。画像ファイルと PDF ファイルは本質的に圧縮されているため、圧縮しないでください。圧縮すると CPU を浪費するだけでなく、ファイル サイズが増加する可能性があります。したがって、できるだけ多くの種類のファイルを圧縮することは、ページ サイズを削減し、ユーザー エクスペリエンスを向上させる簡単な方法です。

ルール 5: スタイル シートを head セクションに配置する
スタイル シートを HEAD セクションに移動すると、インターフェイスの読み込み速度が向上することがわかり、これによりページ要素を順番に表示できるようになります。 IE などの多くのブラウザでは、スタイル シートをドキュメントの下部に配置すると、Web コンテンツの連続表示が妨げられるという問題があります。ブラウザーはページ要素の再描画を避けるために表示をブロックするため、ユーザーには空白のページのみが表示されます。 Firefox は表示をブロックしませんが、スタイルシートのダウンロード後に一部のページ要素を再描画する必要があり、ちらつきの問題が発生する可能性があることを意味します。 HTML 仕様では、スタイル シートを HEAD で定義することが明確に要求されているため、空白の画面やちらつきの問題を回避するには、HTML 仕様に従い、スタイル シートを HEAD に配置するのが最善の方法です。

ルール 6: スクリプト ファイルを一番下に配置する
スタイル ファイルと同様に、スクリプト ファイルの場所に注意する必要があります。それらをページの一番下に配置して、順番に表示して最大限の並列ダウンロードを実現できるようにする必要があります。ブラウザはスタイルシートがダウンロードされるまで表示をブロックするため、HEADセクションにスタイルシートを置く必要があります。スクリプトの場合、スクリプトの後ろにあるコンテンツの連続表示がブロックされるため、スクリプトをできるだけ下に配置すると、より多くのコンテンツを迅速に表示できます。このスクリプトによって引き起こされる 2 番目の問題は、並列ダウンロードの数がブロックされることです。 HTTP/1.1 仕様では、ブラウザーがホストごとの並列ダウンロード数を 2 つ以下に制限することを推奨しています。したがって、イメージ ファイルを複数のマシンに配布すると、2 つを超える並列ダウンロードを実現できます。ただし、スクリプト ファイルがダウンロードされると、ブラウザは他の並行ダウンロードを開始せず、他のホストからのダウンロードも開始しません。場合によっては、スクリプトを一番下に移動するのが簡単ではありません。たとえば、スクリプトは document.write メソッドを使用してページ コンテンツを挿入します。ドメインの問題も考えられます。しかし多くの場合、まだいくつかの方法があります。別の方法は、遅延スクリプトを使用することです。 DEFER 属性は、スクリプトに document.write が含まれていないことを示し、ブラウザーに直ちに表示を続けるよう指示します。残念ながら、Firefox は DEFER 属性をサポートしていません。 IE では、スクリプトが遅延する場合がありますが、必ずしも必要なだけ遅延するわけではありません。一方、スクリプトを遅らせることができる場合は、一番下に配置できます。

ルール 7: CSS 式を避ける
CSS 式は、CSS プロパティを動的に設定する強力な (そして危険な) 方法です。 IE は、backgourd-color:expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”) など、バージョン 5 以降の CSS 式をサポートしています。つまり、背景色は 1 時間ごとに切り替わります。 。 CSS 式の問題は、多くの人が望むよりも多くの回数実行されることです。式は、ページが表示されサイズ変更されたときだけでなく、ページがスクロールされたときやマウスがページ上に移動したときも評価されます。 CSS 式の実行回数を減らす 1 つの方法は、初回実行時に式を明示的な値に置き換えるワンショット式を使用することです。動的に設定する必要がある場合は、代わりにイベント ハンドラーを使用できます。 CSS 式を使用する必要がある場合は、CSS 式が何千回も実行され、ページのパフォーマンスに影響を与える可能性があることに注意してください。

ルール 8: 外部ファイルに JavaScript と CSS を配置する

上記のパフォーマンス最適化ルールの多くは、外部ファイルに基づいて最適化されます。ここで、JavaScript と CSS は外部ファイルに含めるべきか、それともページ ファイルに含めるべきかという質問をする必要があります。実際の世界では、外部ファイルはブラウザによってキャッシュされるため、外部ファイルを使用するとページの表示が高速化されます。 JavaScript と CSS がページに組み込まれている場合、HTTP リクエストの数は減りますが、ページのサイズは増加します。一方、外部ファイルを使用するとブラウザによってキャッシュされるため、HTTP リクエストの数を増やすことなくページ サイズが削減されます。したがって、一般的に言えば、外部ファイルを使用する方がより現実的な方法です。唯一の例外は、Yahoo! と My Yahoo! などのホームページではインライン方式の方が効果的です。一般に、セッション中は現時点ではホームページへのアクセスが少ないため、インライン方式の方がユーザーの応答時間を短縮できます。

ルール 9: DNS クエリの数を減らす
DNS はホスト名と IP アドレスのマッピングに使用されます。通常、解決には 20 ～ 120 ミリ秒かかります。より高いパフォーマンスを実現するために、DNS 解決は通常、ISP または LAN によって維持されるキャッシュ サーバーや、ローカル マシンのオペレーティング システム (Windows の DNS クライアント サービスなど) のキャッシュなど、複数のレベルでキャッシュされます。ブラウザの DNS キャッシュ時間は 30 分、Firefox のデフォルトのバッファ時間は 1 分です。 IE でホスト名を減らすと DNS クエリの数を減らすことができますが、並列ダウンロードの数が減る可能性があります。 DNS クエリを回避すると応答時間が短縮される可能性がありますが、並列ダウンロードの数を減らすと応答時間が長くなる可能性があります。実行可能な妥協策は、コンテンツを少なくとも 2 つ、最大 4 つの異なるホスト名に分散することです。

ルール 10: JavaScript コードを最小限に抑える

JavaScript コードを最小限に抑えるとは、JS コード内の不要な文字を削除し、それによってダウンロード時間を短縮することを意味します。よく使用される 2 つのツールは、JSMin と YUI Compressor です。難読化は、ソース コードを最小限に抑えるための代替手段です。 minify と同様に、コメントや空白を削除してソース コードのサイズを削減し、コードを難読化することもできます。難読化の一環として、関数名と変数名が短い文字列に置き換えられるため、コードがよりコンパクトになり読みにくくなり、リバース エンジニアリングが困難になります。 Dojo Compressor (ShrinkSafe) は、最も一般的な難読化ツールです。最小化は安全で簡単なプロセスですが、難読化はより複雑で問題が発生しやすくなります。米国の上位 10 の Web サイトの調査によると、最小化によりファイルを 21% 削減し、難読化を 25% 削減できます。外部スクリプト ファイルを最小限に抑えることに加えて、埋め込みスクリプト コードも最小限に抑える必要があります。ルール 4 に従ってスクリプトが送信用に圧縮されている場合でも、スクリプトを最小化するとファイル サイズが 5% 以上削減されます。

ルール 11: リダイレクトを避ける
リダイレクト機能は、次のような 2 つの HTTP ステータス コード 301 および 302 によって完了します。 HTTP/1.1 301 Moved Permanently 場所: http://example.com/newuri Content-Type: text /htmlブラウザーは、Location で指定された URL にリクエストを自動的にリダイレクトします。リダイレクトの主な問題は、ユーザー エクスペリエンスが低下することです。最もリソースを消費し、頻繁に見落とされやすいリダイレクトの 1 つは、URL の最後の欠落部分です。たとえば、http://astrology.yahoo.com/astrology にアクセスすると、

http://astrology.yahoo にリダイレクトされます。 .com/占星術/。 Apache では、この問題は Alias、mod_rewrite、または DirectorySlash によって解決できます。

ルール 12: 重複したスクリプト ファイルを削除する
重複した JS スクリプト ファイルをページに含めると、パフォーマンスに影響します。つまり、不要な HTTP リクエストと追加の JS 実行が作成されます。 IE では不要な HTTP リクエストが発生しますが、Firefox では不要な HTTP リクエストが生成されません。追加の JS の実行は、IE または Firefox のどちらで実行されているかに関係なく発生します。スクリプト ファイルの重複を避ける 1 つの方法は、テンプレート システムを使用してスクリプト管理モジュールを作成することです。このモジュールは、スクリプト ファイルの重複を防ぐだけでなく、依存関係チェックを実装し、スクリプト ファイル名にバージョン番号を追加することもできるため、非常に長い有効期限を実現できます。

ルール 13: ETags を構成する
ETags は、ブラウザー キャッシュ内の要素が Web サーバー内の要素と一致するかどうかを判断するために使用されるメカニズムであり、最終変更日よりも柔軟な要素検証メカニズムです。 ETag は要素のバージョンを一意に表す文字列であり、引用符で囲む必要があります。 Web サーバーは最初に応答で ETag を指定します: HTTP/1.1 200 OK 10c24bc-4ab-457e1c1f" Content-Length: 12195 その後、ブラウザーが要素を検証する必要がある場合、 If を使用します。None-Match ヘッダーは ETag を Web サーバーに返します。ETag が一致する場合、サーバーは 304 コードを返すため、ダウンロード時間が節約されます。 GET /i/yahoo.gif HTTP/1.1 ホスト: us.yimg.com < 03:03: 59 2006 Dec 12> 10c24bc-4ab-457e1c1f」 HTTP/1.1 304 未変更 ETag の問題は、Apache1.3 や 2.x などのサーバー固有の属性に基づいて構築されていることです。 、その形式は inode-size-timestamp であり、IIS5.0 および 6.0 では、その形式は Filetimestamp:ChangeNumber です。このように、異なる Web サーバー上の同じ要素の ETag は異なります。このように、マルチ Web サーバー環境では、ブラウザは最初にサーバー 1 に特定の要素をリクエストし、次にその要素をサーバー 2 で検証します。ETag が異なるため、キャッシュは無効になり、再度ダウンロードする必要があります。

したがって、ETags システムが提供する柔軟な検証メカニズムを使用しない場合は、ETag を削除することが最善です。 ETag を削除すると、http 応答と後続の要求の HTTP ヘッダーのサイズが小さくなります。 Microsoft のサポート記事には ETag を削除する方法が記載されており、Apache では構成ファイルで FileETag none を設定するだけです。

ルール 14: Ajax のキャッシュ
パフォーマンス最適化ルールは Web 2.0 アプリケーションにも適用されます。 Ajax のパフォーマンスを向上させる最も重要な方法は、「ルール 3「Expires ヘッダーの追加」で説明したように、応答をキャッシュ可能にすることです。次の他のルールも Ajax に適用されます。もちろん、「ルール 3」が最も効果的な方法です。