ウェブサイトの速度テスト:ウェブホスティングプロバイダーの速度を正しく測定する

公開: 2017-04-21

ウェブサイトの速度は多くの異なるものを参照する可能性があり、測定には通常、あいまいさや解釈の誤りが伴います。 この記事では、ウェブサイトの速度測定のいくつかの紛らわしい側面を明らかにします。 次に、速度測定レポートの解読を支援します。 最後に、Webホスティングプロバイダーの速度を測定するときに考慮する必要のあるメトリックを分析します。

例として、PingdomのWebSiteSpeedTestツールを使用します。 dareboostやWebPageTestのような多くの同様のツールがあります。よりバランスの取れた結果を得るには、それらすべてを試してみることをお勧めします。 GTMetrixとGoogleのPageSpeedInsightsもあります。 グーグルでは、まあ、あなたはグーグルツールが持っている権限を持っています。 欠点は、Webサイトの実際の応答時間(ミリ秒単位)に関する情報が得られないことです。 したがって、定量的な結果が必要な場合は、他のツールを確認する必要があります。

しかし、問題の真実は、速度測定が少し難しいということです。 最初にいくつかのことを片付けましょう。

ウェブサイトの速度の測定は…複雑です

オンラインWebサイト速度測定ツールからのレポートは、通常、Webサイトの速度に関する圧倒的な量の情報を提供します。 これは、特にこれまで使用したことがない場合は、理解するのが困難です。 まず、覚えておく必要のあるポイントがいくつかあります。

  1. ウェブサイトの速度レポートは、大きく異なるいくつかの指標を組み合わせることで、総合的な速度を示します。 これにより、Webサイトの「高速性」の全体的な概算が得られます。 ただし、Webホスティングプロバイダーの速度を評価する必要がある場合は、結果を詳しく調べる必要があります。
  2. ウェブサイトの速度テストを1回実行するだけでは、現実的なビューは得られません。 (同じツールを使用し、同じ地域から)少なくとも10の異なるテストを実行し、それに応じて結果を除算して平均を計算する必要があります。
  3. オンラインWebページ速度ツールは通常、プロバイダーまたはWebサイトにある可能性のあるキャッシュメカニズムをバイパスします。 たとえば、リクエストのリクエストヘッダーを調べると、キャッシュを無効にする2つのHTTPヘッダーが明らかになります。 このため、テストを実行している間は常にキャッシュを念頭に置く必要があります。

Webプロバイダーの速度はアプリケーションの速度とは異なります。

ウェブサイトの速度テストツールは通常、同じことをテストし、同様のタイプのデータを表示します。 前述したように、そのデータのすべてが実際にプロバイダーの速度を参照しているわけではありません。 たとえば、Youtubeなどのサードパーティサーバーから取得されたアセットは、プロバイダーの速度について何も教えてくれません。 これは、コンテンツが自分のサーバーではなく、別のサーバーに存在するためです。

サードパーティのコンテンツ(YouTubeなど)

同様に、JavascriptとCSSコードのメトリックは、Webページがブラウザでレンダリングされる速度のみを示します。

Javascriptリクエスト

ただし、プロバイダーの速度を反映するメトリックがいくつかあります。 これらは、DNS、WebブラウザがWebページに接続して結果を取得するのにかかる時間、およびその他の多くのメトリックです。 一つずつ見ていきましょう!

Pressidiumであなたのウェブサイトをホストする

60日間の返金保証

私たちの計画を見る

Webホスティングプロバイダーの速度メトリック

DNS応答時間

このメトリックは、PingDomツールで測定された、WebサイトのネームサーバーがブラウザーにIPアドレスを返すのにかかる時間を測定します。 一般に、300ms未満の値は正常と見なされます。

DNS応答時間

このメトリックに高い値が見られる場合は、その理由のトラブルシューティングを開始する必要がある場合があります。 最終的には、DNSプロバイダーを変更することを選択できます。 もちろん、DNSレコードがWebホスティングプロバイダーによって維持されている場合は、DNSメトリックを考慮する必要があります。

接続応答時間

