Yahoo Web サイトのページパフォーマンス最適化のための 34 の黄金律_html/css_WEB-ITnose

Yahoo チームの経験: Web サイトのページのパフォーマンスを最適化するための 34 の黄金律
1. HTTP リクエストの数を最小限に抑える
エンド ユーザーの応答時間の 80% は、さまざまなコンテンツのダウンロードに使用されます。この部分には、ページ内の画像、スタイル シート、スクリプト、Flash などのダウンロードが含まれます。ページ内の要素の数を減らすことで、HTTP リクエストの数を減らすことができます。これは、Web ページの速度を向上させるための重要なステップです。
ページのコンポーネントを減らす方法は、実際にはページのデザインを簡素化することです。では、ページコンテンツの豊富さを維持し、応答時間を短縮する方法はあるのでしょうか?ここでは、ページのコンテンツを豊かに保ちながら HTTP リクエストの数を減らすためのテクニックをいくつか紹介します。

ファイルの結合は、すべてのスクリプトを 1 つのファイルに入れることで HTTP リクエストを減らす方法です。たとえば、すべての CSS ファイルを 1 つのスタイル シートに入れることができます。スクリプトやスタイル シートを異なるページで使用するときに異なる変更を加える必要がある場合、これは比較的面倒な場合がありますが、それでも、この方法はページのパフォーマンスを向上させるための重要なステップと見なされるべきです。

CSS スプライトは、画像リクエストを減らす効果的な方法です。すべての背景画像を 1 つの画像ファイルに配置し、CSS の背景画像プロパティと背景位置プロパティを使用して画像のさまざまな部分を表示します。

画像マップは複数の画像を 1 つの画像に統合します。ファイル全体のサイズは変わりませんが、HTTP リクエストの数は減少します。イメージ マップは、ナビゲーション バーなど、イメージのすべてのコンポーネントがページ上で近接して配置されている場合にのみ使用できます。画像の座標と合計を決定するのは面倒でエラーが発生しやすい可能性があり、画像マップ ナビゲーションの使用は読みにくいため、この方法はお勧めできません。

インライン画像では、data:URL スキームを使用して画像データをページの中央に読み込みます。これにより、ページのサイズが大きくなる可能性があります。インライン イメージをスタイルシート (キャッシュ可能) に配置すると、ページ ファイル サイズを増やすことなく HTTP リクエストを減らすことができます。ただし、インライン画像は主流のブラウザではまだサポートされていません。

最初に行う必要があるのは、ページに対する HTTP リクエストの数を減らすことです。これは、初めてのユーザーの待ち時間を短縮する最も重要な方法です。 Tenni Theurer がブログ「ブラウザー Cahe の使用法 - 暴露!」で説明しているように、キャッシュを使用しない場合、HTTP リクエストは応答時間の 40% ～ 60% を占めます。初めて Web サイトにアクセスするユーザーのエクスペリエンスを迅速化します。

2. DNS ルックアップの数を減らす
ドメイン ネーム システム (DNS) は、電話帳の名前と電話番号の関係と同じように、ドメイン名と IP の対応関係を提供します。ブラウザのアドレス バーに www.dudo.org と入力すると、DNS 解決サーバーはこのドメイン名に対応する IP アドレスを返します。 DNS 解決のプロセスにも時間がかかります。通常、指定されたドメイン名に対応する IP アドレスを返すには 20 ～ 120 ミリ秒かかります。このプロセス中、ブラウザは DNS ルックアップが完了するまで何も行いません。

DNS ルックアップをキャッシュすると、ページのパフォーマンスが向上します。この種のキャッシュには特定のキャッシュ サーバーが必要で、通常はユーザーの ISP プロバイダーまたはローカル LAN によって制御されますが、ユーザーが使用するコンピュータ上にもキャッシュが生成されます。 DNS 情報は、オペレーティング システム (Microsoft Windows システムの DNS クライアント サービス) の DNS キャッシュに保持されます。ほとんどのブラウザには、オペレーティング システムから独立した独自のキャッシュがあります。ブラウザには独自のキャッシュ レコードがあるため、リクエスト中にオペレーティング システムの影響を受けません。

Internet Explorer はデフォルトで DNS ルックアップ レコードを 30 分間キャッシュし、レジストリ内のキー値は DnsCacheTimeout です。 Firefox の DNS ルックアップ レコードのキャッシュ時間は 1 分で、設定ファイルのオプションは network.dnsCacheExpiration です (Fasterfox はこのオプションを 1 時間に変更しました)。

