今回は、人気のあるウェブサイトスピードテストツールPingdomのデータの理解かつより改善した利用について説明します。PingdomはWordPressウェブサイトの滝分析という分析を行うのに便利です。これにより、性能問題が診断しやすくなり、誤診断することがなくなります。

しかし、WordPressユーザーがPingdomスピードテストツールのデータを間違って解釈し、ウェブサイトを以前よりも悪化したコンフィギュレーションに設定することも少なくありません。このようなツールはあくまでもガイドとして使用すべきものであり、100%正確であるとは限りません。ポイントは、すべてのテストで同じツールを使用することです。

Knowing how to properly analyze the data from @Pingdom can help you speed up your WordPress site! ⏱ Click to Tweet

Pingdom

Pingdomは、アップタイム監視、ページ速度の監視、トランザクションの監視、サーバーの監視、訪問者のインサイト(RUM)などを提供するスウェーデンを拠点とする会社です(現在SolarWindsにより所有)。彼らの最もよく知られているサービスの1つは、おそらく無料のウェブサイトスピードテストツールです。WordPressコミュニティ上の最も人気のある性能テストツールの1つであることに違いありません。

なぜでしょうか。理由がいくつかありますが、まず非常に使いやすいからでしょう。誰もがウェブパフォーマンスの専門家ではありませんので、一般的なWordPressユーザーにとっては、Pingdom以外の代替ツールの多くは難しすぎます。彼らが言うように、時にはそれほど多くはありません。秘すれば花ですね。結局のところ、ポイントは2つあります:ウェブサイトのスピードと、さらにスピードアップできる方法です。

Pingdomウェブサイトスピードテスト

Pingdomウェブサイトスピードテスト

Pingdomを使用すると、どのウェブサイトに関しても、下記の7か所(5つの大陸)からウェブサイトの速度をテストできます。

  • アジア、日本、東京
  • ヨーロッパ、ドイツ、フランクフルト
  • ヨーロッパ、イギリス、ロンドン
  • 北アメリカ、米国、ワシントン
  • 北アメリカ、米国、サンフランシスコ
  • 太平洋、オーストラリア、シドニー
  • 南アメリカ、ブラジル、サンパウロ

注:当社のメンバーはテストヵ所の一分が利用可能でないときもあることがわかりました。おそらくメンテナンス中であるか、テストを行っている人が多くて過負荷になったためでしょう。使用したいテストヵ所が利用可能になっていないときに1〜2時間後に再確認してください。回復するはずです。

選択するテストヵ所は、ウェブサイトが実際にホストされている場所の物理的な場所に関係するため、非常に重要です。ネットワークレイテンシというものも関与しますが、これについては以下で詳しく説明します。

Pingdomスピードテストツールによる滝解析

ウェッブページといものは、HTML、JavaScript、CSS、イメージなど、さまざまなアセットで構成されています。それぞれは、ウェブサイトに表示されるものをレンダリングするリクエストを生成します。基本的にはリクエストが多いほど、ウェブサイトの読み込み速度が遅くなります。それは必ずしも当てはまるわけではありませんが、それはほとんどの場合本当です。

以下では、Pingdomの各セクションとあなたのウェブサイトの全体的な性能に関係する情報を詳しく分解し、滝解析のやり方を説明します。

Pingdomの概要

PingdomであなたのWordPressウェブサイトのスピードを計測すると、パフォーマンスグレード、合計読み込み時間、合計ページサイズ、およびあなたのウェブサイトにあるリクエストの数のデータが生成されます。本記事では、KinstaでホスティングされているEasy Digital Downloadsを使用した電子商取引サイトのperfmatters.ioを使用しています。

ご覧のとおり、最初のテストを実行すると、Pingdomで88/100点のスコアを出し、合計読み込み時間は541ミリ秒未満です。Pingdomによると当社のウェブサイトの読み込み時間は今までテストされたウェブサイトの92%以上より速かったことが分かったほか、アセットの合計サイズとリクエスト数のデータも出ました。

DNS前のPingdomスピードテスト

DNS前のPingdomスピードテスト

その後、追加のテストを実行した結果、合計読み込み時間は392ミリ秒でした! それはどういうことでしょうか? 🤔 Pingdomスピードテストツールを使用してウェブサイトを複数回計測したことのある方は同じことに気づいたかもしれません。サイトが多ければ多いほど差が大きいです。