この応答時間は、ブラウザが最初にWebサイトに接続するのにかかる時間を測定します。 これは明らかに考慮する必要のある指標です。

接続応答時間

SSL

前のスクリーンショットでは、HTTPS URLへのリダイレクトが発生していることがわかりました(左上のアイコンに表示されています)。 Pingdomは、SSLハンドシェイクが行われるのにかかる時間を測定します。 SSLハンドシェイクは、計算量の多い操作です。 それらの応答時間は、一般に、使用されているプロトコル、SSLオフロードなどの手法が存在するかどうかなどのさまざまな要因によって異なります。

SSL応答時間

SSLハンドシェイクがプロバイダーによって行われることが確実な場合にのみ、SSL応答時間を考慮する必要があります。 確信が持てない場合は、そのメトリックを除外してください。

送信メトリックは、Webブラウザーがサーバーに要求を送信するのにかかる時間です。 これは、訪問者のみのインターネット接続に関連しており、Webサイトやホスティングプロバイダーには関連していません。 したがって、そのメトリックも除外します。

待つ/受け取る

これらの応答時間は、ブラウザが実際のWebページを受信するのにかかる時間を示します。 待機時間は、サーバーがデータの送信を開始するまでブラウザが待機する時間です。 受信時間は、サーバーが実際にそのデータをブラウザーに送信するのにかかる時間を示します。

応答時間の待機/受信

これらの応答時間は両方ともWebサーバーに関連しているため、両方を考慮に入れる必要があります。

静的資産

Webサイトからローカルに提供されるファイルの応答時間も含める必要があります。 これらは静的アセットと呼ばれ、通常は画像、CSSファイル、および一般的にドメインから提供されるすべてのものです。

静的資産

最新のWebブラウザーは、実行の並列スレッドやその他の手法を使用して、リソースのダウンロードを高速化します。 たとえば、100個のリクエストがあるWebサイトがある場合、これらの100個のリクエストは並行してダウンロードされます。 Internet Explorer 10は最大8つの並列接続を使用しますが、Chromeは6を使用します。Firefox3とSafari5も6を使用します。 この値は構成可能ですが、誤用した場合はコンピューターを簡単に挽くことができるため、そのままにしておくことをお勧めします。 さらに、HTTP / 2は、以前のバージョンよりも優れたパケットストリーミング管理を備えているため、ダウンロードアクセラレーションに関して非常に役立ちます。

最後に、Pingdomを使用すると、ローカルアセットを簡単に識別できます。 [フィルター]フィールドにWebサイトのドメインを入力すると、結果をフィルター処理してローカルアセットのリクエストを表示できます。

ファイルリクエストをフィルタリングする

ローカルアセット(特に画像やビデオ)を取得するときに大幅な遅延があることに気付いた場合は、コンテンツ配信ネットワーク(CDN)の使用を検討してください。

コンテンツ配信ネットワークを使用すると、パケット損失と遅延を最小限に抑えることができます。 CDNサービスは、コンテンツを訪問者にできるだけ近づけるためにサーバーを世界中に配置し、それによって遅延を減らします。

最後に

ウェブサイトの速度測定ツールは、何を測定するかによって、批判的に評価しなければならない多くの情報を提供します。

要約すると、Webサイトの速度テストを開始する前に、次の点に注意してください。

  1. ウェブホスティングの速度とその測定方法は、ページの読み込み速度とはまったく異なります。
  2. 注意する必要のある主なメトリックは、接続/待機/受信の応答時間と静的アセットのメトリックです。 DNSとSSLは、Webホスティングプロバイダーによって管理されている場合にのみ考慮されます。
  3. Youtubeなどのサードパーティサービスから取得したコンテンツに関するすべての指標を除外します。
  4. テストを複数回(少なくとも10回)実行してから、結果をテストの数で割って平均を計算します。

アプリケーションとページのレンダリング速度のトピックは非常に重要なもう1つのトピックであるため、別の記事をそれに捧げることを計画しています。 また、多くの要因に依存するため、Webホスティング速度の測定よりもはるかに複雑であり、かなりの数の落とし穴も隠されています。