サイト速度測定ツール「Pingdom」の使い方を徹底解説

この記事では、人気のサイト速度測定ツール「Pingdom」のデータを正しく理解し、より効果的に活用する方法をご紹介します。Pingdomは、WordPressサイトのウォーターフォール分析を行うのに便利なツールで、パフォーマンス問題の特定や原因調査に役立ちます。

一方で、Pingdomの測定結果を誤って解釈した結果、かえってサイト設定やパフォーマンスを悪化させてしまうケースも少なくありません。こうしたツールは、あくまで改善の指標として活用することが重要であり、測定結果が常に100％正確とは限りません。

大切なのは、比較検証を行う際に、毎回同じツール・同じ条件で測定を行うことです。

Pingdomとは

Pingdomは、スウェーデン発の企業（現在はSolarWinds傘下）が提供するサービスで、稼働監視、ページ速度監視、トランザクション監視、サーバー監視、リアルユーザーモニタリング（RUM）など、さまざまな機能を展開しています。その中でも特に広く知られているのが、無料のサイト速度測定ツールです。WordPressコミュニティでも、非常に人気の高いパフォーマンス測定ツールのひとつとして利用されています。

人気の秘密は、その使いやすさにあります。すべての人がウェブパフォーマンスの専門家というわけではないため、他の高度な測定ツールは一般的なWordPressユーザーにとって複雑すぎることもあります。

現在、Pingdomでは世界7箇所（5大陸）のテスト拠点からウェブサイトの速度を測定できます。

• アジア：日本（東京）
• ヨーロッパ：ドイツ（フランクフルト）
• ヨーロッパ：イギリス（ロンドン）
• 北米：アメリカ（ワシントンD.C.）
• 北米：アメリカ（サンフランシスコ）
• オセアニア：オーストラリア（シドニー）
• 南米：ブラジル（サンパウロ）

なお、タイミングによっては一部のテスト拠点が利用できない場合があります。これは、メンテナンス中、またはアクセス集中による一時的な負荷が原因と考えられます。普段利用している拠点が表示されない場合は、少し時間を置いて再度確認してみてください。

また、テスト拠点の選択は、サイトをホスティングしているサーバーの場所と密接に関係しています。ここで重要になるのがネットワークレイテンシです。この点については、後ほど詳しく解説します。

Pingdomを使ったウォーターフォール分析

ウェブページは、HTML、JavaScript、CSS、画像、動画など、さまざまな要素で構成されています。これらはそれぞれ個別のリクエストを生成し、ページ表示に利用されます。一般的に、リクエスト数が多いほどサイト表示は遅くなる傾向があります。もちろん常にそうとは限りませんが、多くの場合はパフォーマンスに影響します。

以下、Pingdomの各セクションについて、それぞれの意味や、サイト全体のパフォーマンスとどのように関係するのかを解説しながら、ウォーターフォール分析の見方をご紹介します。

• Pingdom Summary（概要）
• Performance Insights（パフォーマンスインサイト）
• Response Codes（レスポンスコード）
• Content size and requests by content type（コンテンツタイプ別のコンテンツサイズとリクエスト）
• Content size and requests by domain（ドメイン別のコンテンツサイズとリクエスト）
• Waterfall Chart（ウォーターフォールチャート）
• Case Study Domain Configuration（導入事例のドメイン設定）

Pingdomの概要

WordPressサイトをPingdomで測定すると、パフォーマンススコア、合計読み込み時間、ページサイズ、そしてリクエスト数が表示されます。今回の例では、Easy Digital Downloadsを利用したECサイトを使用しており、Kinstaの高速サーバー上でホスティングされています。

ご覧のように、最初のテストではPingdomスコアは88/100、合計読み込み時間は541ミリ秒でした。また、ページ全体の合計サイズや、読み込み時に発生したリクエスト数も確認できます。

続けてもう一度テストを実行したところ、ページサイズやリクエスト数は同じにもかかわらず、合計読み込み時間は392msまで短縮されました。「なぜこんな差が出るのか？」と思うかもしれません。 Pingdomで複数回テストを実行すると、このような結果になることは珍しくありません。特に大規模サイトでは、さらに大きな差が出る場合もあります。

