サイト速度テストツールGTmetrixの使い方を徹底解説

サイトのパフォーマンスをチェックできる速度テストツールは数多く存在します。以前の記事では、Pingdomについて詳しくご紹介しました。今回は、人気のサイト速度テストツールGTmetrixを最大限に活用し、データを理解する方法を深掘りします。これらのツールでは、スコアを用いた評価が表示され、サイトの異常を把握することができます。しかし、その表示は時に非常に分かりづらいことも。その意味を正しく理解することによって、単にサイトのスコアを上げるだけではなく、最も重要である、サイトのパフォーマンスを改善することができます。

GTmetrixはカナダに本社を置くGT.netという企業によって、自社顧客サイトのパフォーマンスを判定するためのツールとして開発されました。Pingdomとともに、おそらく現在最も有名な速度テストツールの一つでしょう。今回こちらのウェブサービスをご紹介することにしたのは、Kinstaのお客様から「GTmetrixのレポートで提示されたアドバイスに具体的にどのようにして従うべきか」というお問い合わせを頂くためです。他の開発者向けツールと比べるとGTmetrixはとても使いやすく、初心者でも簡単に活用できます。スコアと推奨事項の生成には、GoogleのPageSpeed Insights、そしてYSlowが組み合わせて使用されています。

GTmetrixの分析機能

GTmetrixの必要最低限のバージョンは完全無料で、アカウントに登録するだけで様々な機能を利用できます。有料プランも存在しますが、今回の記事では無料版を使用してご説明します。アカウントに登録すると、より詳しい設定が利用できます。

追加で利用できる設定の一つ目はサイトのテストを実施するロケーションの選択です。テストの実施場所はサイトがホストされているサーバーとの関係上、大変重要です。レイテンシが低いほど読み込み時間は速くなります。現段階では、次のロケーションから選択できます。

ダラス（アメリカ）
香港（中国）
ロンドン（イギリス）
ムンバイ（インド）
シドニー（オーストラリア）
サンパウロ（ブラジル）
バンクーバー（カナダ）

使用するブラウザはChrome（デスクトップ）、Firefox（デスクトップ）のいずれかを選べます。モバイル版は有料プランでのみ利用可能です。また、接続速度も変更できるため、あらゆる接続環境でページの読み込み速度がどのように変化するかをシミュレーションすることができます。

追加機能の二つ目が、動画作成です。ページがどのようにレンダリングされるかを記録できるため、問題のデバッグに役立ちます。AdBlock Plusも便利な機能です。Google Adsenseなどのサードパーティ広告ネットワークを利用している場合、この機能を有効化し広告がページの読み込み時間に及ぼす影響を確認できます。こちらはSmashing Magazineのわかりやすい比較レポートです。広告が表示されるページで2.3秒読み込みが遅くなる、というのは当然の結果でしょう。

その他の機能には「onload」（後ほど解説）に際しテストを中断、リクエストとともにクッキーを送信、HTTP認証の使用、URLのホワイトリスト化／ブロック、ディスプレイ解像度とデバイスピクセル比、ユーザーエージェントの書き換えなどがあります。

速度テストツールGTmetrixでサイトを分析する

ウェブページはHTML、JavaScript、CSS、画像など様々なアセットを使用して作られます。これら一つ一つが、サイトに表示するものをレンダリングするためにリクエストを生成。通常、リクエストが多いほどサイトの読み込みは遅くなります。必ずしもそうだとは言えませんが、多くの場合そうなります。

ここからは、GTmetrixの各項目を詳しくご紹介しながら、それぞれが示す情報の意味を解説していきましょう。サイトの総合的なパフォーマンスについてどのように対応すべきか、有用なヒントが得られます。大事な点として、スコアの改善にばかり固執するのではなく、実際にサイトの速度を改善することに重きをおくようにしましょう。

GTmetrixの概要（パフォーマンススコアと詳細）

GTmetrixでWordPressサイトのテストを実施すると、「GTmetrix Grade」、「Web Vitals」という項目を含むレポートが生成されます。

