Yahoo チームの経験: ウェブサイトのパフォーマンス最適化のための 34 の黄金律_html/css_WEB-ITnose

ウェブサイトのパフォーマンスの最適化に関して Yahoo チームがまとめた経験は、非常に参考になります。
英語の原文: http://developer.yahoo.com/performance/rules.html

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 を設定する
例を見てみましょう: Web 2.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 サイト開発手法と一致している場合、それらは相互に補完します。プログラムによるパフォーマンスから、JavaScript がサポートされている場合は、まずユーザー エクスペリエンスを削除できますが、Web サイトが JavaScript なしで正常に動作することを確認した後、より派手な効果を実現するためにスクリプトをロードする必要があります。

6. プリロード

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

いくつかの前処理メソッドが以下に提供されています。 読み込みメソッド:

無条件読み込み: onload イベントがトリガーされると、追加のページ コンテンツが直接読み込まれます。Google.com のスピリット イメージがどのように読み込まれるかがわかります。 onload では、com ホームページでは必要ありませんが、検索結果ページで使用できます。
条件付き読み込み: ユーザーの操作に基づいて、ユーザーがアクセスできるページを決定します。 .yahoo.com では、入力時に追加のページ コンテンツがどのように読み込まれるかを確認できます。
再設計されたページを読み込むときに、この問題が頻繁に発生します。新しいページは見た目はかっこいいですが、前より遅いです。」 問題は、ユーザーが古いサイトの完全なキャッシュを確立したが、新しいサイトにはキャッシュされたコンテンツがないため、新しいサイトにアクセスできることである可能性があります。この結果を回避するには、サイトの前にコンテンツを追加して、古いサイトでのブラウザの空き時間を利用して、新しいサイトで使用されている画像とスクリプトを読み込み、アクセス速度を向上させます。

7. DOM 要素の数を減らす

ページが複雑であるということは、より多くのデータをダウンロードする必要があることを意味し、また、JavaScript が DOM を走査する速度が遅くなるということも意味します。たとえば、イベント ハンドラーを追加する場合、500 個の DOM 要素と 5000 個の DOM 要素をループする効果は明ら​​かに異なります。

多数の DOM 要素が存在するということは、コンテンツを削除せずに要素タグを置き換えるだけで合理化できるページの部分があることを意味します。ページレイアウトで表を使用していますか?レイアウトのためだけに

要素をさらに導入したことがありますか?使用するのに適したラベル、または意味的により適切なラベルが存在する可能性があります。

YUI CSS ユーティリティは、レイアウトに大きな助けをもたらします。grids.css は全体的なレイアウトを実現するのに役立ち、font.css とreset.css はブラウザーのデフォルト形式を削除するのに役立ちます。これは、改行効果があるからではなく、意味的に意味がある場合にのみ

を使用するなど、ページ内のタグを再検討する機会を提供します。
DOM 要素の数は簡単に計算できます。Firebug コンソールに次のように入力するだけです。これは、マークアップが適切に使用されている同様のページと比較できます。たとえば、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 仕様では、スタイル シートはページの

領域に含めるべきであると明確に規定されています。「 とは異なり、 は ドキュメント領域の。ただし、複数回使用できます。」白い画面が表示されたり、スタイルが設定されていないコンテンツが発生したりしても、試してみる価値はありません。最善の解決策は、HTML 仕様に従ってスタイル シートをドキュメント