主な理由は次の3つです：DNSキャッシュ、CDNキャッシュ、そしてWordPressキャッシュです。そのため、速度測定を行う際は、必ず複数回テストを実施することをおすすめします。もちろん、サードパーティのリソースやAPIへの外部リクエストも、パフォーマンスに影響を与える可能性があります。この理由については、後ほどウォーターフォール分析のセクションで詳しく解説します。

WordPressサイトでPingdomスコアを改善したいですか？サイト構成や設定によっては、特にECサイトやマーケティング用ピクセルを利用している場合、100/100の満点を取るのが難しいこともあります。しかし、まずはスコア改善に取り組んでみること自体が、パフォーマンス最適化の良い出発点になります。本当に重要なのは、最終的なサイト表示速度です。

また、Web上で紹介されているパフォーマンス改善テクニックよりも、ユーザー体験を優先すべき場面もあります。表示速度だけを追い求めるのではなく、実際の使いやすさとのバランスも重要です。

とはいえ、この後のセクションでは、上記サイトでどのようにここまで高速化を実現したのか、具体的なヒントやテクニックをご紹介しますので、ぜひ読み進めてみてください。

なお、WinningWPが実施した独立系の速度比較テストでは、Kinstaは主要サーバー各社と比較して「大幅に高速」という結果となり、平均読み込み時間はわずか394ミリ秒でした。

ページのパフォーマンスを改善する

「Performance insights」（現在は「Improve page performance」）セクションは、2018年に更新され、一部の古い項目が削除される一方で、新しい項目が追加されています。これは、以前は重要とされていた改善提案の中に、現在ではそれほど重要ではなくなったものがあるためと考えられます。

ウェブパフォーマンス最適化の世界は常に変化しているため、「Pingdomで満点を取ること」だけを目的にしてしまうと、かえって本質を見失ってしまうこともあります。

これらのスコアがどのように算出されているのかを理解することが重要であることから、今回はこのセクションの内容（古い項目と新しい項目の両方）をあえて残しています。これらは基本的に、Google PageSpeed Insightsのルールに基づいて評価されています。そのため、これらの項目を改善することで、結果としてサイト全体の読み込み速度改善につながるケースが多くあります。

以下は、「Improve page performance」セクションに含まれる代表的な項目です。

• Use a Content Delivery Network (CDN)（コンテンツデリバリネットワークを使用する）
• Avoid HTTP 404 (Not Found) error（404 Not Foundエラーを避ける）
• Minimize Redirects（リダイレクトを最小限に抑える）
• Add Expires Headers（Expiresヘッダーを追加する）
• Remove Query Strings From Static Resources（静的リソースからクエリ列を削除する）
• Serve static content from a cookieless domain（Cookieを使用しないドメインから静的コンテンツを配信する）
• Compress Components with GZIP（GZIP圧縮を有効にする）
• Parallelize Downloads Across Hostnames（ホスト名を分散して並列ダウンロードを行う）
• Specify a Cache Validator（キャッシュバリデータを指定する）
• Specify a Vary: Accept-Encoding header（Vary: Accept-Encodingヘッダーを指定する）

以下、いくつかの項目を掘り下げます。

Use a Content Delivery Network (CDN)（コンテンツデリバリネットワークを使用する）

現在、WordPressサイトで導入すべき重要なサービスのひとつが、CDN（コンテンツデリバリーネットワーク）です。CDNは、世界各地に配置されたサーバーネットワーク（POP）を利用して、画像、CSS、JavaScript、動画など、WordPressサイトの静的コンテンツ（場合によっては動的コンテンツも）を高速配信する仕組みです。

Kinstaでは、すべてのホスティングプランにCDNが標準搭載されており、数クリックで有効化できます。CDNを利用することで、パフォーマンス向上（TTFBやネットワークレイテンシの低減）、帯域使用量やホスティングコストの削減、さらにはSEO面でのメリットも期待できます。

注意）現在の新しいPingdomツールには不具合があり、CDNサービスを正確に検出できない場合があります。

おすすめは以下のCDNサービスです。

• KeyCDN（Kinsta CDNのプロバイダ）
• Cloudflare
• CDN77

Kinstaが独自に行なったCDNスピードテストでは、CDNがページ読み込み時間を50％以上短縮する場合があることがわかりました。

Avoid HTTP 404 (Not Found) error（HTTP 404エラーを防ぐ）

この項目は以前、「Avoid bad requests（不正なリクエストを回避する）」という名称でした。これは現在でも重要な項目です。その名の通り、正常に処理できなかったリクエストを意味します。多くの場合、すでに削除された画像やアセットへ手動でリンクしてしまったことが原因で、404エラーが発生しています。