クライアントの DNS キャッシュが空の場合 (ブラウザーとオペレーティング システムの両方が空の場合)、DNS ルックアップの数はページ内のホスト名の数と同じになります。これには、ページ内の URL、画像、スクリプト ファイル、スタイル シート、Flash オブジェクトなどに含まれるホスト名が含まれます。ホスト名の数を減らすと、DNS ルックアップの数が減ります。

ホスト名の数を減らすと、ページ上の並列ダウンロードの数も減らすことができます。 DNS ルックアップの数を減らすと応答時間が短縮されますが、並列ダウンロードを減らすと応答時間が長くなります。私のガイドラインは、これらのページのコンテンツを少なくとも 2 つ、最大 4 つの部分に分割することです。その結果、DNS ルックアップの数を減らすことと、高度な並列ダウンロードを維持することとの間のトレードオフが生じます。

3. ジャンプを避ける
ジャンプは 301 および 302 コードを使用して実装されます。以下は、応答コード 301 を持つ HTTP ヘッダーです:
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html
ブラウザは、[場所] で指定された URL をユーザーに示します。ジャンプにはヘッダー ファイル内のすべての情報が必要ですが、コンテンツ部分は空であってもかまいません。名前に関係なく、301 および 302 応答は、Expires や Cache-Control などのヘッダー オプションを追加してキャッシュすることを指定しない限り、キャッシュされません。 要素の更新タグと JavaScript も URL ジャンプを実装できますが、ジャンプする必要がある場合は、主に「戻る」ボタンが正しく動作するようにするために、標準の 3XX HTTP ステータス コードを使用するのが最善の方法です。 。

ただし、ジャンプするとユーザー エクスペリエンスが低下することに注意してください。ユーザーと HTML ドキュメントの間にジャンプを追加すると、HTML ファイルがロードされる前にファイル (画像、Flash など) がダウンロードされないため、ページ内のすべての要素の表示が遅れます。

Web 開発者によって無視されることが多いジャンプ現象がありますが、応答時間が無駄になることがよくあります。この現象は、URL にスラッシュ (/) が必要であるにもかかわらず無視された場合に発生します。たとえば、http://astrology.yahoo.com/astrology にアクセスしたい場合、実際に返されるのは、http://astrology.yahoo.com/astrology/ を指す 301 コードを含むジャンプです (末尾に注意してください)スラッシュ)。 Apache サーバーでは、Alias または mod_rewrite または DirectorySlash を使用してこれを回避できます。

新しい Web サイトと古い Web サイトを接続する場合も、ジャンプ機能がよく使用される状況です。この場合、多くの場合、Web サイトのさまざまなコンテンツを接続し、さまざまなタイプのユーザー (ブラウザーの種類、ユーザー アカウントの種類など) に応じてジャンプする必要があります。ジャンプを使用して 2 つの Web サイト間を切り替えるのは非常に簡単で、必要なコードの量もそれほど多くありません。このアプローチを使用すると、開発者の複雑さは軽減されますが、ユーザー エクスペリエンスも低下します。両方が同じサーバー上にある場合は、別の方法として、Alias と mod_rewrite を使用することもできます。リダイレクトの原因が異なるドメイン名である場合は、代わりに Alias または mod_revirte を使用して CNAME (あるドメイン名と別のドメイン名の関係を保存する DNS レコード) を作成できます。

4. キャッシュ可能な AJAX
Ajax の利点の 1 つは、バックエンド サーバーから情報を送信する非同期の性質により、ユーザーに即座にフィードバックが得られることです。ただし、Ajax を使用しても、ユーザーが非同期 JavaScript および XML 応答の待機に時間を費やさないという保証はありません。多くのアプリケーションでは、ユーザーが応答を待つ必要があるかどうかは、Ajax の使用方法によって異なります。たとえば、Web ベースの電子メール クライアントでは、ユーザーは Ajax が基準を満たす電子メール クエリ結果を返すまで待つ必要があります。 「非同期」は「即時」を意味するものではないことに注意することが重要です。