理由は3つあります:DNSキャッシング、CDNキャッシング、およびWordPressキャッシング。これこそは、テストを複数回行う理由です。もちろん、サードパーティのリソースまたはAPIへの外部呼び出しも影響を与えることがあります。下記の滝解析にてさらなる理由を説明します。

DNS後のPingdomスピードテスト

DNS後のPingdomスピードテスト

あなたもWordPressウェブサイトのより良いPingdomスコアを取得したいですか? ウェブサイトとそのコンフィギュレーションによっては、満点の100/100点を取得するのは必ずしもできるわけではありませんが、それでもスコアを上げるのに少し時間を費やすだけで価値があるでしょう。本当に重要なのは総合的なスピードです。

また、ユーザーエクスペリエンスは、ウェブ上で読んだウェブパフォーマンスの工夫より大事である場合があります。 ユーザーエクスペリエンスを忘れてはいけません! しかし、上記のウェブサイトの実績の背景にある工夫をこれから教えますので、必ずお読みください。

When it comes to web performance optimization, you can't forget the user experience! 🚀 Click to Tweet

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

2018年に旧「パフォーマンスインサイト」を更新し、「ページのパフォーマンスを改善する」というの名前を付けました。重要性がなくなり、内容が変更したり削除された部分もあり、追加された部分もありました。Webパフォーマンスの最適化は変わりつつあるものです。Pingdomの満点だけを目指すのであれば、本当い疲れる作業です。

Pingdomパフォーマンスインサイト

Pingdomパフォーマンスインサイト

しかし、点数の出し方を把握することが重要であるため、本セクションの内容(古いものと新しいもの)をここに残します。基本的にGoogle PageSpeed Insightのルールに基づいている内容です。ウェブサイトでこれを改善すると、全体的な読み込み時間が改善するはずです。

「ページのパフォーマンスを改善する」には例えば以下があります:

さて、これらのうちのいくつかを確認しましょう。

コンテンツ配信ネットワーク(CDN)を使用する

WordPressウェブサイトで最も使用すべきなサービスの1つは、コンテンツ配信ネットワーク(CDN)です。CDNは世界中のサーバー(POPsとも呼ばれるもの)のネットワークです。画像、CSS、JavaScript、ビデオストリームなどのWordPressウェブサイトの静的な(時には動的な)コンテンツをホストし、配信するものです。

Kinstaのお客様であれば、当社のすべてのホスティングプランにCDNが付きます。数クリックで有効にすることができます。CDNのメリットは例えば、パフォーマンスの向上(TTFBとネットワークレイテンシの短縮)、バンドウィズとホスティングのコストの削減、SEOのメリットさえあります。

注:更新されたPingdomツールには現在、CDNプロバイダを正確に検出するバグがあります。

コンテンツ配信ネットワーク(CDN)を使用する

コンテンツ配信ネットワーク(CDN)を使用する

お勧めできるCDNプロバイダーは例えば:

当社のCDNスピードテストでは、CDNがページ読み込み時間を50%以上短縮する場合があることがわかりました!

HTTP 404(未検出)エラーを避ける

このセクションは以前「悪いリクエストを避ける」と呼ばれていました。これこそは常に重要です!この警告は名前通り、正常に完了できなかったリクエストのことです。削除されたアセットまたは画像に手動でリンクするときに404エラーが発生します。Pingdomでは応答ヘッダーのステータスの404とともにオレンジ色の点として表示されます。

Avoid bad requests - 404 error

悪いリクエストを避ける:404 エラー

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

リダイレクトの数を減らす

リダイレクトが多すぎることは決して気を付けないといけないことです。301リダイレクト、HTTPからHTTPSへのリダイレクト、またはwwwから非wwwへのリダイレクトはOKです。むしろ、必要であるときもあります。ただし、それぞれのリダイレクトがウェブサイトのパフォーマンスへの悪影響を与えます。リダイレクトを複数使用すると、ウェブサイトのパフォーマンスへの影響を把握したうえで使用するようにしましょう。ページおよび投稿のリダイレクト、イメージのリダイレクトなどすべてのリダイレクトはそうです。

リダイレクトは、Pingdomでは応答ヘッダーのステータスの301または302とともに青い点として表示されます。

Minimize redirects - 301