Pingdomでは、このエラーはオレンジ色のアイコンで表示され、レスポンスヘッダーのステータスには「404」が表示されます。

ウェブサイトのすべてのリクエストが正常に返されるようにしましょう。これにより、もはや存在しなくなったアセットにクエリが生成されないようになります。

Minimize Redirects（リダイレクトを最小限に抑える）

リダイレクトの多用は、常に注意すべきポイントです。301リダイレクト、HTTPからHTTPSへの転送、wwwあり／なしの統一など、単純なリダイレクトは一般的であり、サイトによっては必要になることもあります。しかし、リダイレクトは実行されるたびにパフォーマンスへ影響を与えます。さらに、複数のリダイレクトを重ねてしまうと、その影響はより大きくなります。これは、ページや投稿のURLだけでなく、画像リダイレクトなどにも当てはまります。

Pingdomでは、リダイレクトは青色のアイコンで表示され、レスポンスヘッダーのステータスには「301」または「302」が表示されます。

リダイレクトはサイトにどれくらい影響するのでしょうか。簡単なテストをしてみます。まず、お問い合わせページで速度を測定すると、合計読み込み時間は417ミリ秒でした。

次に、URLを少し変更して、複数のリダイレクトが与える影響を確認するために再度速度を測定すると、同じページの読み込み時間は695ミリ秒まで増えました。これは66%もの増加です。

関連して、WordPressのリダイレクトと速度改善のベストプラクティスはこちらをご覧ください。

Add Expires Headers（Expiresヘッダーを追加する）

この項目は以前、「Leverage browser caching（ブラウザキャッシュを活用する）」という名称でした。簡単に言えば、WordPressサイト上の各スクリプトには、HTTPキャッシュヘッダーを設定する必要があります（本来は設定されているべきもの）。これにより、ブラウザがファイルをどれくらいの期間キャッシュするかが決まります。

この問題を改善するには、利用しているサーバー環境で、cache-controlヘッダーとexpiresヘッダーが適切に設定されていることを確認してください。Kinstaでは、これらのヘッダーはデフォルトで設定されています。

サーバーへ手動でキャッシュヘッダーを追加する方法、またExpiresヘッダーの設定方法はこちらをご覧ください。

もうひとつの問題は、サードパーティ製スクリプトを読み込む場合、自分ではキャッシュヘッダーを追加できないことです。これは、それらのウェブサーバーを管理していないためです。代表的な例としては、Google アナリティクスのスクリプトや、Facebook・Twitterなどのマーケティングピクセルがあります。

この問題への対策としては、Google アナリティクスのスクリプトをローカルでホストする方法があります（ただし、これはGoogle公式サポート対象ではありません）。また、WP Rocketでは、Facebookマーケティングピクセルをローカル配信する機能も提供されています。

スクリプトをローカル配信した場合のパフォーマンス改善効果は、サイト構成によって異なります。ただし、ファイルを自分で管理できるため、CDN経由で配信できる点は大きなメリットです。また、サードパーティへのDNSリクエストを削減できる利点もあります。一方で、これらのスクリプトは、すでにユーザーのブラウザ側でキャッシュされている場合もある点には注意が必要です。

この推奨事項への詳しい対処法はこちらをご覧ください。

Remove Query Strings From Static Resources（静的リソースからクエリ列を削除する）

クエリ文字列異常もよくある課題です。CSSファイルとJavaScriptファイルのURLの最後には、通常https://domain.com/file.min.css?ver=4.5.3などのファイルバージョンがあります。ただし、クエリ文字列をキャッシュできないサーバーとプロキシサーバーがあるため、削除することでキャッシュが改善できます。これには、クエリ文字列をワンクリックで削除できるPerfmattersなどの有料プラグインが便利です。

または、以下のコードをテーマのfunctions.phpファイルへ手動で追加することもできます。よりおすすめなのは、無料のCode Snippetsプラグインを使ってコードを追加する方法です。この方法であれば、テーマファイルを直接編集する必要がありません。

