最新のサイトの最適化は、さまざまな側面から構成されています。 それらはすべて、ビジネスにとって非常に重要です。 最適化されたサイトを呼び出すには、次の要件を満たしている必要があります。
-可能な限り迅速に顧客の要求に対応する
-適切に設計され、使いやすい
-さまざまな身体障害を持つ人々が使用できる
-消費者のブラウザに関係なく使用できる
-最新の検索エンジンで簡単に見つけられる
これらの側面の最初のポイントである「顧客の要求に可能な限り迅速に対応する」は、おそらく最も包括的で達成が難しいでしょう。 これは、ユーザーがこのページをダウンロードするか、フォームを送信する場合、要求されたページをできるだけ早くブラウザーにロードする必要があることを意味します。
ページの高速読み込みは、クライアントのHTML / CSS / JavaScriptコードの最適化とサーバー操作の両方に依存します。
この最適化の主なアプローチは、ページ上のネットワーク作業を削減することです。 これは、クライアントからサーバーへの要求を減らす必要があることを意味します。 リクエストを減らすには、画像の数を減らす必要があります。 画像の縮小は、 CSS Sprite [1]で組み合わせることにより実現できます。 スクリプトとCSSファイルを切り取ります。 各スクリプトとCSSファイルについて、ブラウザはサーバーを呼び出します。 ファイルにクライアントマシン上のキャッシュバージョンがある場合、サーバー上のファイルに変更がなければキャッシュバージョンが使用されます。 スクリプトとCSSファイルの数を減らすための最良のソリューションの1つは、それらを結合することです。 メンテナンスを容易にするために、ほとんどのプログラマーは複数のスクリプトとCSSファイルを使用することを好みます。 それらを結合するには、サーバーにアップロードする前にそれらを結合するプログラムを使用できます。 したがって、最終的には、サーバーが要求できる1つのスクリプトと1つのCSSファイルが判明します。
これらの最適化にもかかわらず、ブラウザはサーバーに対して一定数のHTTP要求を送信します。 これらのクエリを最適化するには、完全な診断を行う必要があります。 診断と適切な計算が最適化の鍵です。 問題を特定して解決するための鍵。
単一のHTTP要求の診断は、次のコンポーネントで構成されています。
DNS時間
これは、DNSシステムがドメインをIPアドレスに変換する時間です。 クライアントをサーバーに接続する前に、まずドメイン名をサーバーのIPアドレスに変換する必要があります。
大規模なサイトでは、コンテンツに複数のドメインを使用しています。 ブラウザでは、開いている接続の数に制限があります。 さらに、1つのドメインへの同時接続には制限があります[2] 。 複数のドメインを使用すると、サイトの読み込み速度が向上しますが、これにより、DNSブロードキャストの数が増加します。
クライアントがこのドメインをIPに変換する場合、次のアクションが発生します。
たとえば、example.comを使用します
ローカルネームサーバーに対して要求が行われます。 クライアントは初めてexample.comにアクセスするため、ローカルサーバーはそれを認識しません。 また、ドメインのIPネームサーバーを知りません。 したがって、彼はいくつかのメインサーバーにアクセスします。
TLDネームサーバーを受け入れるために、メインサーバーの1つに要求が行われます。 example.comの場合、これは.comのサーバーです。
ネームサーバーexample.comのTLDサーバーが要求されます。
ネームサーバーexample.comは、ドメインが指すローカルネームサーバーIPアドレスを返します。
ローカルネームサーバーは、クライアントにドメインのIPアドレスを提供します。
example.comへの後続のリクエストでは、通常、上記のアクションは実行されませんが、ローカルネームサーバーeのキャッシュからのドメインIPアドレスが返されます。
キャッシュ時間は、その構成で説明されているTTL（Time-To-Live）ドメインによって異なります。 86,400秒（24時間）などの高いTTL値は、レコードを更新するアプリケーションの作成頻度が低くなるという点で優れています。 ただし、これにより、たとえばドメインのIPをすばやく変更する必要がある場合など、いくつかの不便が生じます。
接続時間
ドメイン名がサーバーのIPアドレスに変換された後、クライアントはこのサーバーへの接続を試みます。 接続にかかる時間は接続時間と呼ばれます。 この時間は、主にインターネットクライアントとサーバーの速度に依存します。 ルートでのパケット損失により、接続時間が大幅に遅くなる可能性があります。
クライアントは、要求ごとに新しいTCPセッションを常に開くとは限りません。 HTTP / 1.1は永続的な接続をサポートしています。つまり、1つのセッションを複数のリクエストに使用できます。 これにより、クライアントとサーバー間にハンドシェイク [3]がないため、サーバーから結果を受信する時間が大幅に短縮されます。 最新のブラウザはすべて、永続的なTCPセッションをサポートしています。
通常セッションのスキーム：
HTTP / 1.1は、一定のセッションに加えて、 HTTPパイプライン [4]も追加します 。 HTTP Pipeliningを使用すると、結果を待たずに1つのTCPセッションで複数の要求を送信できます。
HTTPパイプラインスキーム。
HTTP Pipeliningを使用するには、クライアントとサーバーの両方がそれをサポートする必要があります。 最新の一般的なブラウザでは、デフォルトでOperaのみがサポートしています。 その他では、許可する必要があるか、サポートされていません。
モバイルブラウザでは、すべてが異なります。 Opera Mobile、Opera Mini、Androidブラウザの両方で、デフォルトでHTTPパイプラインが使用されます。
サーバーは、 持続接続とHTTPパイプライニングをサポートするように構成されていることが望ましい 。 これにより、ページの読み込み時間が大幅に短縮されます。
リダイレクト時間
HTTPプロトコルにより、サーバーはクライアントを別のアドレスにリダイレクトできます。 これにより、新しい要求が発生し、その結果、クライアントが要求した情報を取得する時間が長くなります。
可能な限り、リダイレクトされたループを避けることをお勧めします。 これにより、ページの読み込み時間が確実に短縮されます。 問題に対する他の解決策がない場合にのみリダイレクトを使用します。
最初のバイトまでの時間（TTFB）
クライアントがHTTP要求をサーバーに送信した後、サーバーはそれを処理し、応答を返します。 回答としてサーバーから最初のTCPパケットを取得-これは最初のバイトを取得しています。
TTFB値が高いほど、サーバーによるリソースの処理が遅くなります。 たとえば、拡張子が.phpの動的ページをリクエストする場合。 このページから応答を受信する前に、PHPインタープリターによって処理されます。このページがデータベースと通信する可能性が高く、その後のみクライアントに応答を返します。 つまり、このようなページのTTFBは、単純な.htmlページよりも高くなります。
TTFBを知ると、サーバーがこのページを処理するのにかかる時間を知ることができます。 したがって、サーバー上でさまざまなソフトウェアの最適化を行うことができます。 TTFBの減少は、サーバーのパフォーマンスとページの読み込みの両方にとって重要です。
最後のバイトまでの時間（TTLB）
クライアントはすべてのヘッダーを受信し、最後のパケットが到着すると、応答の最後のバイトを受信します。
TTLBとTTFBの値がわかっている場合、サーバーがクライアントのリソースのコンテンツ全体を送信するのにかかる時間を決定できます。 TTLBは、TTFBとは対照的に、リソースのサイズに比例します。 ただし、TTLBが大きすぎる場合、問題はサーバーハードウェアまたはインターネット速度のいずれかです。
各リクエストと各コンポーネントの時間を受け取るように、サイトを検査できるプログラムは多数あります。 たとえば、Firebug、NETタブ。
サイトの24時間統計を提供できるプロフェッショナルなソリューションが必要な場合は、 WebSitePulseのサービスを使用できます。
WebSitePulseのサービスを使用すると、24時間監視に基づいてサイトの詳細な統計を取得できます。 サイトの読み込みのさまざまなコンポーネントの詳細なグラフを使用すると、サイトの読み込みに問題があるタイミングと偏差、低速接続とサーバー負荷のどちらで接続されているかを分析できます。 これらの統計情報は、世界のさまざまな地域で運営されているサイトのパフォーマンスの広範な概要を提供します。
1. http://en.wikipedia.org/wiki/Sprite_%28computer_graphics%29
2. http://www.browserscope.org/?category=network
3.ハンドシェイク-http ://en.wikipedia.org/wiki/Handshaking
4. HTTPパイプライン化-http ://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_servers