Yahooのフロントエンド最適化に関する35のルールについての簡単な説明

概要: 仕事でも面接でも、Web フロントエンドのパフォーマンスを最適化することは非常に重要です。では、最適化はどこから始めればよいのでしょうか? Yahoo のフロントエンド最適化の 34 のルールに従うこともできますが、現在は 35 個あるため、これらは Yahoo のフロントエンド最適化の 35 のルールであると言えます。分類されたのは良いことです。これにより、最適化の方向性がより明確になります。

コンテンツ

1. HTTPリクエストの数を最小限に抑える

エンドユーザーの応答時間の 80% はフロントエンドで費やされ、そのほとんどはページ上のさまざまなコンポーネント (画像、スタイルシート、スクリプト、Flash など) のダウンロードに費やされます。コンポーネントの数を減らすと、必然的にページから送信される HTTP リクエストの数も減ります。これがページを高速化するための鍵です。

ページ コンポーネントの数を減らす 1 つの方法は、ページ デザインを簡素化することです。しかし、応答時間を改善しながら複雑なページを構築する方法はあるのでしょうか?まあ、両方の長所を活かす方法は確かにあるのです。

ファイルをマージすると、すべてのスクリプトが 1 つのファイルに格納されるため、リクエストの数が減ります。もちろん、すべての CSS をマージすることもできます。各ページのスクリプトとスタイルが異なる場合、ファイルを結合するのは面倒な作業になる可能性がありますが、サイトの公開プロセスの一部としてこれを行うと、応答時間が大幅に改善されます。

CSS スプライトは、画像リクエストの数を減らすための推奨される方法です。すべての背景画像を 1 つの画像に結合し、CSS の background-image プロパティと background-position プロパティを使用して、表示する部分を配置します。

イメージマップは、複数の画像を 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 を照会しません。

IE は、DnsCacheTimeout レジストリ設定に記述されているように、デフォルトで 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 永久に移動
場所: http://example.com/newuri
コンテンツタイプ: text/html

ブラウザは、「場所」フィールドに指定された URL に自動的にジャンプします。リダイレクトに必要なすべての情報は HTTP ヘッダーに含まれており、応答本文は通常空です。実際、Expires や Cache-Control などの追加の HTTP ヘッダーもリダイレクトを示します。リダイレクトにはメタタグと JavaScript を更新するなどの他の方法もありますが、リダイレクトする必要がある場合は、主に戻るボタンが適切に機能するように、標準の 3xxHTTP ステータス コードを使用するのが最適です。

リダイレクトはユーザー エクスペリエンスを低下させることに注意してください。ユーザーと 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 には次の追加ルールが適用されます。

1. Gzip コンポーネント
2. DNSルックアップを削減
3. JavaScript の圧縮
4. リダイレクトを避ける
5. ETags の設定

Web 2.0 電子メール クライアントが Ajax を使用してユーザーのアドレス帳をダウンロードし、オートコンプリート機能を実装する例を見てみましょう。ユーザーが最後に使用してからアドレス帳を変更しておらず、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. コンポーネントのプリロード

プリロードは遅延ロードの反対のように思えるかもしれませんが、実際には目的が異なります。コンポーネントをプリロードすることで、ブラウザのアイドル時間を最大限に活用して、将来使用されるコンポーネント (画像、スタイル、スクリプト) をリクエストできます。ユーザーが次のページにアクセスすると、ほとんどのコンポーネントがすでにキャッシュ内にあるため、ページの読み込みが速くなります。

実際のアプリケーションでは、プリロードにはいくつかの種類があります。

1. 無条件プリロード - 追加のコンポーネントを取得して、できるだけ早くロードを開始します。 google.com は、スプライト イメージのプリロードの良い例です。このスプライト イメージは、google.com のホームページには必要ありませんが、検索結果ページのコンテンツには必要です。
2. 条件付きプリロード - ユーザーのアクションに基づいてユーザーがどこにジャンプするかを推測し、それに応じてプリロードします。 search.yahoo.com 入力ボックスに入力すると、これらの追加コンポーネントの読み込みがどのように要求されるかを確認できます。
3. 事前にプリロード – 新しいデザインがリリースされる前にプリロードします。再設計後に「新しいサイトは素晴らしいですが、以前よりも遅いです」という声を聞くことは珍しくありません。その理由の 1 つは、ユーザーが以前のページには古いキャッシュを使用してアクセスしていたのに対し、新しいページはキャッシュが空の状態でアクセスされるからです。この悪影響は、新しいデザインがリリースされる前にいくつかのコンポーネントをプリロードすることで軽減できます。古いサイトは、ブラウザのアイドル時間を利用して、新しいサイトに必要な画像やスクリプトをリクエストできます。