GTmetrix Gradeは「Performance」と「Structure」という二つの指標によって算出されます。

GTmetrix Performanceはサイト監査ツールLighthouseによるパフォーマンスのスコアです。
GTmetrix Structureはページの総合的なパフォーマンスを測定する独自のパフォーマンス指標です。

2020年にGoogleはWeb Vitals（ウェブバイタル）というウェブパフォーマンスとユーザーエクスペリエンスを標準化した指標を導入しました。Web Vitalsは様々な指標で構成されますが、GTmetrixでは「Largest Contentful Paint（LCP）」、「Total Blocking Time（TBT）」、「Cumulative Layout Shift（CLS）」の3つを採用しています。

Largest Contentful Paint（LCP）：ページの最も大きな要素が読み込まれるのにかかる時間を意味します。LCPはサイトのキービジュアルの読み込み時間であることもあれば、サイト本文の読み込み時間であることもあります。
Total Blocking Time（TBT）：ユーザーがサイトを操作できるようになるまでにサイトがブロックされている時間です。レンダリングを妨げるCSSやJavaScriptはTBTに大きな影響を及ぼすことがあります。
Cumulative Layout Shift（CLS）：ページが読み込まれる間に起きる要素のズレです。例えば、ツイートが埋め込まれたページのレイアウトではページ読み込み時に大きなズレが発生することがあります。

ここでは、Kinstaでホストしているケーススタディ用のドメインである「kinstalife.com」を使用した例をご紹介します。最初の速度テストでは、次の通りの結果となりました。

GTmetrix Grade – B
GTmetrix Performance – 85%
GTmetrix Structure – 83%
LCP – 1.0s
TBT – 0ms
CLS – 0

その後、二度目のテストを実施したところ、GTmetrix Gradeは「A」に変わりました。これは一体なぜでしょうか？GTmetrixの速度テストを複数回実施すると、このような事象が発生することがあります。その原因の一つはキャッシュです（DNSキャッシュとサーバーキャッシュの両方）。その詳しい理由は、後ほどご紹介する滝グラフの項目をご覧ください。

GTmetrixの「Summary」の画面では、ページの読み込み中に起きる主要な出来事を時系列で示した「Speed Visualization（スピードの可視化）」という項目も表示されます。次のスクリーンショットでは、kinstalife.comの「TTFB（サーバー初期応答時間）」、「FCP」、「LCP」、「onload time（ページの読み込み処理が完了した時間）」、「time to interactive（ページが操作可能になるまでの時間）」、「fully loaded time（読み込むファイルがなくなった時間）」が表示されています。

Summary」画面下部には、「Top Issues（主要な問題点）」と「Page Details（ページ詳細）」という項目があります。「Top Issues」には、優先度の高い改善すべき問題点が表示され、「Page Details」にはページのファイルサイズの内訳と割合が表示されます。

Performance

次はGTmetrixの「Performance」タブです。こちらにはLighthouseから引用した数々の便利なパフォーマンスデータ指標が表示されます。概要画面に表示される「LCP」、「TBT」、「CLS」に加え、「Performance Metrics」の項目には「Speed Index（SI）」、「Time to Interactive（TTI）」、「First Contentful Paint（FCP）」という指標が表示されます。

「Performance Metrics」の項目では、改善すべき問題点が具体的に示されるわけではありませんが、改善すべきユーザーエクスペリエンスに関する大まかな情報を把握するにはとても便利です。

さらに画面を下にスクロールすると、「Onload Time」、「TTFB（サーバー初期応答時間）」、「Fully Loaded Time」など、「Browser Timing（ブラウザ読み込み時間）」の統計が確認できます。かつてはこれらの指標が大変重要でしたが、Googleが「Web Vitals」という新たな指標を定めた今は、こちらの指標を優先的に最適化することをお勧めします。多くの場合、「Web Vitals」を最適化することで、ブラウザ読み込み時間も改善されるでしょう。