何件のリダイレクトはウェブサイトを影響するレベルでしょうか。少しのテストをしましょう。まず、https://perfmatters.io/contact/の問い合わせページでスピードテストを行います。以下に示すように、良い込み時間は417ミリ秒です。

リダイレクトのないウェブサイトのスピードテスト

リダイレクトのないウェブサイトのスピードテスト

その後、URLを少し変更し、別のスピードテストを行い、複数のリダイレクトの影響を確認します。http://www.perfmatters.io/contactご覧のとおり、同じページの読み込み時間は695ミリ秒もかかります。66%の増加です。あら!

リダイレクトが複数あるウェブサイトのスピードテスト

リダイレクトが複数あるウェブサイトのスピードテスト

WordPressのリダイレクトと、パフォーマンスのスピードアップためのベストプラクティスについての当社の記事も是非ご確認ください。

 

Expires ヘッダーを追加する

この提案は以前「ブラウザのキャッシュを活用せよ」と呼ばれました。分かりやすく言うと、WordPressウェブサイトのすべてのスクリプトに、HTTPキャッシュヘッダーが添付されているはずです。キャッシュヘッダーは、ファイルのキャッシュの期限が切れる時点を指定します。この問題を処理するには、WordPressホスティング会社のcache-controlヘッダーとexpiresヘッダーの設定が適切かを確認します。Kinstaは、これらのヘッダーをすべてのサーバー上に配置しています。サーバーにキャッシュヘッダーを手動で追加する手順を是非ご確認ください。

Leverage browser caching - caching headers

ブラウザのキャッシュを活用せよ – キャッシュヘッダ

もう1つの問題は、サードパーティ製のスクリプトを使用しているときに、Webサーバーを触れないため、キャッシュヘッダーを追加できないことです。よくある異常原因は例えば、Google AnalyticsのスクリプトとFacebook及びTwitterなどのマーケティングピクセルです。この問題を処理するには、Perfmattersなどのプラグインを使用することにより、Google Analyticsのスクリプトをローカルにホストすることができます。(これは正式にはサポートされていません。)WP Rocketにも、Facebookのマーケティングピクセルをローカルにホストするオプションが用意されています。

スクリプトのローカルへの移動のウェブサイトのパフォーマンスへの影響度がそれぞれです。メリットは、ファイルを完全に管理でき、自分のCDNから配信できることです。これにより、サードパーティのDNSリクエストもなくなります。一方、これらのファイルはすでに訪問者のブラウザにキャッシングされている可能性もあります。

「ブラウザのキャッシュを活用せよ」警告の処理方法についての詳細な記事も是非ご確認ください。

「クエリ文字列を削除せよ」

クエリ文字列異常もよくある課題です。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もあります。Kinsta CDNは、キャッシュできるし、デフォルトで行っている設定になっています。つまり、Kinstaのお客様なら、クエリ文字列は既にキャッシュされています。

「静的リソースからクエリ文字列を削除せよ」ウォーニング

「静的リソースからクエリ文字列を削除せよ」

ウォーニング当社の静的リソースからクエリ文字列を削除する方法についての詳細なチュートリアルも是非ご確認ください。

「クッキーレスドメインから静的コンテンツを配信せよ」

クッキーレスドメインから静的コンテンツを配信せよ」ウォーニングの処理については詳細の記事を発行しています。HTTP/2などのな新しいプロトコルのおかげでこれが重要性を失い、あなたも警告を無視することができます。一般的には、 同じコネクションを使ってすべてをストリーミングするより新しいコネクションを作るのが費用が高いです。 しかし、この問題を解決する2つの方法は、クッキーを削除するCDNプロバイダを使用すること、または別のドメインまたはサブドメインを作成することです。

「クッキーレスドメインから静的コンテンツを配信せよ」ウォーニング

「クッキーレスドメインから静的コンテンツを配信せよ」ウォーニング

「ホスト名間のダウンロードを並列せよ」

このウォーニングは、HTTP/1.1の限界またはウェブブラウザがあるホストに同時に接続できる回数に制限があるために発生します。 その制限は通常6つのコネクションです。多くのリクエストのあるウェブサイトにはよくある課題です。過去、この制限を回避する唯一の方法は、ドメインシャーディングと呼ばれる手段でした。ただし、HTTP/2をサポートするホスティング会社またはCDNプロバイダを使用している場合は、1つのコネクションで複数のリソースを並列にロードできる為、このウォーニングが無視できます。もちろん、ドメインシャーディングを実行することにより「ホスト名間のダウンロードを並列せよ」ウォーニングの処理方法についての当社のチュートリアルもご確認できます。