7. DOM要素の数を減らす

ページが複雑になると、ダウンロードするバイト数が多くなり、JavaScript による DOM へのアクセスが遅くなります。たとえば、イベント ハンドラーを追加する場合、ページ上の 500 個の DOM 要素をループする場合と、5,000 個の DOM 要素をループする場合では違いがあります。

DOM 要素の数が多いということは、ページ上にクリーンアップする必要がある余分なマークアップがあることを示しています。レイアウトにネストされたテーブルを使用していますか?あるいは、レイアウトの問題を修正するために多数の <div> を追加していますか?おそらく、より優れたセマンティック マークアップを使用する必要があります。

YUI CSS ユーティリティはレイアウトに非常に役立ちます。grids.css は全体的なレイアウト用で、fonts.css と reset.css はブラウザのデフォルトの書式設定を削除するために使用できます。これは、マークアップを整理して検討し始める良い機会です。たとえば、新しい行をレンダリングするためではなく、意味的に意味がある場合にのみ <div> を使用します。

DOM 要素の数は簡単にテストできます。Firebug コンソールに次のように入力するだけです。

ドキュメント.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> の利点:

1. ロゴや広告などのサードパーティコンテンツの導入が遅い
2. セキュリティサンドボックス
3. 並列ダウンロードスクリプト

<iframe> の欠点:

1. 空のiframeでもコストがかかる
2. ページの読み込みをブロックしています
3. 非意味論的

10. 404を避ける

HTTP リクエストはコストがかかります。役に立たない応答 (404 Not Found など) を取得するために HTTP リクエストを送信しても意味がありません。メリットがなく、ユーザー エクスペリエンスが遅くなるだけです。

一部のサイトでは、便利な 404 (「xxx ですか?」) を使用しています。これはユーザー エクスペリエンスには適していますが、サーバー リソース (データベースなど) も浪費します。最悪なのは、リンク先の外部 JavaScript にエラーがあり、結果が 404 になることです。まず、このようなダウンロードは並列ダウンロードをブロックします。次に、ブラウザは 404 レスポンス本文を解析しようとしますが、これは JavaScript コードなので、どの部分が使用可能かを判断する必要があります。

CSS部分

11. CSS式の使用を避ける

CSS 式を使用して CSS プロパティを動的に設定する方法は強力ですが危険です。 IE5 以降ではサポートされていましたが、IE8 以降では推奨されなくなりました。たとえば、CSS 式を使用して、背景色を 1 時間ごとに交互に変更するように設定できます。