Structure

GTmetrixの「Structure」タブでは、サイトのパフォーマンスに影響を及ぼす具体的な問題を確認できます。ここでは「レンダリングを阻害するリソースを削除する」、「CSSを圧縮する」など、具体的な推奨事項が記載されるので非常に有益です。

以下では、WordPressサイト管理者が直面する最も一般的な問題をできるだけ網羅したいと思います。こちらの項目は定期的に更新する予定ですので、是非ともブックマークをどうぞ。通常、これらの項目を改善するだけでパフォーマンスの改善が見られます。

「serve scaled images（サイズの合致した画像を配置する）」

サイトに使用する画像のサイズは必ず調整しておきましょう。CSSによってリサイズされないようにすることが重要です。そうでないと、「serve scaled images（サイズの合致した画像を配置する）」という警告が表示されるはずです。WordPressを利用している場合、画像をメディアライブラリにアップロードするとデフォルトでリサイズされます。この設定は、「設定」＞「メディア」から変更できます。画像の幅の上限がサイトの画面の幅に近い値になるように設定しましょう。そうすることで、サイトの幅に合うようにCSSによってリサイズしようとするのを防ぐことができます。もしくは、画像最適化プラグインで自動的にリサイズすることも可能です。

「Inline Small CSS（CSSの小さなコードをインライン化する）」

CSSのインライン化はページリクエストの合計ダウンロードサイズを増加させるため、通常は推奨されません。しかし、リクエスト数の少ない小規模なサイトの場合、パフォーマンスを改善できることがあります。

手軽にCSSをインライン化するにはAutoptimizeなどの無料プラグインを利用するのがおすすめです。その際には「すべてのCSSをインライン化」にチェックを入れ、一方でインライン化しないCSSファイルを除外するようにしてください。

「Inline Small JavaScript（JavaScriptの小さなコードをインライン化する）」

CSSの簡単なコードをインライン化したのと同様にJavaScriptの小さなコードもインライン化することができます。ページリクエストの合計ダウンロードサイズを増加させるため、通常は推奨されませんが、リクエスト数の少ない小規模なサイトの場合、パフォーマンスを改善できることがあります。この場合もAutoptimizeでJavaScriptの設定を変更するだけでOKです。

「Leverage Browser Caching（ブラウザキャッシュを有効化する）」

「Leverage browser caching（ブラウザキャッシュを有効化する）」というメッセージも表示されがちです。こちらは、ウェブサーバーのキャッシュを管理するHTTPヘッダーが正しく設定されていない時に表示されます。「leverage browser caching」という警告を修正する方法も合わせてご覧ください。しかし、外部サービスの広告ネットワークでこの警告が表示されている場合は、どうすることもできません。

「Serve Resources From a Consistent URL（一貫したURLからリソースを配信する）」

「serve resources from a consistent URL（一貫したURLからリソースを配信する）」という警告が表示される場合、同じURLから同一のリソースが配信されている可能性が考えられます。多くの場合、クエリ文字列が関連しているケースで発生します。静的リソースからクエリ文字列を削除する方法という記事をご覧ください。削除すると、重複して読み込むことはなくなります。

「Defer Parsing of JavaScript（JavaScriptの読み込みのタイミングをずらす）」

JavaScriptとCSSはもともとレンダリングを阻害する性質を持ちます。つまり、ダウンロードの上ブラウザで処理されるまでの間、ウェブページ表示を妨げます。そこでdefer属性です─ブラウザに対してHTMLが完全に読み込まれるまでリソースのダウンロードを保留するよう指示します。この警告を手軽に解消するには無料のAutoptimizeを使うか、Async JavaScriptプラグインを利用できます。レンダリングを阻害するJavaScriptとCSSを削除する方法に関する記事もご覧ください。

詳しい手順を知りたい方はWordPressでJavascriptの読み込みをずらす警告を解消する方法（4つの手法）をお読みください。

「Minify CSS and JavaScript（CSSとJavaScriptを圧縮する）」