function remove_query_strings() {
 	 	 if(!is_admin()) {
 	 	 add_filter('script_loader_src', 'remove_query_strings_split', 15);
 	 	 add_filter('style_loader_src', 'remove_query_strings_split', 15);
 	 	 }
 	 	}
 	 	function remove_query_strings_split($src){
 	 	 $output = preg_split("/(&ver|\?ver)/", $src);
 	 	 return $output[0];
 	 	}
 	 	add_action('init', 'remove_query_strings');

サイトからクエリ文字列をすぐに削除する前に、なぜそれが使われているのかを理解しておくことが重要です。WordPress開発者は、キャッシュ関連の問題を回避するために、ファイルへバージョン番号を付与することがよくあります。

たとえば、アップデート時にstyle.cssが?ver=4.6から?ver=4.7へ変更されると、ブラウザ側では完全に新しいURLとして認識され、古いキャッシュを利用しなくなります。もしクエリ文字列を削除した状態でプラグインを更新すると、古いキャッシュファイルが引き続き配信されてしまう可能性があります。その結果、キャッシュの有効期限が切れるか、完全に削除されるまで、サイト表示が崩れるケースもあります。

また、一部のCDNではクエリ文字列付きURLもキャッシュ可能です。Kinsta CDNではデフォルトでこれに対応しており、Kinsta利用者のアセットはクエリ文字列付きでも問題なくキャッシュされます。

静的リソースからクエリ文字列を削除する詳しい方法はこちらをご覧ください。

Serve static content from a cookieless domain（Cookieを使用しないドメインから静的コンテンツを配信する）

「Serve static content from a cookieless domain（Cookieを使用しないドメインから静的コンテンツを配信する）」警告への対処についてはこちらで詳しくご説明しています。しかし、HTTP/2のような新しい通信プロトコルでは、この最適化の重要性は以前ほど高くありません。

というのも、新しい接続を複数作成するよりも、同じ接続上でまとめて配信したほうが効率的なケースが増えているためです。この警告に対応したい場合は、Cookieを除外して配信できるCDNを利用するか、静的コンテンツ専用の別ドメイン／サブドメインを用意する方法があります。

Compress Components with GZIP（GZIP圧縮を有効にする）

「Compress Components with GZIP（GZIP圧縮を有効にする）」警告は、PingdomがGZIP圧縮されていないアセットを検出した際に表示されます。GZIPは、HTML、CSS、JavaScriptなどのテキストベースのファイルサイズを削減するための圧縮方式です。サーバー側で有効化することで、Webページや各種アセットを圧縮した状態で訪問者へ配信できます。

実際のテストでは、GZIP圧縮を有効化することで、リクエストファイルサイズを78%以上削減できました。

Kinstaでは、GZIP圧縮を有効化する必要はありません。すべてのKinstaサイトでは、GZIPより高速な圧縮方式であるBrotli圧縮がすでに有効になっています。これは、Kinsta独自のCloudflare統合によって実現されています。そのため、Kinstaでホスティングされたサイトは、GZIPを使用する一般的な環境よりも高速に動作し、モバイル端末など通信環境が限られるデバイスでも快適に表示されます。

もしサーバー側でGZIPを有効化した後も、この推奨項目が表示される場合は、サイト内で読み込まれている外部アセットの配信元サーバーで、GZIPまたはBrotli圧縮が有効になっていない可能性があります。その場合、配信元サーバー側の設定によるため、利用者側で変更できることは基本的にありません。

Parallelize Downloads Across Hostnames（ホスト名を分散して並列ダウンロードを行う）

Specify a Cache Validator（キャッシュバリデータを指定する）

この警告は、本来すべてのオリジンサーバーのレスポンスに含まれるべきHTTPキャッシュヘッダーが不足している場合に表示されます。これらのヘッダーは、キャッシュの有効性を確認し、キャッシュ期間を指定する役割を持ちます。ヘッダーが見つからない場合、リソースを読み込むたびに新しいリクエストが発生し、サーバー負荷の増加につながります。対象となるヘッダーには、last-modified、ETag、Cache-Control、およびExpiresなどがあります。

「Leverage browser caching（ブラウザキャッシュを活用する）」警告と同様に、通常はWordPressサーバー側でこれらのヘッダーが自動的に追加されるべきです。サードパーティリクエストでこの警告が表示されている場合は、その配信元サーバーを管理できないため、利用者側で対応することはできません。

この推奨事項の対処方法はこちらをご覧ください。

Specify a Vary: Accept-Encoding header（Vary: Accept-Encodingヘッダーを指定する）