パフォーマンスを向上させるには、Ajax の応答を最適化することが重要です。 Ajxa のパフォーマンスを向上させる最も重要な方法は、応答をキャッシュ可能にすることです。詳細については、「Expires または Cache-Control ヘッダーの追加」を参照してください。その他のいくつかのルールも Ajax に適用されます:
Gizp 圧縮ファイル
DNS ルックアップの数を減らす
JavaScript を効率化する
ジャンプを避ける
ETag を設定する

例を見てみましょう: Web2.0 電子メール クライアントは Ajax を使用してダウンロードを自動的に完了しますユーザーのアドレス帳の。ユーザーが電子メール Web アプリケーションを最後に使用してからアドレス帳に変更を加えておらず、Ajax 応答が Expire または Cacke-Control ヘッダーを介してキャッシュされている場合、アドレス帳は最後のキャッシュから直接読み取ることができます。 。キャッシュされたアドレス帳を使用するか、新しいリクエストを送信するかをブラウザーに指示する必要があります。これは、アドレス帳を読み取る Ajax URL に、最終編集時刻を含むタイムスタンプを追加することで実現できます (例: &t=11900241612 など)。前回のダウンロード以降、アドレス帳が編集されていない場合、タイムスタンプは変更されず、ブラウザのキャッシュからロードされるため、HTTP リクエスト プロセスが 1 つ削減されます。ユーザーがアドレス帳を変更した場合、タイムスタンプを使用して新しい URL がキャッシュされた応答と一致しないことが判断され、ブラウザはアドレス帳を更新するリクエストを発行します。
Ajxa レスポンスが動的に生成される場合でも、それが 1 人のユーザーにのみ適用される場合でも、キャッシュする必要があります。そうすることで、Web 2.0 アプリケーションを高速化できます。

5. コンテンツの読み込みを遅らせる
Web ページをよく見て、「ページがレンダリングされるときに最初に読み込む必要があるコンテンツはどれか? 後で読み込むことができるコンテンツと構造はどれか? プロセス全体onload イベントに基づいています。2 つの部分に分かれている JavaScript は、理想的な選択肢です。たとえば、ドラッグ アンド ドロップとアニメーションを実装する JavaScript がある場合、ページ上のドラッグ アンド ドロップ要素が後で読み込まれるまで待機することができます。非表示部分 (ユーザーの操作後に表示されるコンテンツ) や折りたたまれた部分の画像などの他のコンテンツも延期することができます。ツールを使用すると作業を節約できます。YUI Image Loader は、フォールド内の画像の読み込みを延期するのに役立ちます。また、YUI Get ユーティリティは、JS と CSS を組み込むのに便利な方法です。たとえば、Firebug の [ネット] タブを開いて、Yahoo のホームページを見てみることができます。
パフォーマンス目標とその他の Web サイト開発実践は、整合性があれば相互に補完します。この場合、プログラムを通じて Web サイトのパフォーマンスを向上させる方法では、JavaScript がサポートされている場合はユーザー エクスペリエンスを最初に削除できることがわかりますが、そのためには Web サイトが JavaScript なしで正常に実行できることを確認する必要があります。ページが適切に実行されていることを確認したら、スクリプトをロードして、ドラッグ アンド ドロップやアニメーションなどのより派手な効果を実装します。

6. プリロード
プリロードとポストロードはまったく逆のように見えますが、実際にはプリロードは別の目的を達成することです。プリロードとは、ブラウザがアイドル状態のときに、将来必要になる可能性のあるページ コンテンツ (画像、スタイルシート、スクリプトなど) をリクエストすることです。この方法を使用すると、ユーザーが次のページにアクセスするときに、ページ内のほとんどのコンテンツがキャッシュに読み込まれているため、アクセス速度が大幅に向上します。

いくつかのプリロード方法が以下に提供されています:
無条件ロード: onload イベントがトリガーされると、追加のページ コンテンツが直接ロードされます。 Google.com を例にとると、その精神イメージがどのように onload に読み込まれるかがわかります。この心霊画像は google.com のホームページでは必須ではありませんが、検索結果ページでは使用できます。
条件付き読み込み: ユーザーの操作に基づいて、ユーザーがアクセスする可能性のあるページを基本的に決定し、それに応じてページのコンテンツをプリロードできます。 search.yahoo.com では、入力時に追加のページ コンテンツがどのように読み込まれるかを確認できます。
先行読み込みを行う: 再設計されたページを読み込むときにプリロードを使用します。この状況は、ページの再デザイン後に「新しいページは見た目はかっこいいが、以前よりも遅い」というユーザーの苦情が発生したときによく発生します。問題は、ユーザーが古いサイトの完全なキャッシュを持っているのに、新しいサイトのキャッシュが何もないことである可能性があります。したがって、新しいサイトにアクセスする前にコンテンツをロードすることで、この結果を回避できます。古いサイトでは、ブラウザの空き時間を利用して、新しいサイトで使用されている画像やスクリプトを読み込んで、アクセス速度を向上させます。

