ホームページ >ウェブフロントエンド >htmlチュートリアル >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 などのヘッダー オプションを追加してキャッシュすることを指定しない限り、キャッシュされません。
ただし、ジャンプするとユーザーエクスペリエンスが低下することに注意してください。ユーザーと 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 はブラウザーのデフォルト形式を削除するのに役立ちます。これは、改行効果があるからではなく、意味的に意味がある場合にのみ
9. iframe の数を最小限に抑える
ifrmae 要素は、親ドキュメントに新しい HTML ドキュメントを挿入できます。 iframe をより効果的に使用するには、iframe の仕組みを理解することが重要です。
18. CSS 式の使用を避ける (式)
CSS 式は、CSS プロパティを動的に設定する強力な (ただし危険な) 方法です。 Internet Explorer では、バージョン 5 以降の CSS 式がサポートされています。次の例では、CSS 式を使用して、1 時間ごとに背景色を切り替えることができます。上記のように式にはJavaScript式を使用しています。 CSS プロパティは、JavaScript 式の評価に基づいて設定されます。この式メソッドは他のブラウザでは機能しないため、クロスブラウザ設計では Internet Explorer 専用に設定すると便利です。
式の問題は、私たちが思っているよりも頻繁に評価されることです。ページを表示して拡大したときだけでなく、ページをスクロールしたときやマウスを移動したときも再計算されます。 CSS 式にカウンターを追加して、式が評価される頻度を追跡します。ページ上でマウスを動かすだけで、10,000 を超える計算を簡単に実行できます。
CSS 式が評価される回数を減らす 1 つの方法は、1 回限りの式を使用することです。これは、最初の実行時に結果を指定されたスタイル属性に割り当て、CSS 式の代わりにこの属性を使用します。ページ サイクル中にスタイル プロパティを動的に変更する必要がある場合は、CSS 式の代わりにイベント ハンドラーを使用することが現実的なオプションです。 CSS 式を使用する必要がある場合は、CSS 式が何千回も評価され、ページのパフォーマンスに影響を与える可能性があることを必ず覚えておいてください。
19. 外部 JavaScript と CSS の使用
多くのパフォーマンス ルールは、外部ファイルの処理方法に関するものです。しかし、これらの手順を実行する前に、より基本的な質問をするかもしれません。JavaScript と CSS は外部ファイルに配置する必要があるのか、それともページ自体の中に配置する必要があるのでしょうか。
JavaScript ファイルと CSS ファイルの両方がブラウザでキャッシュを引き起こす可能性があるため、実際のアプリケーションで外部ファイルを使用すると、ページ速度が向上します。 HTML ドキュメントに組み込まれている JavaScript と CSS は、リクエストごとに HTML ドキュメントとともに再ダウンロードされます。これにより HTTP リクエストの数は減りますが、HTML ドキュメントのサイズは増加します。一方、外部ファイルの JavaScript や CSS をブラウザがキャッシュすると、HTTP リクエストの数を増やすことなく HTML ドキュメントのサイズを削減できます。重要な問題は、外部 JavaScript および CSS ファイルのキャッシュの頻度が HTML ドキュメントがリクエストされる回数に関係していることです。ある程度の難易度はありますが、それでも測定できる指標はいくつかあります。ユーザーがセッション中にサイト上の複数のページを表示し、それらのページ間で同じスクリプトとスタイルシートが再利用される場合、外部ファイルをキャッシュすると大きなメリットが得られます。
多くのウェブサイトには、これらの指標を構築する機能がありません。このようなサイトの場合、JavaScript と CSS を外部ファイルとして参照するのが最善の解決策です。組み込みコードを使用する良い例外は、Yahoo! ホームページや My Yahoo! などの Web サイトのホームページです。セッションあたりのビュー数が少ない (おそらく 1 つだけ) ホームページの場合、JavaScript と CSS が組み込まれていると、エンド ユーザーの応答時間が短縮される場合があります。
ページビューが大きいホームページの場合、組み込みコードによる HTTP リクエストの削減の利点と、外部ファイルの使用によるキャッシュの利点のバランスを取ることができる手法があります。その 1 つは、ホームページに JavaScript と CSS を組み込むことですが、ページのダウンロード後に外部ファイルを動的にダウンロードすることです。これらのファイルがサブページで使用される場合、それらのファイルはすでにブラウザーにキャッシュされています。
20. JavaScript と CSS をカットします
合理化とは、コードから不要な文字を削除してファイル サイズを削減し、ダウンロード時間を節約することを指します。コードを減らす場合は、すべてのコメント、不要な空白文字 (スペース、改行、タブ インデント) などを削除する必要があります。 JavaScript では、ダウンロードする必要があるファイル サイズが小さくなるため、応答時間が短縮されます。 JavaScript を合理化するために最も広く使用されている 2 つのツールは、JSMin と YUI Compressor です。 YUI Compressor を使用して CSS を縮小することもできます。
難読化は、ソースコードの最適化に使用できるもう 1 つの方法です。このアプローチは合理化よりも複雑で、難読化プロセスで問題が発生する可能性が高くなります。米国の上位 10 の Web サイトを対象とした調査では、合理化によって元のコード サイズが 21% 削減され、難読化によって 25% に達する可能性があることがわかりました。難読化によりコードをより適切に縮小できますが、JavaScript では縮小のリスクが低くなります。
外部スクリプトとスタイルシート ファイルの解析に加えて、<script> および <style> コード ブロックも解析する必要があります。 Gzip を使用してスクリプトやスタイルシートを圧縮する場合でも、これらのファイルを圧縮すると 5% 以上のスペースを節約できます。 JavaScript と CSS の能力とサイズが増大するにつれて、コードの削減にメリットが生まれます。 </p> <p>21. @import の代わりに <link> を使用します</p> 前の最良の実装では、順序立てて読み込んで表示しやすくするために CSS を先頭に配置する必要があると述べました。 <p>IE では、ページ下部の @import は <link> を使用するのと同じ効果があるため、使用しないことをお勧めします。 <br> </p>22. フィルターの使用を避ける <p> </p> IE の独自属性 AlphaImageLoader は、7.0 より前のバージョンで表示される PNG 画像の半透明効果を修正するために使用されます。このフィルタの問題は、ブラウザが画像を読み込むときにコンテンツのレンダリングが停止し、ブラウザがフリーズすることです。画像だけでなくすべての要素に対して 1 回ずつ動作するため、メモリのオーバーヘッドが増加するため、問題は多面的です。 <p>AlphaImageLoader の使用を完全に回避する最善の方法は、代わりに IE で適切に動作する PNG8 形式を使用することです。どうしても AlphaImageLoader を使用する必要がある場合は、underscore_filter を使用して IE7 以降のユーザーに対して無効にしてください。 <br> </p>23. スクリプトをページの下部に配置します <p> </p>このスクリプトの問題は、ページの並行ダウンロードを妨げることです。 HTTP/1.1 仕様では、ブラウザがホスト名ごとに同時にダウンロードできるのは 2 つまでであることが推奨されています。イメージが複数のホスト名に配置されている場合は、各並列ダウンロードで 2 つ以上のファイルを同時にダウンロードできます。ただし、スクリプトをダウンロードするとき、ホスト名が異なる場合でも、ブラウザは他のファイルを同時にダウンロードしません。 <p>場合によっては、スクリプトをページの下部に移動するのが簡単ではない場合があります。たとえば、スクリプトで document.write を使用してページ コンテンツを挿入する場合、それを下に移動することはできません。ここでスコープの問題も発生する可能性があります。多くの場合、この点で問題が発生します。 <br>頻繁に使用される代替方法は、遅延スクリプトを使用することです。 DEFER 属性は、document.write がスクリプトに含まれていないことを示し、ブラウザーに表示を継続するように指示します。残念ながら、Firefox は DEFER 属性をサポートしていません。 Internet Explorer では、スクリプトが遅延することがありますが、予想どおりではありません。スクリプトを遅らせることができる場合は、ページの下部に移動できます。これにより、ページの読み込みが速くなります。 <br> </p>24. 重複したスクリプトを削除する<p> </p>同じページ内で JavaScript ファイルを繰り返し参照すると、ページのパフォーマンスに影響します。これは珍しいことだと思うかもしれません。米国の上位 10 の Web サイトを調査したところ、そのうち 2 サイトでスクリプトの参照が繰り返し行われていることがわかりました。スクリプトが 2 回参照されるという奇妙な現象が発生する主な要因は 2 つあります。それは、チームの規模とスクリプトの数です。この場合、重複したスクリプトにより不要な HTTP リクエストや無駄な JavaScript 操作が発生し、Web サイトのパフォーマンスが低下する可能性があります。 <p>Internet Explorer では不要な HTTP リクエストが生成されますが、Firefox では生成されません。 Internet Explorer では、スクリプトが 2 回参照され、キャッシュ可能でない場合、ページ読み込みプロセス中に 2 つの HTTP リクエストが生成されます。ライブ スクリプトをキャッシュすると、ユーザーがページをリロードするときに追加の HTTP リクエストが発生する可能性があります。 <br> HTTP リクエストを追加するだけでなく、スクリプトを複数回実行すると時間も無駄になります。 Internet Explorer と Firefox には、スクリプトがキャッシュ可能かどうかに関係なく、JavaScript を再評価するという問題があります。 <br>同じスクリプトが 2 回参照されることを避ける 1 つの方法は、スクリプト管理モジュールを使用してテンプレート内のスクリプトを参照することです。 <script /> タグを使用して HTML ページでスクリプトを参照する最も一般的な方法は、次のとおりです。 <br><script type=”text/javascript” src=”menu_1.0.17.js”></script>
PHP では、insertScript と呼ばれるメソッドを作成することで置き換えることができます:
25. DOM アクセスを減らす
JavaScript を使用して DOM 要素にアクセスすると時間がかかるため、より多くのページを取得するには、次のようにする必要があります:
アクセスされた関連要素をキャッシュします。ノードをドキュメント ツリーに追加する前にオフラインで更新します。ページ レイアウトの変更に JavaScript を使用しないでください。詳細については、YUI トピックの Julien Lecomte の記事「高性能 Ajax」を参照してください。 。 手順"。
26. スマート イベント ハンドラーを開発する
ページが応答しないと感じることがあります。これは、DOM ツリー要素にアタッチされているイベント ハンドラーが多すぎて、一部のイベント ハンドラーが頻繁にトリガーされることが原因です。これが、イベント委任を使用することが良いアプローチである理由です。 div 内に 10 個のボタンがある場合、ボタンごとにハンドラーを追加するのではなく、div にイベント ハンドラーを 1 回アタッチするだけで済みます。イベントが発生するときにそれをキャプチャし、どのイベントがそのイベントを引き起こしたかを判断できます。
DOM ツリーを操作するために onload イベントの発生を待つ必要もありません。必要なのは、アクセスしたいツリー構造内の要素が表示されるのを待つことだけです。すべての画像が読み込まれるまで待つ必要もありません。
イベント アプリケーションで onAvailable メソッドの代わりに DOMContentLoaded イベントを使用することもできます。
HTTP Cookie は、権限の検証や個人化された ID などのさまざまな目的に使用できます。 Cookie 内の関連情報は、HTTP ファイル ヘッダーを通じて Web サーバーとブラウザーの間で通信されます。したがって、ユーザーの応答時間を短縮するために、Cookie をできるだけ小さく保つことが重要です。
詳細については、Tenni Theurer と Patty Chi の記事「When the Cookie Crumbles」をご覧ください。この調査には主に次の内容が含まれます。
不要な Cookie を削除し、ユーザーの応答への影響を軽減するために、アダプティブ レベルのドメイン名に Cookie を設定するように注意します。 適切な有効期限を設定します。有効期限を早め、Cookie をクリアするのが早すぎないようにすると、ユーザーの応答時間が短縮されます。
ブラウザが静的な画像をリクエストし、リクエスト内で同時に Cookie を送信する場合、サーバーはこれらの Cookie を一切使用しません。したがって、これらはネットワーク送信のいくつかの否定的な側面のために作成されただけです。静的コンテンツに対するリクエストが Cookie を含まないリクエストであることを確認する必要があります。サブドメインを作成し、それを使用してすべての静的コンテンツをホストします。
ドメイン名が www.example.org の場合、static.example.org に静的コンテンツを含めることができます。ただし、www.example.org ではなくトップレベル ドメイン名 example.org に Cookie を設定すると、static.example.org へのすべてのリクエストに Cookie が含まれるようになります。この場合、新しいドメイン名を購入して静的コンテンツを保存し、このドメイン名を Cookie なしで保存できます。 Yahoo! は ymig.com を使用し、YouTube は ytimg.com を使用し、Amazon は image-anazon.com を使用します。
静的コンテンツを保存するために Cookie を使用しないドメイン名を使用するもう 1 つの利点は、一部のプロキシ (サーバー) が Cookie コンテンツ要求のキャッシュを拒否する可能性があることです。関連する提案は、ホームページとして example.org と www.example.org のどちらを使用するかを決定したい場合は、Cookie の影響を考慮する必要があるということです。 www を無視すると、Cookie を *.example.org (* はすべてのサブドメインを表す汎ドメイン名解決です、翻訳者の Dudo の注) に設定する以外に選択肢がないため、パフォーマンス上の理由から、Have a を使用するのが最善です。 www のサブドメインを設定し、そこに Cookie を設定します。
29. 画像を最適化する
画像の数を確認できます。 GIF 画像の色は と一致しています。 カラー パレットの仕様は一致しています。 imagemagick で次のコマンド ラインを使用すると簡単に確認できます:
identify -verbose image.gif画像で 4 色のみが使用されていて、256 色のスロットがパレットに表示されていることがわかった場合、この画像はまだ存在します。圧縮の余地。 GIF 形式を PNG 形式に変換して、スペースが節約されるかどうかを確認してください。ほとんどの場合、圧縮できます。ブラウザのサポートが限られているため、デザイナーは PNG 形式の画像を使用することに消極的ですが、これは過去のことです。現時点での唯一の問題は、トゥルー カラー PNG 形式のアルファ チャネルの半透明性ですが、同様に、GIF はトゥルー カラー フォーマットではなく、半透明性をサポートしていません。したがって、GIFでできることはPNG(PNG8)でもできます(アニメーションを除く)。この簡単なコマンドは、GIF を PNG に安全に変換できます:
convert image.gif image.png31. HTML で画像を拡大縮小しないでください
HTML で高さと幅を設定するためだけに必要以上に大きい画像を使用しないでください。必要な場合:
その場合、代わりに写真 (mycat.jpg) を 100×100 ピクセルにする必要があります。 500×500ピクセルの画像を縮小します。
favicon.ico はサーバーのルート ディレクトリにある画像ファイルです。役に立つかどうかを気にしない場合でもブラウザが要求するため、存在する必要があります。そのため、404 Not Found 応答を返さないことが最善です。同じサーバー上にあるため、Cookie は要求されるたびに送信されます。この画像ファイルは、ダウンロード順序にも影響します。たとえば、IE では、onload で追加ファイルをリクエストすると、追加コンテンツがロードされる前にファビコンがダウンロードされます。
したがって、favicon.ico によって引き起こされるデメリットを軽減するには、次のことを行う必要があります:
適切な時点 (つまり、変更する予定がないとき) は、ファイルをできるだけ小さく、できれば 1K 未満に保つ新しいファイルを変更するときは名前を変更できないため、favicon.ico をもう一度やり直します) Expires ファイルヘッダーを設定します。 Expires ヘッダーを数か月後に安全に設定できます。これは、現在の favicon.ico が最後に編集された時間を確認することで判断できます。
33. 個々のコンテンツを 25K 未満に保つ
この制限は主に、iPhone が 25K を超えるファイルをキャッシュできないことが原因です。これは解凍後のサイズを指すことに注意してください。 gizp 圧縮だけでは要件を満たさない可能性があるため、ファイルを合理化することが非常に重要です。
詳細については、Wayne Shea と Tenni Theurer の論文「Performance Research, Part 5: iPhone Cacheability? Making it Stick」を参照してください。
ページのコンテンツを複合テキストにパッケージ化すると、1 つの HTTP リクエストで複数のコンポーネントを取得できるようになります (HTTP リクエストは非常に贅沢です)。このルールを使用する場合は、まずユーザー エージェントがそれをサポートしていることを確認してください (iPhone はサポートしていません)。