「Specify a Vary: Accept-Encoding header（Vary: Accept-Encodingヘッダーを指定する）」への対処方法はこちらでご紹介しています。

これはHTTPヘッダーの一種で、オリジンサーバーのすべてのレスポンスに含まれているべきものです。このヘッダーは、ブラウザ側が圧縮されたコンテンツを処理できるかどうかをサーバーへ伝える役割を持っています。Kinstaでは、このヘッダーはすべてのサーバーで自動的に設定されています。

Response codes

Pingdomの次のセクションは、「Response codes」です。レスポンスコード（HTTPステータスコードとも呼ばれます）は、ウェブサーバーがページ上部へ付加する短いメッセージのようなものです。これは、ページ表示リクエストを受け取った際に、サーバー側でどのように処理されたかを知らせるためのものです。代表的なレスポンスコードには、以下のようなものがあります。

• 200 “Everything is OK.”：ウェブページまたはリソースが期待どおりに動作するときに返される

  

• 301 “The requested resource has been moved permanently.”： ウェブページやリソースが別の場所へ恒久的に移動した際に返されるコードで、恒久的なURLリダイレクトに使用されます。

  

• 404 “The requested resource was not found.”：最もよく見られるエラーコードのひとつです。このコードは、要求されたリソースが存在しない場合に返され、サーバー側でもそのリソースの存在を確認できないことを示します。

  

HTTPステータスコードの詳細はこちらをご覧ください。

Content size and requests by content type

次のセクションは、「Content size by content type（コンテンツタイプ別コンテンツサイズ」と「Requests by content type（コンテンツタイプ別のリクエスト）」です。ウェブページのリソースを最も消費しているものを特定するのに役立ちます。HTTP Archiveによると、一般的なウェブページでは、画像が全体サイズの約43％を占めています。

ただし、以下のサイト例のように、必ずしも画像が最大割合を占めるとは限りません。

画像最適化の詳細はこちらをご覧ください。画像をさらに圧縮し、ページサイズ全体の大部分を占めないようにするための便利なツールやプラグインも数多く存在します。

また、上記の例では、画像の代わりに大きなFont Awesomeアイコンを活用しています。これは、ページサイズ削減に大きく貢献する有効な手法のひとつです。コンテンツサイズ全体をさらに削減するそのほかの技はこちらでもご紹介しています。

Content size and requests by domain（ドメイン別のコンテンツサイズとリクエスト）

「Content size and requests by domain（ドメイン別のコンテンツサイズとリクエスト）」セクションでは、サイト上で利用されている外部サービスやスクリプトを素早く確認できます。

今回の例では、ほとんどのアセットがCDN経由で配信されていることが分かります。また、ウェブサーバーから配信される初期HTML（DOC）読み込みに加え、Google アナリティクスのドメインへの外部リクエストも確認できます。サイトによっては、さらに多くの外部サービスが読み込まれている場合があります。たとえば、Facebook、Twitter、Hotjar、SumoMe、AdRoll、New Relic、Crazy Eggなどが代表的です。

一般的には、外部リクエストは少ないほど望ましいとされています。というのも、外部サービスを利用するたびに、レイテンシ、TLSハンドシェイク、DNSルックアップなどの追加処理が発生するためです。WordPressサイトで利用されている外部サービスの特定や分析についてはこちらをご覧ください。

基本的には、リクエスト数をできる限り減らし、アセットを1か所へ集約するのが理想です。たとえば、WebサーバーやCDN側で直接配信する方法があります。代表的な例がFont Awesomeです。外部CDNのスクリプトへ直接リンクするのではなく、Font Awesomeをダウンロードして、自分のサーバー側から配信する方法が推奨されます。

Waterfall Chart

最後は、リクエストに関連のセクションです。ここでは、ウェブページ上のすべてのリクエストをウォーターフォールチャート形式で表示できます（以下参照）。

このチャートを使うことで、各リクエストを個別に分析し、どこで遅延やパフォーマンス問題が発生しているのかを確認できます。これが、いわゆる「ウォーターフォール分析」です。

以下では、各ステータスカラーの意味について、さらに詳しく見ていきます。

DNS（ピンク色）

では、DNSとは何でしょうか。簡単に言えば、インターネット上の「電話帳」のようなものです。DNSサーバー（Domain Name Server）には、サイトの情報や、そのサイトがどのIPアドレスへ接続されるべきかが保存されています。