圧縮とは基本的に、機能を変えずにすべての不要な文字列をソースコードから削除することを意味します。例えば改行、余白、インデントなどがそれに当たります。そうすることで、データのバイト数を削減し、ダウンロード、読み込み、実行の時間を短縮できます。

ここでも無料のAutoptimizeプラグインが大変便利です。「JavaScriptコードの最適化」と「CSSコードの最適化」の両方にチェックを入れるだけでOKです。大規模なサイトの場合、これらの設定がサイトのパフォーマンスに悪影響を与えることがあるため、下の方にある詳細設定も利用しましょう。大規模なサイトではCSSとJavaScriptのインライン化と連結は通常推奨されません。そんな時に役立つのがHTTP/2です。

「Optimize Images（画像を最適化する）」

HTTP Archiveによると、2017年4月の時点で、画像は平均でウェブページ全体の66%を占めるということです。そのため、WordPressサイトの最適化を行う際、まず着手すべきは画像の最適化でしょう。スクリプトやフォントよりも高い優先度で対処することをお勧めします。

理想はすべての画像がWordPressへのアップロード前に圧縮、最適化されていること─しかし実際、現実的な話ではありません。そのため、優れた画像最適化プラグインの使用をお勧めします。そうすることで、画像を自動的に圧縮、リサイズでき、素早い読み込みを後押しできます。ウェブ用の画像を最適化する方法に関する記事もご確認ください。

「Reduce Initial Server Response Time（サーバー初期応答時間を短縮する）」

WordPressにおいて、サーバー初期応答時間が遅い主な原因は「ページキャッシュの設定がされていないこと」です。ページキャッシュを設定していないと、WordPressではリクエストの度にPHPを用いて動的にページを構築します。そのため、短時間に連続してリクエストがあった場合、手に負えなくなってしまいます。ページキャッシュがあれば、サイトは既に生成されたHTMLファイルを配信することができます。これは、各々のページのリクエストにPHPを用いて応答するよりも大幅に迅速で、スケーラブルです。

Kinstaをご利用のお客様の場合、ページキャッシュについて心配する必要はありません。お客様に代わり、当社にてNginxの設定で対応しています。ご利用中のWordPressレンタルサーバーがページキャッシュに対応していない場合、WP RocketやW3 Total Cacheなどのキャッシュ系プラグインをインストールしておきましょう。サーバー初期応答時間をさらに短縮したい場合は、WordPressサイトにCloudflareのAPO（自動プラットフォーム最適化）サービスを連携することをお勧めします。Cloudflareの提供するこの革新的なサービスは、ユーザーサイトのHTMLページを世界各地に予め配信し、どこからのアクセスであってもサーバー初期応答時間を短縮します。

「Minify HTML（HTMLを圧縮する）」

CSSやJavaScriptと同様にHTMLも圧縮可能です。これにより、不必要な文字列を削除し、データのバイト数を削減し、実行時間を短縮できます。

ここでも無料のAutoptimizeプラグインが便利です。「HTMLコードを最適化」にチェックを入れましょう。

「Enable GZIP Compression（gzip圧縮を有効化する）」

gzipとはファイルの圧縮と解凍に使用されるファイル形式とそのプログラムのこと。gzip圧縮はサーバーサイドで有効化され、HTML、CSS、JavaScriptファイルサイズの更なる削減が可能です。画像への適用は不要です（既に圧縮されているため）。gzip圧縮により、最大70%のサイズ削減に成功した例もあります。

これはWordPress最適化を行う際、最も手軽な方法の一つでしょう。なお、Kinstaのサーバーではgzip圧縮がデフォルトで適用されています。

Apacheでgzip圧縮を有効化するには.htaccessファイルに次のコードを追加します。

<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>

NGINXをご利用の場合、nginx.confファイルに次のコードを追加します。

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_vary on;
gzip_types text/plain text/css text/javascript image/svg+xml image/x-icon application/javascript application/x-javascript;