「ホスト名間のダウンロードを並列せよ」ウォーニング

「ホスト名間のダウンロードを並列せよ」ウォーニング

「キャッシュバリデータを指定せよ」

この警告は、キャッシュを検証してその長さ設定する為、すべてのオリジンサーバーレスポンスに含めるべきのHTTPキャッシュヘッダーがないときに出ます。ヘッダーが見つからない場合は、毎回リソースへの新しいリクエストが生成され、サーバーの負荷が増えます。これらのヘッダーは例えば、last-modifiedETagCache-Control及び Expiresです。「キャッシュバリデータを指定せよ」警告のと同様に、これらのヘッダーもWordPressホスティング会社により自動的に追加されるはずです。サードパーティのリクエストで発生する場合は、サーバー関係のサーバーの管理が全くない為、処理する方法ありません。

「キャッシュバリデータを指定せよ」ウォーニング

「キャッシュバリデータを指定せよ」ウォーニング当社の「キャッシュバリデータを指定せよ」警告の処理方法についての詳細な記事も是非ご確認ください。

「Vary: Accept-Encoding ヘッダーを設定せよ」

「Vary: Accept-Encoding ヘッダーを設定せよ」ウォーニングの処理方法については詳細な記事を発行しています。これはクライアントがコンテンツの圧縮されたバージョンを処理できるかどうかをブラウザに通知するため、すべてのオリジンサーバーのレスポンスに含める必要があるHTTPヘッダーです。

「Vary: Accept-Encoding ヘッダーを設定せよ」ウォーニング

「Vary: Accept-Encoding ヘッダーを設定せよ」ウォーニング

Pingdomのレスポンスコード

Pingdomスピードテストツールの次のセクションはレスポンスコードです。 HTTPステータスコードとも呼ばれるレスポンスコードは、ウェブページの先頭に追加されるウェブサーバーからの短いコメントのようなものです。 ページの表示リクエストが受信されたときの状態を知らせるウェブサーバーからのメッセージです。 例えば、次のようなものがあります:

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

    Pingdom 200のリスポンスコーヒーの例

    Pingdom 200のリスポンスコーヒーの例

  • 301: “The requested resource has been moved permanently.” (恒久的に移動した。)リクエストしたウェブページまたはリソースが恒久的に移動されているときに返されるコードです。 恒久URLリダイレクトのに使われているコードです。

    Example of Pingdom 301 response code

    Pingdom 301のリスポンスコーヒーの例

  • 404: “The requested resource was not found.” (未検出。)よく見かけるエラーメッセージです。リクエストされたリソースが存在しない、または存在するかどうかをサーバーが知らないときに返されるコードです。

    Pingdom 404のリスポンスコーヒーの例

    Pingdom 404のリスポンスコーヒーの例

HTTPステータスコードについての詳細な記事では、リスポンスコードの内容をさらに詳しく説明します。

コンテンツタイプ別のコンテンツサイズとリクエスト

次のセクションは、コンテンツタイプ別のコンテンツサイズとコンテンツタイプ別のリクエストです。両方は、あなたのウェブページのリソースを最も使っているものをすばやく確認するのに便利です。HTTP Archiveによれば、画像は通常のウェブページの合計サイズの43%を占めます。当社もこれはそうだと考えています。しかし、これから説明するとおり、いつもそうであるとは限りません。

Pingdomのコンテンツタイプ

Pingdomのコンテンツタイプ

画像を最適化するには、画像のウェブ用最適化についての当社の詳細な記事を是非お読みください。画像をさらに圧縮してあなたのウェブサイトのページの読み込みの大半を占めないようにする素晴らしいツール及びプラグインがいくつかあります。上記のケーススタディでは、perfmatters.ioが画像の代わりにFont Awesomeアイコンを利用しています。これは、大きな違いを生む素晴らしい戦略です。もちろん、コンテンツサイズをさらに小さくする方法については、ページスピードガイドにもいくつかの工夫を述べます。

ドメイン別のコンテンツサイズとリクエスト