Pingdomでサイトを初めて測定する際には、新規DNSルックアップが実行されます。そのため、DNSレコードへ問い合わせを行い、IPアドレス情報を取得する必要があります。これにより、追加のルックアップ時間が発生します。

また、DNSサーバー自体の設置場所も、パフォーマンスへ影響します。

Pingdomでサイトを複数回測定すると、DNS情報がキャッシュされるため、すでにIPアドレス情報を取得済みとなり、再度DNSルックアップを行う必要がなくなります。これが、Pingdomで複数回テストすると、サイトがより高速に表示される理由です。

下の画面を見ると、2回目のテストでは、初期DOC読み込み時のDNSルックアップ時間が3.6ミリ秒になっています。通常は、リクエストがキャッシュされることで、最終的には0ミリ秒近くまで下がります。実は、この挙動を誤解してしまう人はかなり多いです。

サイトを複数回計測すると、PingdomがIP情報をすでに知っているためDNSをキャッシュし、再度ルックアップを実行する必要はありません。これはPingdomを複数回使用するとサイトがより速くなったように見える理由の1つです。

また、有料DNSサービスを利用することで、さらにDNSパフォーマンスを最適化できます。加えて、多くの追加機能も利用可能です。Cloudflareの無料DNSも非常に高速です。あわせて、Cloudflare APOもチェックしてみてください。

サイトを複数回テストすると高速化して見える理由は、DNSキャッシュ以外にもあります。そのひとつが、コンテンツデリバリネットワーク（CDN）の利用です。CDNに馴染みがない方のために説明すると、CDNとは、JS、CSS、画像などのコンテンツを、訪問者に近い場所にある世界中のサーバーへキャッシュ配信する仕組みです。Pingdomで最初にサイトを測定した際には、CDNからアセットを新規取得する必要がある場合があります。CDNキャッシュもDNSと似た仕組みで、一度キャッシュされると、その後の読み込みは大幅に高速化されます。

DNS高速化のもうひとつの方法として、「DNSプリフェッチ」もあります。これは、ブラウザがページ読み込みの裏側で事前にDNSルックアップを実行する仕組みです。WordPressサイトのheader部分へ数行のコードを追加することで利用できます。以下に例を紹介します。

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

また、WordPress 4.6以降を使用している場合は、リソースヒントを利用する方法もあります。開発者はwp_resource_hintsフィルターを使って、dns-prefetch、preconnect、prefetchなどに任意のドメインやURLを追加できます。

SSL（紫色）

HTTPSには多少のオーバーヘッドがありますが、HTTP/2の登場によって、その影響は以前ほど大きくありません。HTTP/2はウェブ表示を高速化するための新しい通信プロトコルであり、利用するにはHTTPSが必須となります。HTTP/2の詳細はこちらをご覧ください。

また、2018年時点でも、すべての事業者がHTTP/2へ対応していたわけではありません。これはウェブサーバー側だけでなく、CDN側も同様です。そのため、サーバーやCDNを選ぶ際は、両方がHTTP/2へ対応しているかを確認することが重要です。Kinstaでは、すべてのWordPressユーザーにHTTP/2対応環境を提供しています。

さらに、Pingdomは2018年半ばに、速度テストツールをChrome 60以降へアップグレードしました。リクエストヘッダー内のUser-Agentからも確認できます。以前はChrome 39を使用していましたが、ChromeがHTTP/2へ正式対応したのはバージョン49以降です。そのため、現在のPingdomでは、HTTP/2による高速化効果を正しく反映したテスト結果を確認できるようになっています。

Connect（青色）

Pingdomにおける「Connect（接続）」は、TCP接続にかかった時間を指します。つまり、クライアント（ブラウザ）とサーバー間でTCP接続を確立するために必要だった合計時間です。仕組みを細かく理解する必要はありませんが、これはブラウザとサーバーが通信を開始する前に行う基本的な接続処理だと考えると分かりやすいでしょう。

Wait（黄色）

「Wait（待ち時間）」は、TTFB（Time To First Byte）を意味しています。ウェブサーバーやネットワークリソースの応答速度を測定する指標です。

一般的には、100ミリ秒以下であれば良好なTTFBとされています。一方で、300〜400ミリ秒に近づいている場合は、サーバー設定に問題があるか、より高性能なサーバー環境への移行を検討すべきタイミングかもしれません。