gzip圧縮を有効化する方法についての記事も合わせてお読みください。

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

特定のURLから別のURLへのHTTPリダイレクトを最小限に抑えることでもRTT（ラウンドトリップタイム）と待機時間を短縮できます。これについてはWordPressのリダイレクトに関する記事をお読みください─こちらでは、たった2件の不適切なリダイレクトによりサイトの読み込み時間がなんと58%も長くなっていた事例をご紹介しています。WordPressのリダイレクトは基本的にサイトの遅延を招きます。そのためリダイレクトによるサイトへの訪問数を最小限に抑えることが重要です。

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

「specify a cache validator（キャッシュのバリデータを設定する）」という警告はキャッシュを管理するHTTPヘッダーが指定されていないときに表示されます。このHTTPヘッダーはキャッシュ時間の設定と検証の両方を行うため、すべてのオリジンサーバーのレスポンスに必要です。このヘッダーが設定されていない場合、リソースを取得するために毎回新しいリクエストを生成するため、サーバーの負荷が増加します。これを設定することで、連続したリクエストが都度サーバーから読み込まれるのを防ぎ、帯域幅を節約し、パフォーマンスを改善することができます。ちなみに、この警告が「管理外にあるリソース」に関するものである場合には、修正できません。

この警告の解決には様々な種類のキャッシュ管理を担うHTTPヘッダーが関係しています。詳しくはキャッシュのバリデータを設定する方法をご覧ください。

「Specify Image Dimensions（画像の寸法を設定する）」

画像がCSSによってリサイズされないようにすべき、という要点は既にご説明しましたが、画像の寸法も指定すべきです。つまり、HTMLコードに幅と高さを含めるようにしましょう。

悪い例

<img src="https://domain.com/images/image1.png">

良い例

<img src="https://domain.com/images/image1.png" width="200" height="100">

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

CSSとJavaScriptファイルでは通常、URL末尾にファイルのバージョンが記載されます（domain.com/style.css?ver=4.6など）。サーバーやプロキシサーバーの中には、cache-control:publicヘッダーが設定されていたとしてもクエリ文字列をキャッシュできないものも。そこで、クエリ文字列を削除することでキャッシュ動作を改善できることがあります。コードを修正するか無料のWordPressプラグインを使用することで簡単に削除できます。

詳細は静的リソースからクエリ文字列を削除する方法をご覧ください。なお、「管理外にあるリソース」については、修正できませんのでご注意ください。

「Remove query strings from static resources」

「Specify a Vary: Accept-Encoding Header（Vary: Accept-Encodingヘッダーを設定する）」

こちらは、すべてのオリジンサーバーのレスポンスで設定されていなければならないHTTPヘッダーです。クライアントがコンテンツの圧縮されたバージョンを扱えるかどうかをブラウザに伝える役割を果たします。通常、gzip圧縮の有効化により、この警告は消えるはずです。詳しくは、specify a vary: accept-encoding headerについての記事をご確認ください。なお、こちらもまたサードパーティのリソースでは修正できませんので悪しからず。

GTmetrixの滝グラフ

GTmetrixの滝グラフにはウェブページ上のすべての個別のリクエストが表示されます（下記参照）。それぞれのリクエストを分析し、何がサイト上の読み込みの遅れやパフォーマンスの問題を引き起こしているのかを確認できます。ここからはその詳しい解説と、各リクエストの色分けがそれぞれ、どのような意味なのかをご説明します。

Blocking（茶色）

ブラウザがウェブページを読み込む時、JavaScriptとCSSがダウンロードされ、ブラウザに処理されるまでの間、ウェブページの表示を妨げます。GTmetrixの滝グラフではこの遅れが「blocking」という項目で表示されます。詳細はJavaScriptとCSSがレンダリングを阻害するのを防止する方法をご確認ください。

DNS Lookup（青緑）