ドメイン別のコンテンツサイズとリクエストは、ウェブサイト上の外部サービスとスクリプトがすばやく確認できます。当社のサンプルサイトでは、すべてのアセットがCDNから読み込まれています。 次に、ウェブサーバーからのウェブサイトの初期のHTML DOC読み込み、またはGoogle Analyticsドメインへの外部呼び出しがあります。 ウェブサイトによって、Facebook、Twitter、Hotjar、SumoMe、AdRoll、New Relic、CrazyEggなどの複数の外部サービスがある場合があります。

 

Pingdomドメイン別のリクエスト

Pingdomドメイン別のリクエスト

基本的には、外部サービスは独自の待ち時間、TLSハンドシェイク待ち時間、DNSルックアップなどを導入する為、外部リクエストが少ない方がいいです。WordPressウェブサイトの外部サービスを特定して分析する方法についての詳細な記事を必ずご確認ください。

原則としては、できるだけリクエストの数を減らし、アセットをウェブサーバーまたはCDNに移動するより、1か所でホスティングするのが最善です。例えばFont Awesomeはその一つの例です。Font Awesomeの外部スクリプトにリンクするのではなく、ダウンロードして直接提供した方がよいでしょう。

When evaluating web performance it's important to decide which files you should and shouldn't host. ⚡ Click to Tweet

Pingdomの滝チャート

最後に、Pingdomスピードテストツールのウェブページ上の個々のリクエストのすべての滝チャートを生成するリクエストセクションがあります(下記参照)。これで各リクエストを分析し、ウェブサイトの待ち時間増加または性能問題を起こす原因を調べることができます。滝解析を行うというときには、ここの話です。以下は、それぞれのステータスカラーの意味のより詳細な定義です。

Pingdomの滝分析

Pingdomの滝分析

DNS (ピンク色)

では、DNSとは何でしょうか? 電話帳のようにものと考えればよいでしょう。あなたのウェブサイトに関する情報とどのIPアドレスにルーティングすべきであるかという情報を含むドメイン名サーバと呼ばれるサーバがあります。 Pingdomを使って最初にあなたのウェブサイトを計測するとき、Pingdomが新しいルックアップを実行し、IP情報を受け取るためにDNSレコードの問い合わせを行わなければなりません。その結果、追加のルックアップ時間がかかります。

PingdomにてのDNS待ち時間

PingdomにてのDNS待ち時間

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

以下の画面でわかるように、2回目のテストでは、最初のDOC読み込みでのDNSルックアップ時間は3.6ミリ秒です。リクエストはすでにキャッシュされているため、0ミリ秒まで低下することもよくあります。これは多くの方が誤解してしまうポイントです!

PingdomにてのキャッシングされたDNS

PingdomにてのキャッシングされたDNS

また、プレミアムDNSサービスを使用することによりさらに最適化することができます。もちろん、その他にも多くのメリットがあります。Cloudflareの無料DNSも高速です!

ダウンタイムまたはWordPressの異常に悩んでいますか。Kinstaは時間を節約するために設計されたホスティングソリューションです!当社のフィーチャーをご確認ください。

複数のテストの後にウェブサイトがより速くなったように見える理由は他にもあります。それらの一つは、コンテンツ配信ネットワーク(CDN)の使用です。 CDNをご存じのない方への説明ですが、CDNとは訪問者に近い場所にあるサーバーを使用してコンテンツ(JS、CSS、画像など)をキャッシングするグローバルのサーバーネットワークです。初めてPingdomでウェブサイトを計測するとき、アセットを直接CDNから読み込む必要があります。 CDNキャッシュはDNSと同様に、一度キャッシングされると、連続して読み込めばはるかに高速になります。

DNSのスピードアップができるもう一つの手段は、DNSプリフェッチを行うことです。これにより、ブラウザはバックグラウンドでページのDNSルックアップを実行できます。WordPressウェブサイトのヘッダーのコードに数行を追加するだけでDNSプリフェッチができます。以下の例を参照してください。

<!-- 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以降のバージョンをご利用の場合は、Resource Hintsを使用することもできます。開発者は、wp_resource_hintsフィルタを使用して、カスタムドメイン、またはdns-prefetchpreconnectprefetch及びprerenderのURLを追加できます。

SSL (紫色)