7. DOM 要素の数を減らす
ページが複雑であるということは、より多くのデータをダウンロードする必要があることを意味し、また、JavaScript が DOM を走査する速度が遅くなるということも意味します。たとえば、イベント ハンドラーを追加する場合、500 個の DOM 要素と 5000 個の DOM 要素をループする効果は明ら​​かに異なります。
多数の DOM 要素が存在するということは、コンテンツを削除せずに要素タグを置き換えるだけで合理化できるページの部分があることを意味します。ページレイアウトで表を使用していますか?レイアウトのためだけに

要素をさらに導入したことがありますか?使用するのに適したラベル、または意味的により適切なラベルが存在する可能性があります。
YUI CSS ユーティリティは、レイアウトに大きな助けをもたらします。grids.css は全体的なレイアウトを実現するのに役立ち、font.css とreset.css はブラウザーのデフォルト形式を削除するのに役立ちます。これは、改行効果があるからではなく、意味的に意味がある場合にのみ

を使用するなど、ページ内のタグを再検討する機会を提供します。
DOM 要素の数は、Firebug コンソールに次のように入力するだけで簡単に計算できます。
では、DOM 要素の数が多すぎるのでしょうか?これは、マークアップが適切に使用されている同様のページと比較できます。たとえば、Yahoo! ホームページは多くのコンテンツを含むページですが、使用されている要素 (HTML タグ) は 700 個のみです。

8. ドメイン名に従ってページコンテンツを分割します
ページコンテンツをいくつかの部分に分割すると、並列ダウンロードを最大限に高めることができます。 DNS ルックアップの影響により、使用するドメイン名の数が 2 ～ 4 であることを最初に確認する必要があります。たとえば、使用される HTML コンテンツと動的コンテンツを www.example.org に配置し、ページのさまざまなコンポーネント (画像、スクリプト、CSS) をそれぞれ statics1.example.org と statics.example.org に保存できます。
さらに関連する情報は、Tenni Theurer と Patty Chi が共著した記事「Carpool Lane での並列ダウンロードの最大化」を参照してください。

9. iframe の数を最小限に抑える
ifrmae 要素は、親ドキュメントに新しい HTML ドキュメントを挿入できます。 iframe をより効果的に使用するには、iframe の仕組みを理解することが重要です。

の直後です。これは、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 を使用する方が (意味的に) 理にかなっています。

17. スタイルシートを先頭に配置します
Yahoo! のパフォーマンスを調査したところ、スタイルシートをドキュメントの 内に配置すると、ページのダウンロード速度が向上することがわかりました。これは、スタイル シートを

内に配置すると、ページが段階的に読み込まれて表示されるためです。
パフォーマンスを重視するフロントエンド サーバーは、多くの場合、ページが順序どおりに読み込まれることを望んでいます。同時に、ブラウザは受信したコンテンツを可能な限り表示することも望んでいます。これは、コンテンツが多いページや接続が遅いユーザーにとって特に重要です。プロセス ポインターなどの視覚的なフィードバックをユーザーに返すことについては、十分に研究されており、正式に文書化されています。私たちの調査では、HTML ページがプロセス ポインターです。ブラウザーがファイル ヘッダーを順序どおりに読み込むと、ナビゲーション バーや上部のロゴなどはすべて、ページの読み込みを待っているユーザーに対する視覚的なフィードバックとして機能します。これにより、全体的なユーザー エクスペリエンスが向上します。
スタイルシートをドキュメントの下部に配置する場合の問題は、Internet Explorer を含む多くのブラウザーでコンテンツの順序どおりのレンダリングが妨げられることです。ブラウザーは、スタイルの変更によるページ要素の再描画を避けるためにレンダリングを中止します。ユーザーは空白のページに直面する必要があります。
HTML 仕様では、スタイル シートはページの

領域に含める必要があると明確に規定されています。「 とは異なり、 は