DNSルックアップとは電話帳を利用した探し物のようなものです。ネームサーバーと呼ばれるサーバーが存在し、そこに、あなたのサイトの情報、そして、それがどのIPにルーティングされるべきかという指示が保存されています。GTmetrixで初回のテストを実施する時、初めてのルックアップであるため、IP情報取得のためにDNSレコードにクエリが実行されます。そのため、ルックアップにかかる時間は少し長くなります。

gtmetrix first dns

GTmetrixで二度目のテストを実施すると、IP情報は既にわかっているため再度ルックアップを行う必要はなくなります。これが、GTmetrixで複数回テストを実施すると、「計測結果」が向上する理由の一つです。次のスクリーンショットから分かるように、二度目のテストではDNSルックアップにかかった時間は0msでした。これは多くの方の誤解を招きやすい部分です。複数回テストし、平均値を確認することをお勧めします。ただし、DNSルックアップにかかる時間を確認したい場合は、初回のテスト結果を参照しましょう。

CDNを利用している場合のアセット（JavaScript、CSS、画像）にも同じことが言えます。CDNキャッシュはDNSと同じような働きをします。一度キャッシュされると、それ以降の読み込み時間が大幅に短縮されます。また、DNSプリフェッチを利用することでもDNSを高速できます。これによりブラウザが特定のページのDNSルックアップをバックグランドで実行するようにできます。実装については、WordPressサイトのヘッダーに数行コードを追加するだけで完了します。次の例をご覧ください。

<!-- 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-prefetch、preconnect、prefetch、 prerenderの独自ドメインとURLを追加することができます。

Connecting（緑）

GTmetrixにおける「connecting」はTCPコネクション、もしくはそれの確立に要する合計時間を意味します。仕組みを詳しく理解する必要はありませんが、ホスト／クライアントとサーバー間で確立しなければならないやり取りであるということを覚えておきましょう。

Sending（赤）

「sending」はウェブブラウザがサーバーにデータを送信するのにかかった時間です。

Waiting（紫）

GTmetrixの「wait time」は他のツールでサーバー初期応答時間（TTFB）と呼ばれるものに当たります。TTFBはウェブサーバーやその他のネットワークリソースの応答性を示す指標です。一般的に、TTFBが100ms以下であれば許容範囲と見なされます。300-400 msに近づくと、サーバーの設定に問題があるか、より優れたソフトウェアにアップグレードしなければならないでしょう。Kinstaのテストでは、以下のとおりほぼ100ms以下でしたので、優れた数字だと言えます。

TTFBを手軽に低減する方法の一つは、適切なキャッシュの設定がされ、CDNを利用したレンタルサーバーを利用することです。WordPressサイトでTTFBを短縮する方法もご覧ください。

Receiving （灰色）

「receiving」はウェブブラウザがサーバーからデータを受信するのにかかった時間を示します。

Event Timings（イベント発生のタイミング）

ページをリクエストする度に、データがレンダリングされ、読み込まれる過程の一連のイベントが発生します。

First Paint（緑の線）：ブラウザがページの各種レンダリングを開始した時点（背景の色を表示するなど）
DOM Loaded（青い線）：ドキュメントオブジェクトモデル（DOM）の準備が整った時点
Onload（赤い線）：ページの処理が完了し、ページの全てのリソース（画像、CSSなど）のダウンロードが完了した時点
Fully Loaded（紫の線）：「onload」の後、ネットワークアクティビティが2秒間実施されなかった時点

HTTP Response Headers（HTTPレスポンスヘッダー）

個別のリクエストをクリックすると「HTTP response headers」から大変有益な情報が得られます。次のスクリーンショットでは、ウェブサーバーでgzipが有効化されていること、HHVMを使用して動作していること、キャッシュから配信されていること（HITという表示─キャッシュから配信されていない場合MISSと表示される）、cache-controlヘッダー、サーバーアーキテクチャ（こちらは確認できないこともしばしば）、expiresヘッダー、ブラウザのユーザーエージェントなど、様々な情報が確認できます。