TTFBを減らす手っ取り早い方法は、WordPressキャッシュとCDNの効果的な活用です。以下、簡単なテストを行ってみます。

WordPressサーバーキャッシュなしのTTFB

まず、WordPressサイトのキャッシュを削除した状態でテストを実施しました。この場合、キャッシュを再生成する必要があります。その結果、合計読み込み時間は541ミリ秒、初回リクエスト時のTTFB（Wait）は185.2ミリ秒でした。

WordPressサーバーキャッシュありのTTFB

続いて、再度テストを実行しました。今度はキャッシュから直接配信されています。ご覧のように、合計読み込み時間は392ミリ秒まで短縮され、初回リクエスト時のTTFBも52.8ミリ秒まで改善しました。これが、キャッシュによる効果です。

日本各地、あるいは世界中に訪問者がいるサイトの場合、TTFBを大幅に改善する簡単な方法のひとつがCDNの利用です。今回も例によって、その違いを確認するためにいくつかテストを実施しました。

CDNなしのTTFB

CDNありのTTFB

今回は、CDNによる効果を分かりやすく比較するため、「Pacific – Australia – Sydney」ロケーションからテストを実行しました。

今回の例で使用しているWordPressサイトは、米国中央部にあるKinstaサーバーでホスティングされています。その状態でオーストラリアから測定することで、Kinsta CDNのキャッシュによって表示速度がどれほど向上し、TTFBがどれだけ削減されるかを確認できます。もちろん、TTFBを改善するうえでは、適切に設計されたアーキテクチャを持つ高品質なWordPressサーバーを選ぶことも非常に重要です。

Send（オレンジ色）、Receive（緑色）

Pingdomの「Send（送信）」と「Receive（受信）」ステータスはその名の通りです。前者はウェブブラウザがサーバにデータを送信するのにかかる時間で、後者はウェブブラウザがサーバーからデータを受信するのにかかる時間です。通常、どちらも非常に低いか、0になります。

HTTP Response Headers

今回使用したサイトのドメイン設定

最後に、今回の測定で使用した実際の構成をご紹介します。ぜひ参考にしてみてください。「改善のヒントやケーススタディを紹介していても、実際の設定内容までは公開されていない」というケースは少なくないため、先ほど紹介した導入事例用ドメインで実際に使用した構成をそのまま掲載しています。

アーキテクチャ

• ドメインは、米国リージョンのKinstaサーバーでホスティングされています。Kinstaでは現在、27箇所のデータセンターから選択可能です。
• KinstaではHTTP/2、Nginx、MariaDBを採用しており、これらが高速な読み込み速度に貢献しています。
• サイトでは、Kinsta CDNの基盤となっているKeyCDNを利用しています。CDN帯域はすべてのホスティングプランに無料で含まれています。
• キャッシュプラグインは使用していません。Kinstaではサーバーレベルですべてをキャッシュするため、構成を大幅にシンプルにできます。
• サイトではPHP 7.3を使用しています。PHPは新しいバージョンほどパフォーマンスが大きく向上する傾向があります。詳しくはPHPベンチマークをご覧ください。Kinstaでは、クリック操作だけでPHPバージョンを変更できます。

WordPressのプラグインとテーマ

以下は、このWordPress ECサイトのパフォーマンスへ影響しているプラグインやテーマの一覧です。

• 画像の圧縮：Imagifyプラグイン（有料）
• WordPressサイトへSVG画像をアップロード：Safe SVGプラグイン（無料）
• EDDサイトの構築：GeneratePressテーマ（有料）

関連記事

• WordPressのレンダリングを妨げるリソースを除外する方法（CSSとJavaScript）
• WordPressで絵文字を無効にする方法
• WordPressで埋め込みを無効にする方法
• Google PageSpeed Insightsで100点満点を取る意味
• WordPressサイトのAdmin-Ajaxの過剰な使用の原因を特定する方法

まとめ

速度測定ツール「Pingdom」の使い方を理解して活用することで、パフォーマンス改善において、よりデータに基づいた判断ができるようになります。

また、「Waterfall Chart（ウォーターフォールチャート）」は、各アセットがどのように読み込まれているか、そしてWordPressサーバー、物理的なサーバーロケーション、CDNなどからどのような影響を受けているかを把握するうえで非常に重要です。

この記事が、サイト速度やパフォーマンス改善のトラブルシューティングに役立てば幸いです。