紫色のステータスカラーは、ブラウザがSSL/TLSハンドシェイクを実行するのにかかる時間を示します。HTTPSを使用してウェブサイトを実行する度に、SSL証明書が含まれており暗号化プロセス(SSL/TLSハンドシェイク)に余分な時間がかかります。当社のサンプルドメインは、Kinstaのウェブサーバーと当社のCDNのKeyCDNの両方に証明書があります。したがって、ウェブサーバーと当社のアセットの両方からの最初のHTML DOC読み込みにSSLネゴシエーション時間があります。

PingdomにてのSSL読み込み時間

PingdomにてのSSL読み込み時間

HTTPSの実行には若干のデメリットがありますが、HTTP/2のおかげでは本当に少なくなっています。HTTP/2はウェブ自体のスピードアップをしてくれる新しいプロトコルです! ブラウザのサポートのためには、HTTPSはHTTP/2を利用する必要があります。当社のHTTP/2の完成ガイドをご覧ください。

HTTP/2をまだサポートしていないプロバイダーもありますので、ご了承ください。ウェブホスティング側とCDN側の両方がそうです。ホスティング会社あるいはCDNをお探しのあなたも、必ずHTTP/2サポートを確認してください。Kinstaは、WordPressをご利用のお客様のすべてを対象にHTTP/2をサポートすることを誇りに思っています。

現在Pingdomツール自体がテストを実行するためにChrome 60を使用している為、HTTP/2をサポートしていないことにご注意ください。ChromeはHTTP/2をバージョン49以降しかサポートしていません。PingdomがHTTP/2の利点を完全に示していない為、ウェブサイトの実際のパフォーマンスがより優れている可能性もあります。もちろん、Pingdomがテストマシンをアップグレードするまでだけですね。

2018年には、PingdomはやっとChrome 60以上を使用するようにツールをアップグレードしました。リクエストヘッダーで使用されているuser-agentが表示されるようになりました。以前はChrome 39を使用していましたが、Chromeでは49までにはHTTP/2がサポートされませんでした。今回は、Pingdomツールでテストを行うときにHTTP/2のすべてのメリットが表示されるようになりました。👏

Pingdom HTTP/2 support

PingdomのHTTP/2サポート

接続(青い色)

Pingdomの接続時間は、TCP接続、またはTCP接続の作成に必要な合計時間のことです。この動作を理解する必要はおそらくありませんが、単にホスト/クライアントとサーバーの間の実行してはいけない通信方法です。

pingdom connect time

待ち時間(黄色)

Pingdomの待ち時間は、他のツールではTTFBとも呼ばれる最初のバイトを受け取るまでの時間のことです。TTFBは、ウェブサーバーまたはその他のネットワークリソースの応答性を測る単位です。基本的には、100ms未満の結果は喜ばしい結果で、良いTTFBです。 300〜400 msの範囲に近づいている場合は、サーバー上のコンフィギュレーションが間違っているか、そろそろより良いウェブスタックにアップグレードする必要がある可能性があります。

ttfb

TTFBを減らす最も簡単な方法はなんでしょうか。最も効率のいい方法は効果的なWordPressキャッシングとCDNです。では、テストを実行しましょう。

WordPressホストキャッシュなしのTTFB

最初に、WordPressウェブサイトのキャッシュをクリアした上でテストを行いました。つまり、キャッシュを再度プリロードしました。合計読み込み時間は541ミリ秒であり、最初のリクエストのTTFB(待ち時間)は185.2ミリ秒でした。

Pingdom TTFB before WordPress cache

WordPressキャッシュなしでのPingdomのFFTB

WordPressホストキャッシュ付きのTTFB

次に、テストを再実行しました。直接キャッシュから配信しています。合計読み込み時間は392ミリ秒にまで減少し、最初のリクエストのTTFBは今や52.8ミリ秒です! やはりキャッシングのパワーですね。

Pingdom TTFB with WordPress cache

WordPressキャッシュ付きでのPingdomのFFTB

全国または世界中の訪問者のいるウェブサイトなら、TTFBを大幅に改善するもう1つの簡単な方法はCDNを使用することです。その影響度をお見せするには再びテストを行いました。

CDNなしのTTFB

まず、CDNを無効にしてテストを行いました。ご覧のように、合計読み込み時間は1.93秒で、アセットの平均TTFBは約176ミリ秒でした。

CDN前のTTBF

CDN前のTTBF

CDN付きのTTFB

次に、CDNを有効にしてテストを再実行しました。ご覧のとおり、合計読み込み時間は1.21秒に下がり、CDNアセットの平均TTFBは今や4.6ミリ秒です!CDNこそ違いを生み出しますね。