背景色: 式( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

12. <link>を選択し、@importを破棄する

前述したように、プログレッシブ レンダリングを実現するには、CSS を先頭に配置するのがベスト プラクティスです。

IE で @import を使用すると、下部で <link> を使用するのと同じ効果が得られるため、使用しないことをお勧めします。

13. フィルターの使用を避ける

IE 独自の AlphaImageLoader フィルターを使用すると、IE7 より前のバージョンでの半透明の PNG 画像の問題を修正できます。画像の読み込み処理中に、このフィルターはレンダリングをブロックし、ブラウザを妨害し、メモリ消費量を増加させ、各画像ではなく各要素に適用されるため、多くの問題が発生します。

最善のアプローチは、AlphaImageLoader をまったく使用せず、代わりに IE で適切にサポートされている PNG8 画像を使用することです。 AlphaImageLoader を使用する必要がある場合は、IE7 以降のユーザーに影響を与えないように、アンダースコア ハック _filter を使用する必要があります。

14. スタイルシートを先頭に置く

Yahoo! でパフォーマンスを調査しているときに、ドキュメントの HEAD セクションにスタイルシートを配置すると、ページの読み込みが速くなることがわかりました。これは、スタイルシートをヘッドに配置すると、ページが段階的にレンダリングされるためです。

パフォーマンスを気にするフロントエンドエンジニアは、ページを段階的にレンダリングしたいと考えています。つまり、ブラウザに既存のコンテンツをできるだけ早く表示させることが求められます。これは、ページに大量のコンテンツがある場合や、ユーザーの接続速度が遅い場合に特に重要です。ユーザーへのフィードバック (進捗状況インジケーターなど) を表示することの重要性は、広範囲に研究され、文書化されています。私たちの場合、HTML ページが進行状況インジケーターになります。ブラウザがページ ヘッダー、ナビゲーション バー、トップ ロゴなどを徐々に読み込むと、ページの読み込みを待っているユーザーへのフィードバックとして使用され、全体的なユーザー エクスペリエンスが向上します。

js部分

15. 重複したスクリプトを削除する

ページ上に重複したスクリプト ファイルがあると、予期しない形でパフォーマンスに影響する可能性があります。米国のトップ 10 の Web サイトを調査したところ、重複したスクリプトが含まれているのは 2 つのみでした。 1 つのページにスクリプトが重複する可能性が高くなる主な理由は、チームの規模とスクリプトの数の 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 要素にアクセスすると速度が遅くなるため、ページの応答性を高めるには、次の操作を行う必要があります。

1. 訪問した要素のインデックスをキャッシュする
2. まずノードを「オフライン」で更新し、次にそれらをDOMツリーに追加します。
3. レイアウトの問題を修正するためにJavaScriptを使用しない

17. スマートなイベントハンドラを使用する

頻繁に実行されるイベント ハンドラーが DOM ツリーのさまざまな要素に多数追加されると、ページが応答しなくなることがあります。このため、イベント委任を使用することをお勧めします。 div に 10 個のボタンがある場合は、ボタンごとに 1 つではなく、div コンテナーに 1 つのイベント ハンドラーのみを追加する必要があります。イベントはバブルアップできるため、イベントをキャプチャして、どのボタンがイベントのソースであったかを知ることができます。

18. スクリプトを一番下に置く

スクリプトは並列ダウンロードをブロックします。公式 HTTP/1.1 ドキュメントでは、ブラウザがホスト名ごとに 2 つ以上のコンポーネントを並列ダウンロードしないように推奨されています。画像が複数のホスト名から取得される場合、並列ダウンロードの数は 2 を超えることがあります。スクリプトがダウンロード中の場合、ブラウザは別のホスト名に対しても他のダウンロードを開始しません。

スクリプトを一番下に移動するのは簡単ではない場合があります。たとえば、document.write を使用してスクリプトをページ コンテンツに挿入した場合、それ以上下に移動することはできません。スコープに関する問題が発生する可能性もありますが、ほとんどの場合は解決できます。

一般的な提案は、遅延スクリプトを使用することです。DEFER 属性を持つスクリプトは document.write を含まないように設計されており、レンダリングを続行できることをブラウザに通知します。残念ながら、Firefox は DEFER 属性をサポートしていません。 IE ではスクリプトが延期される可能性がありますが、期待どおりではありません。スクリプトを延期できる場合は、ページの下部に配置すると、ページの読み込みが速くなります。

ジャバスクリプト、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 です。YUI Compressor は CSS も圧縮できます。

難読化はオプションのソースコード最適化手段であり、圧縮よりも複雑なため、難読化プロセスではバグが発生しやすくなります。米国のトップ 10 ウェブサイトの調査では、圧縮によってサイズが 21% 削減され、難読化によって 25% 削減されました。難読化によりサイズは大幅に縮小されますが、圧縮よりもリスクが高くなります。

外部スクリプトとスタイルを圧縮するだけでなく、インライン <script> および <style> ブロックも圧縮できます。 gzip が有効になっている場合でも、最初に圧縮するとサイズが 5% 以上削減されることがあります。 JavaScript と CSS はますます一般的になっているので、コードを圧縮することは良い考えです。

写真

21. 画像を最適化する

GIF を PNG に変換して、スペースが節約されるかどうかを確認してください。すべてのPNG画像に対してpngcrush（または他のPNG最適化ツール）を実行します。

22. CSSスプライトを最適化する

1. スプライト画像では、水平方向に配置すると、垂直方向に配置する場合よりも最終的なファイル サイズが小さくなるのが一般的です。
2. スプライト イメージで類似の色を組み合わせると、色の数を少なく抑えることができます。理想的には、256 色未満の PNG8 形式です。
3. 「モバイルフレンドリー」なので、スプライト画像にあまり多くのスペースを残さないでください。これは画像ファイルのサイズに大きな影響を与えませんが、画像をピクセルマップに解凍するときにユーザーエージェントが消費するメモリを節約します。 100×100 の画像には 10,000 個のピクセルがあり、1000×1000 の画像には 100 万個のピクセルがあります。

23. HTMLで画像を拡大縮小しない

HTML で幅と高さを設定できるからといって、不必要に大きな画像を使用しないでください。必要であれば

<img width="100" height="100" src="mycat.jpg" alt="私の猫" />

そうすると、500x500 ピクセルの画像を縮小するのではなく、画像自体 (mycat.jpg) を 100x100 ピクセルにする必要があります。

24. 小さくてキャッシュ可能な favicon.ico (PS お気に入りアイコン) を使用する

favicon.ico はサーバーのルートディレクトリに配置される画像です。無視してもブラウザが自動的に要求してくるので面倒なことになりますので、404 Not Found 応答は出さない方がよいでしょう。そして、同じサーバー上にある限り、リクエストするたびに Cookie が送信されます。さらに、この画像はダウンロード順序に影響を及ぼします。たとえば、IE では、onload で追加のコンポーネントをリクエストすると、ファビコンが最初にダウンロードされます。

したがって、favicon.ico の欠点を軽減するには、次の点に注意する必要があります。

1. 十分に小さい、できれば1K以下
2. 適切な有効期限の HTTP ヘッダーを設定します (後で変更する場合、名前を変更することはできません)。有効期限は通常、数か月先に設定するのが安全です。現在の favicon.ico の最終更新日を確認することで、ブラウザーが変更を認識していることを確認できます。

クッキー

25. クッキーの重量を減らす

クッキーは、認証やパーソナライズなど、さまざまな目的で使用されます。 Cookie 情報は、HTTP ヘッダーで Web サーバーとブラウザー間で交換されます。ユーザーの応答時間への影響を最小限に抑えるには、Cookie をできるだけ小さく保つことが重要です。

1. 不要なCookieを削除する
2. ユーザーの応答時間への影響を最小限に抑えるために、Cookie をできるだけ小さく保ちます。
3. 他のサブドメインに影響を与えないように、Cookieの適切なドメインレベルを設定するように注意してください。
4. 適切な有効期限を設定します。有効期限を早く設定するか、有効期限を設定しない場合は、Cookie がより早く削除され、ユーザーの応答時間が短縮されます。

26. クッキーを含まないドメインにコンポーネントを配置する

ブラウザが静的画像のリクエストを送信すると、それと一緒に Cookie も送信されますが、サーバーではこれらの Cookie はまったく必要ありません。そのため、これらは意味のないネットワーク トラフィックを引き起こすだけなので、静的コンポーネントのリクエストに Cookie が含まれていないことを確認する必要があります。サブドメインを作成し、そこにすべての静的コンポーネントをデプロイできます。

ドメイン名が www.example.org の場合、静的コンポーネントを static.example.org にデプロイできます。ただし、トップレベルドメイン example.org または www.example.org に Cookie が設定されている場合は、static.example.org へのすべてのリクエストにそれらの Cookie が含まれます。この時点で、新しいドメイン名を購入し、その上にすべての静的コンポーネントをデプロイし、この新しいドメイン名を Cookie なしに保つことができます。 Yahoo! は yimg.com、YouTube は ytimg.com、Amazon は images-amazon.com などを使用します。

クッキーなしでドメインに静的コンポーネントを展開するもう 1 つの利点は、一部のプロキシがクッキーを含むコンポーネントのキャッシュを拒否する可能性があることです。注意すべき点: ホームページとして example.org を使用するか www.example.org を使用するかわからない場合は、Cookie の影響を考慮してください。 www を省略すると、Cookie を *.example.org にのみ書き込むことができるため、パフォーマンス上の理由から、www サブドメインを使用して、このサブドメインに Cookie を書き込むことが最適です。

携帯

27. すべてのコンポーネントが25K未満であることを確認する

この制限は、iPhone が 25K を超えるコンポーネントをキャッシュできないために発生します。これは、圧縮されていないサイズを指すことに注意してください。そのため、gzip だけでは不十分な場合があり、コンテンツ自体を縮小することも重要です。

28. コンポーネントを複合ドキュメントにパッケージ化する

コンポーネントを添付ファイル付きの電子メールのような複合ドキュメントにパッケージ化することで、単一の HTTP リクエストで複数のコンポーネントを取得できます (HTTP リクエストはコストがかかることに注意してください)。この方法を使用する場合は、まずユーザーエージェントがサポートしているかどうかを確認する必要があります (iPhone はサポートしていません)。

サーバ

29.Gzip コンポーネント

フロントエンド エンジニアは、ネットワーク経由で HTTP リクエストと応答を送信するのにかかる時間を大幅に短縮する方法を見つけることができます。エンドユーザーの帯域幅速度、ネットワーク サービス プロバイダー、ピア交換ポイントまでの距離などはすべて開発チームの制御範囲外であることは間違いありません。ただし、応答時間に影響を与える可能性のある他の要因もあり、圧縮により HTTP 応答のサイズが縮小され、応答時間が改善される可能性があります。

HTTP/1.1 以降、Web クライアントには圧縮をサポートする Accept-Encoding HTTP リクエスト ヘッダーが用意されています。

Accept-Encoding: gzip、deflate

Web サーバーがこの要求ヘッダーを検出すると、クライアントによってリストされた方法のいずれかを使用して応答を圧縮します。 Web サーバーは、Content-Encoding 応答ヘッダーを通じてクライアントに通知します。

コンテンツエンコーディング: gzip

gzip 圧縮をできるだけ使用するとページのサイズを縮小でき、これはユーザー エクスペリエンスを向上させる最も簡単な方法でもあります。

30. 画像のsrc属性を空のままにしない

空の文字列を含む画像 空の文字列 src 属性を含む画像は非常に一般的であり、主に次の 2 つの形式で表示されます。

1. ストレートHTML

<画像src=””>

2. JavaScript

var img = 新しい画像();
画像を拡大

どちらの形式でも同じ問題が発生します。ブラウザがサーバーに別のリクエストを送信するからです。

31. ETagsを構成する

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

HTTP/1.1 200 OK
最終更新日: 2006 年 12 月 12 日 (火) 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
コンテンツの長さ: 12195 

次に、ブラウザがコンポーネントを検証する必要がある場合、If-None-Match リクエスト ヘッダーを使用して ETag を元のサーバーに返します。 ETag が正常に一致すると、304 ステータス コードが返され、応答本文が 12195 バイト削減されます。

GET /i/yahoo.gif HTTP/1.1
      ホスト: us.yimg.com
      変更日時: 2006 年 12 月 12 日火曜日 03:03:59 GMT
      一致しない場合: "10c24bc-4ab-457e1c1f"
      HTTP/1.1 304 変更されていません

32. AjaxにGETリクエストを使用する

Yahoo! メール チームは、XMLHttpRequest を使用する場合、ブラウザの POST リクエストが 2 段階のプロセス (最初に HTTP ヘッダーを送信し、次にデータを送信する) で実装されることを発見しました。したがって、GET リクエストを使用するのが最適です。GET リクエストでは、1 つの TCP メッセージを送信するだけで済みます (Cookie が多数ある場合を除く)。 IE URL の最大長は 2K なので、送信するデータが 2K を超える場合は GET は使用できません。

POST リクエストの興味深い副作用は、GET リクエストの場合と同様に、実際にはデータが送信されないことです。 HTTP 仕様で説明されているように、情報を取得するには GET リクエストが使用されます。したがって、そのセマンティクスは、GET リクエストを使用してデータを要求することであり、サーバーに保存する必要があるデータを送信することではありません。

33. バッファを早めにクリアする

ユーザーがページを要求すると、サーバーが HTML ページを組み立てるのに約 200 ～ 500 ミリ秒かかり、その間、ブラウザはデータが到着するのを待機します。 PHP には flush() 関数があり、準備された HTML 応答の一部をブラウザに送信して、残りの部分をバックグラウンドで準備している間にブラウザがコンポーネントの取得を開始できるようにします。これは、ビジーなバックエンドや非常に「軽量」なフロントエンド ページで役立ちます (PS、応答時間が主にバックグラウンドで発生する場合、利点は最大になります)。

バッファをフラッシュする理想的な場所は HEAD の後です。これは、HTML の HEAD 部分は通常生成が容易で、CSS ファイルや JavaScript ファイルを含めることができるため、ブラウザはバックグラウンドで処理されている間にもコンポーネントの取得を並行して開始できるためです。

例えば：

 ... <!-- css、js -->
    </head>
    <?php フラッシュ(); ?>
    <本文>
      ... <!-- コンテンツ -->

34. CDN（コンテンツ配信ネットワーク）を使用する

ユーザーとサーバー間の物理的な距離も応答時間に影響します。コンテンツを地理的に分散した複数のサーバーに展開すると、ユーザーはページをより速く読み込むことができます。しかし、具体的にどのようにすればよいのでしょうか?

地理的に分散されたコンテンツを実装するための最初のステップは、分散構造に対応するために Web アプリケーションを再設計しないことです。アプリケーションによっては、アーキテクチャを変更すると、セッション状態の同期やサーバー間でのデータベース トランザクションの複製などの困難なタスクが必要になる場合があります。この困難さのため、ユーザーとコンテンツの距離を縮める提案は遅れたり、まったく承認されなかったりする可能性があります。

エンド ユーザーの応答時間の 80% ～ 90% は、ページ コンポーネント (画像、スタイル、スクリプト、Flash など) のダウンロードに費やされることを覚えておいてください。これがパフォーマンスの黄金律です。アプリケーション構造を最初から再設計するよりも、まず静的コンテンツを配布する方が適切です。これにより、応答時間が大幅に短縮されるだけでなく、CDN のメリットを実証しやすくなります。

コンテンツ配信ネットワーク (CDN) は、異なる地理的な場所に分散された Web サーバーのグループであり、ユーザーにコンテンツをより効率的に配信するために使用されます。通常、コンテンツを配信するために選択されるサーバーは、ネットワーク距離の測定値に基づいています。たとえば、ホップ数が最も少ないサーバー、または応答時間が最も速いサーバーを選択します。

35. Expires または Cache-Control HTTP ヘッダーを追加する

このルールには 2 つの側面があります。

1. 静的コンポーネントの場合: 期限切れにならないように、遠い将来の時間を Expires として設定します。
2. 冗長な動的コンポーネント: 適切なCache-Control HTTPヘッダーを使用して、ブラウザが条件付きリクエストを行えるようにします。

Web ページのデザインはますます豊かになり、ページ内のスクリプト、画像、Flash も増えています。サイトへの新しい訪問者は、まだいくつかのHTTP要求を送信する必要がある場合がありますが、有効期限を使用することにより、コンポーネントをキャッシュ可能にすることができます。 HTTPヘッダーは一般的に画像で使用されますが、スクリプト、スタイル、フラッシュコンポーネントなどのすべてのコンポーネントで使用する必要があります。

ブラウザ（およびプロキシ）は、キャッシュを使用してHTTPリクエストの数とサイズを削減し、ページをより速く読み込むことができます。 Webサーバーは、有効性HTTP応答ヘッダーを使用して、ページのさまざまなコンポーネントをキャッシュする時間をクライアントに伝えます。遠い将来の有効期限を使用すると、この応答は2010年4月15日までに変更されないことをブラウザに伝えます。

有効期限: 2010 年 4 月 15 日 (木) 20:00:00 GMT

Apacheを使用している場合は、ExpiresDefaultディレクティブを使用して、現在の日付に比べて有効期限を設定します。次の例では、妥当性期間を要求時間から10年に設定します。

有効期限デフォルトは「アクセスプラス10年」

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。