もう一つ覚えておくべきこととして、Pingdomとは違い、GTmetrixはHTTP/2に対応しています。これはGTmetrixがテストの実行にChrome 58以降のバージョンを利用しているためです。Chromeではバージョン49でHTTP/2のサポートが追加されました。そのため、速度テストのツールを選ぶ際にはこの点を考慮しましょう。

Video（動画）

最新版のGTmetrixには、表示の異常やフロントエンドのパフォーマンス関連の問題をデバッグするのに便利な「Video」タブがあります。動画機能が有効化されていると、パフォーマンステスト毎にどのようにページが読み込まれるかを記録した、埋め込み可能な動画が生成されます。この機能は特定のブラウザとスクリーンサイズの組み合わせでのみ発生する表示上の問題をデバッグするのに便利です。

History（履歴）

「History」タブでは、過去に実施した全ての速度テストの履歴を確認できます。無料アカウントでは、保存できる履歴の数に上限があります。また、特定のURLを監視することもできるので、時間の経過によるパフォーマンスの変化を追跡することも可能です。

特に便利なのは、過去のレポートを選び横並びで比較できる機能です。サイトの最適化を行なっていて、パフォーマンスが改善したかどうか確認したい時に大変便利です。なお、時に最適化を過剰に行ってしまうこともあるので注意が必要です。

ケーススタディで使用したドメインの設定

GTmetrixの詳細ガイドをお読み下さりありがとうございました。アドバイスやケースステディを掲載しておきながら、それを実際に行うまでのプロセスが開示されていないとがっかりするものです。そこで、この記事で使用したケーススタディの設定を以下にご紹介します。ご自由にご活用ください。

アーキテクチャ

KeyCDNの展開には無料のCDN Enablerプラグインを使用しました。
Googleアナリティクスをローカル環境で同期するのには無料のCAOSプラグインを使用しました。
不必要なHTTPリクエストを排除し、絵文字や埋め込みを無効化するのには有料のperfmattersプラグインを使用しました。
読み込み時の特定のスクリプトを無効化するのには有料のGonzalezプラグインを使用しました。
画像の圧縮には有料のImagifyプラグインを使用しました。

WordPressプラグイン

こちらは今回WordPressサイトで使用したプラグインの一覧です。

KeyCDNの展開には無料のCDN Enablerプラグインを使用しました。
Googleアナリティクスをローカル環境で同期するのには無料のCAOSプラグインを使用しました。
不必要なHTTPリクエストを排除し、絵文字や埋め込みを無効化するのには有料のperfmattersプラグインを使用しました。
読み込み時の特定のスクリプトを無効化するのには有料のGonzalezプラグインを使用しました。
画像の圧縮には有料のImagifyプラグインを使用しました。

お勧めの関連記事

WordPressサイトを高速化する方法（包括的ガイド）
WordPressで絵文字を無効化する方法
WordPressで埋め込みを無効化する方法
WordPressサイトで外部サービスを特定、分析する方法
WordPressサイトでGoogle PageSpeed Insightsの100/100を獲得するには
WordPressサイトのAdmin-Ajaxの過剰な使用の原因を特定する方法
DNSルックアップを減らし高速化するための７つのヒント

まとめ

このように速度テストツールGTmetrixの仕組みやグラフの意味を深く理解することで、サイトのパフォーマンスを改善する際にデータに基づいた決定がしやすくなります。滝グラフは個別のアセットがどのように読み込まれているかを理解する上で非常に重要です。Pingdomとの比較に関して言えば、それぞれ異なる指標で計測するため、どちらを使用するにしても一つのツールに決めて同じものを使い続けるべきでしょう。あなたは他にもGTmetrixに関するアドバイスをご存知でしょうか？

上記の関連記事以外にももっと詳細な記事をご覧になりたい方は、是非ともコメント欄からお知らせください。

Brian Jackson

Brianの最大の情熱の一つは10年以上使用してきたWordPressです。複数のプレミアムプラグインさえ開発しています。Brianの趣味はブログや映画やハイキングなどです。TwitterでBrianとつながりましょう。