CDN後のTTFB

CDN後のTTFB

それに、テストを実行するのに場所を「太平洋、オーストラリア、シドニー」にしたことも非常に重要なポイントです。なぜでしょうか。それはもちろん、結果がどれぐらい改善したかを示したいと思っていたからです。本サンプルWordPressウェブサイトは、Google Cloudを使用するKinstaにホスティングされ、米国の中部に位置しています。オーストラリアをベースにテストを実行することで、CDNキャッシングの速度向上とTTFB削減の結果を示すことができました。

そしてもちろん、慎重に考え出されたアーキテクチャを備えた優れたWordPressホスティング会社を持つことも、TTFBを引き下げるのに重要です。

送信(オレンジ色)と受信(緑色)

Pingdomの送信と受信ステータスは、おそらく説明が必要ありません。送信時間は、ウェブブラウザがサーバにデータを送信するのにかかる時間です。受信時間は、ウェブブラウザがサーバからデータを受信するのにかかる時間です。両方は非常に低いか、0であるはずです。

HTTP応答ヘッダー

滝解析中に個々のリクエストをクリックし、HTTP応答ヘッダーを確認することもできます。これは貴重な情報です。以下の画面では、例えばgzipがウェブサーバー上で有効になっていること、HHVMが使用されていること、キャッシュから提供されていること(HITそうでない場合はMISSを表示する)、キャッシュ制御ヘッダー、 ブラウザのユーザーエージェントなどが確認できます。

http response headers

ケーススタディのドメイン設定

それでは、本記事をここまで読んでくれた方にはプレゼントをお渡ししたいと考えています。工夫やケーススタディを教えてくれるが、その背景を教えてくれない人が最悪ですね。したがって、上記のケーススタディドメインのコンフィギュレーションをそのまま教えます。ご遠慮なくお使いください。

アーキテクチャ

  • 本ケーススタディドメインはGoogle Cloud Platformを使用するKinstaにホスティングされ、米国のアイオワ州のカウンシルブラフス(us-central1)に位置しています。Kinstaはで現在、20ヵ所のデータセンターからご選択いただけます。高速ネットワークレイテンシのためにGCPの「プレミアムティア」ネットワークは、すべてのプランに付きます。
  • Kinstaは高速な読み込み時間に貢献するHTTP/2、NginxMariaDBを使用しています。
  • 本ウェブサイトはKinsta CDNの機能を強化するKeyCDNを使用しています。 無料のCDNバンドウィズはすべてのホスティングプランに含まれています。
  • 本ウェブサイトはキャッシングプラグインを使用していません。Kinstaはサーバーレベルでキャッシングをしますので、使用しやすいです!
  • 本ウェブサイトはPHP 7.3を使用しています。PHPの新しいバージョンを使用するとパフォーマンスが大幅に向上します。こちらのPHPベンチマークをご確認ください。Kinstaでは、ボタンを押すだけでPHPのバージョン間の切り替えができます。

 

WordPressウェブサイトのPHPバージョンを更新する

 

WordPressのプラグインとテーマ

次に、WordPressの電子商取引サイトで使用されるとパフォーマンスに影響を与えるプラグインの一覧を示します。

  • Kinstaのチームメンバーの一人により開発されたプレミアムPerfmattersプラグインは、埋め込み、絵文字などの不要なHTTPリクエストを取り除き、特定のスクリプトがページ、投稿、またはサイト全体に読み込まれることを設定できるスクリプトマネージャも用意されています。
  • プレミアムImagifyプラグインは、画像を圧縮するのに便利です。
  • 無料のSafe SVGプラグインは、SVG画像をWordPressサイトにアップロードするのに便利です。
  • プレミアムのWordPressテーマであるGeneratePressは、EDDサイトを構築するのに使用されました。

 

お勧めのチュートリアル:

まとめ

ご覧のとおり、Pingdomスピードテストツールの考え方またそのグラフの意味の理解は、パフォーマンス面でのデータをベースにした決定をするのに役立ちます。滝分析は、個々のアセットの読み込み状況、WordPressホスティング会社の影響、物理的なロケーション、CDNなどを知るのに重要な手段です。あなたもその他のPingdomのいい工夫をご存じですか。

上記のような詳細な記事をお読みになりたい方は、是非コメントを残し教えてください。

15
シェア