サイトのパフォーマンスをチェックできる速度計測ツールは多数存在します。以前の記事では、Pingdomの概要と使い方を取り上げましたが、今回は人気測定ツール「GTmetrix」を活用して、データを理解する方法をご紹介します。

GTmetrixではスコアを用いた評価が表示され、サイトの異常を把握することができます。表示方法はわかりにくいところもありますが、各項目の意味を理解することで、単にサイトのスコアを上げるだけではなく、最も重要であるサイトパフォーマンスを改善することができます。

GTmetrixはカナダに本社を置くGT.netという企業が提供しています。当初は自社の顧客サイトのパフォーマンスを判定するためのツールとして開発されました。Pingdomと並び、現在世界的に最も有名な速度測定ツールの1つと言えます。

「GTmetrixのレポートで提示された助言にどう従うべきか」というKinstaのお客様からのお問い合わせを受け、今回この記事を執筆しています。GTmetrixは、他の開発者向けツールと比べると非常に使いやすく、初心者でも簡単に使用できます。スコアと推奨事項の生成には、GoogleのPageSpeed InsightsとYSlowを組み合わせています。

速度測定ツール「GTmetrix」
速度測定ツール「GTmetrix」

GTmetrixの分析機能

GTmetrixには完全無料版があり、アカウントに登録するだけで複数の機能を利用できます。有料プランもありますが、今回は無料版を使用します。

アカウントに登録すると、さらに詳細な設定が利用可能になります。追加で設定できる項目の1つは、サイト速度を測定するロケーションです。測定を行う場所はサイトがホストされているサーバーとの関係上、非常に重要です。レイテンシが低いほど、読み込み時間は短くなります。現時点では、以下から選択できます。

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

使用ブラウザは、Chrome（PC版）またはFirefox（PC版）から選択可能です（モバイル版は有料プランでのみ）。また、接続速度も変更できるため、さまざまな接続環境におけるページの読み込み速度を再現できます。

GTmetrixテスト環境のオプション
GTmetrixテスト環境のオプション

追加機能として、動画を作成することもできます。ページがどのように表示されるかを実際に確認できるため、不具合の原因調査に役立ちます。また、AdBlock Plus機能も便利です。Google AdSenseなどの外部広告ネットワークを利用している場合、この機能を有効にすることで、広告がページ読み込み速度に与える影響を確認できます。

GTmetrixにて有料で利用できる機能
GTmetrixにて有料で利用できる機能

追加オプションには、onload時点でテストを停止する機能（これについては後ほど詳しく）、リクエストにCookieを含めて送信する機能、HTTP認証の使用、URLのホワイトリスト／ブラックリスト設定、画面解像度やデバイスピクセル比の設定、さらにユーザーエージェントの上書きなどがあります。

GTmetrixでサイトを分析する方法

ウェブページは、HTML、JavaScript、CSS、画像など、さまざまなアセットによって構成されています。これらの各要素は、サイト上のコンテンツをレンダリングするためにそれぞれリクエストを生成します。一般的に、リクエスト数が多いほどサイトの読み込み速度は遅くなる傾向があります。必ずしも常にそうとは限りませんが、多くの場合に当てはまります。

ここからは、GTmetrixの各項目を詳しく紹介しながら、それぞれが示す情報の意味を解説していきます。サイト全体のパフォーマンス改善に役立つ、有用なヒントが得られるはずです。なお、重要なのはスコアの向上だけに固執するのではなく、実際のサイト速度を改善することに重点を置くことです。

GTmetrix Summary（パフォーマンススコアと詳細）

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

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

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

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

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

以下は、Kinstaでホストしている導入事例用ドメイン「kinstalife.com」の測定結果です。最初の測定結果は以下のようになりました。

  • GTmetrix Grade（スコア）：B
  • GTmetrix Performance（パフォーマンス）：85%
  • GTmetrix Structure（構造）：83%
  • LCP：1.0秒
  • TBT：0ミリ秒
  • CLS：0
「kinstalife.com」のGTmetrix速度測定結果
「kinstalife.com」のGTmetrix速度測定結果

その後、再度測定したところ、GTmetrix Gradeは「A」になりました。これは、GTmetrixの速度テストを複数回実行しているとよくある現象で、DNSキャッシュやサーバーキャッシュなどのキャッシュ機能が原因になっている可能性があります。詳しくは、ウォーターフォール分析のセクションでご説明します。

GTmetrixでの二回目の速度テスト
GTmetrixでの二回目の速度テスト

「Summary（概要）」タブには、ページ読み込み時の主要イベントを時系列で表示する速度の可視化グラフも含まれています。以下のスクリーンショットでは、kinstalife.comの「TTFB、FCP、LCP、onload時間（ページの読み込み完了時間）、Time to Interactive（ページが操作可能になるまでの時間）、Fully Loaded Time（ページ全体の読み込み完了時間）を確認できます。

kinstalife.comの各速度指標
kinstalife.comの各速度指標

また、概要ページの下部には「Top Issues（主要な問題）」と「Page Details（ページ詳細）」セクションがあります。「Top Issues」では優先的に修正すべき項目の一覧を確認でき、「Page Details」ではページを構成するファイルの割合やサイズの内訳を確認できます。

GTmetrixの「Top Issues」と「Page Details」セクション
GTmetrixの「Top Issues」と「Page Details」セクション

Performance

「Performance（パフォーマンス）」タブには、Lighthouseから引用した数々の便利なパフォーマンスデータ指標が表示されます。「Summary」概タブに表示されるLCP、TBT、CLSに加えて、「Performance Metrics（パフォーマンス指標）」セクションには、「Speed Index（表示速度指数）」、「Time to Interactive（ページが操作可能になるまでの時間）」、「First Contentful Paint（最初のコンテンツが表示されるまでの時間）」という指標が表示されます。

GTmetrixの「PageSpeed」の各スコア
GTmetrixの「PageSpeed」の各スコア

「Performance Metrics」の項目では、改善すべき問題点が具体的に示されるわけではありませんが、ユーザーエクスペリエンスに関する全体的な傾向を把握するのに役立ちます。

さらに画面を下にスクロールすると、「Onload Time（ページの読み込み完了時間）」、「TTFB（サーバー初期応答時間）」、「Fully Loaded Time（ページ全体の読み込み完了時間）」など、「Browser Timing（ブラウザ読み込み時間）」の統計を確認できます。かつてはこれらの指標が非常に重視されていましたが、現在はCore Web Vitalsを優先的に最適化することをおすすめします。多くの場合、これらを改善することで、ブラウザの読み込み時間も改善されます。

GTmetrixのブラウザ読み込み時間の指標
GTmetrixのブラウザ読み込み時間の指標

Structure

「Structure（構造）」タブでは、サイトのパフォーマンスに影響を及ぼす具体的な問題を確認できます。「eliminate render-blocking resources（レンダリングを阻害するリソースを削除）」「minify CSS（CSSを圧縮）」といった、具体的な推奨事項が記載されるので非常に有益です。

以下、WordPressサイト管理者が直面する一般的な推奨事項をご紹介します（このタブで表示される推奨事項は定期的に更新する予定です。気になる方はぜひこの記事をブックマークしておいてください）。通常は、これらの項目を改善するだけでパフォーマンスの改善が見られます。

GTmetrixの「PageSpeed」の各スコア
GTmetrixページ速度のスコア

Serve scaled images（適切なサイズの画像を配信する）

サイトで画像を扱う際は、常に実際の表示サイズに合わせて画像をアップロードし、CSSによるリサイズに依存しないようにしましょう。そうしないと、「Serve scaled images（適切なサイズの画像を配信する）」という改善項目が表示される原因になります。

WordPressでは、デフォルトで画像をメディアライブラリにアップロードする際に自動的にリサイズが行われます。これらの設定は「設定」>「メディア」から確認できます。画像の最大幅は、サイトのコンテンツ幅に近いサイズに設定するのがおすすめです。こうすることで、CSSによって画像サイズを無理に縮小して表示する必要がなくなります。

また、画像最適化プラグインを使用して、画像を自動的にリサイズすることも可能です。

Serve scaled images（適切なサイズの画像を配信する）
Serve scaled images（適切なサイズの画像を配信する）

Inline small CSS（小さなCSSをインライン化する）

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

Inline small CSS（小さなCSSをインライン化する）
Inline small CSS（小さなCSSをインライン化する）

CSSを簡単にインライン化するには、Autoptimizeのような無料プラグインを利用できます。「Inline all CSS?（すべてのCSSをインライン化する）」オプションにチェックを入れたうえで、インライン化しない追加のCSSファイルを除外設定してください。

AutoptimizeでCSSをインライン化
AutoptimizeでCSSをインライン化

Inline small JavaScript（小さなJavaScriptをインライン化する）

小さなCSSをインライン化する場合と同様に、小さなJavaScriptのインライン化にも同じことが当てはまります。通常、JavaScriptをインライン化するとページ全体のダウンロードサイズが増加するため、あまり推奨されません。ただし、リクエスト数が少ない小規模なサイトでは、パフォーマンス向上につながる場合があります。こちらもAutoptimizeのJavaScript設定を利用できます。

Inline small JavaScript（小さなJavaScriptをインライン化する）
Inline small JavaScript（小さなJavaScriptをインライン化する）

Leverage Browser Caching（ブラウザキャッシュを活用する）

「Leverage browser caching（ブラウザキャッシュを活用する）」は、多くの人が対処に苦労する一般的な改善項目です。これは、ウェブサーバーに適切なHTTPキャッシュヘッダーが設定されていない場合に表示されます。詳しくは、「Leverage browser caching」警告の解消方法についてこちらをご覧ください。

なお、この問題を修正できるのは、自分で管理しているリソースに限られます。たとえば、サードパーティの広告ネットワークに対してこの警告が表示されている場合、ユーザー側で対応することはできません。

Leverage Browser Caching（ブラウザキャッシュを活用する）
Leverage Browser Caching（ブラウザキャッシュを活用する）

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

「Serve Resources From a Consistent URL（一貫したURLからリソースを配信する）」が表示される場合、同じリソースが異なるURLから配信されている可能性があります。これは、クエリ文字列が付与されている場合によく発生します。静的リソースからクエリ文字列を削除する方法はこちらをご覧ください。クエリ文字列を削除することで、同じリソースが重複して読み込まれる問題を防ぐことができます。

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

Defer Parsing of JavaScript（JavaScriptの解析を遅延する）

JavaScriptとCSSは、デフォルトではレンダリングをブロックするリソースです。つまり、ブラウザがこれらをダウンロードして処理するまで、ウェブページの表示が遅れる可能性があります。

defer 属性を使用すると、ブラウザはHTMLの解析が完了するまでリソースのダウンロードを遅延させることができます。この問題を簡単に解消する方法としては、無料のAutoptimizeやAsync JavaScriptプラグインを利用する方法があります。レンダリングをブロックするJavaScriptとCSSを解消する方法はこちらをご覧ください。

Defer Parsing of JavaScript（JavaScriptの解析を遅延する）
Defer Parsing of JavaScript（JavaScriptの解析を遅延する）

詳しい手順は、WordPressでJavascriptの読み込みをずらす警告を解消する方法をご覧ください。

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

圧縮は、ソースコードの機能を変更することなく、不要な文字を削除する処理です。これには、改行、空白、インデントなどが含まれます。これにより、データ容量を削減でき、ダウンロード速度や解析・実行時間の短縮につながります。

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

この用途にもAutoptimizeプラグインが便利です。「Optimize JavaScript Code（JavaScriptコードを最適化）」と「Optimize CSS Code（CSSコードを最適化）」の両方にチェックを入れるだけで利用できます。

大規模なサイトの場合は、下部にある詳細設定も調整してみることをおすすめします。設定によっては、かえってサイトのパフォーマンスに悪影響を及ぼす場合があるためです。一般的に、大規模サイトではCSSやJavaScriptのインライン化や結合は推奨されません。そこで活躍するのが、HTTP/2の性能です。

AutoptimizeでCSSとJavaScriptを圧縮
AutoptimizeでCSSとJavaScriptを圧縮

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

HTTP Archiveによると、画像はウェブページ全体のデータ容量の平均66%を占めています。したがって、WordPressサイトを最適化する際は、まず画像の最適化から始めるのが効果的です。画像の最適化は、スクリプトやフォントの最適化よりも重要です。

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

理想を言えば、すべての画像はWordPressにアップロードする前に圧縮・最適化しておくべきです。しかし、実際にはそれを毎回徹底するのは簡単ではありません。そのため、優れた画像最適化プラグインを利用することをおすすめします。これにより、画像の圧縮やリサイズを自動化でき、サイト上で軽量かつ高速に読み込まれるようになります。詳しくは、ウェブ向けに画像を最適化する方法をご覧ください。

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

WordPressにおいて、サーバーの初期応答時間（TTFB）が遅くなる主な原因は、ページキャッシュを使用していないことです。ページキャッシュがない場合、WordPressはリクエストごとにPHPを使用してページを動的に生成するため、アクセスが増えるとすぐにサーバーへ大きな負荷がかかります。

一方、ページキャッシュを有効にすると、サイトは事前生成されたHTMLファイルを配信できるようになります。これは、各ページリクエストをPHPで処理するよりも高速かつスケーラブルです。

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

Kinstaをご利用の場合は、Nginx設定によってページキャッシュが自動的に処理されるため、ページキャッシュについて心配する必要はありません。利用中のWordPressサーバーがページキャッシュに対応していない場合は、WP RocketやW3 Total Cacheなどのキャッシュプラグインをインストールすることをおすすめします。

さらにサーバー応答時間を短縮したい場合は、WordPressサイトにCloudflare APOを導入することをおすすめします。Cloudflareが提供するこの最適化サービスでは、サイトのHTMLページを世界中のエッジサーバーに配信できるため、グローバル規模でサーバー応答時間を短縮できます。

Minify HTML（HTMLを圧縮する）

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

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

例によって、ここでもAutoptimizeプラグインが便利です。「Optimize HTML Code（HTMLコードを最適化）」オプションを有効にするだけでOKです。

AutoptimizeでHTMLコードを最適化
AutoptimizeでHTMLコードを最適化

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

GZIPは、ファイルの圧縮および解凍に使用されるファイル形式とソフトウェアです。GZIP圧縮はサーバー側で有効化され、HTML、スタイルシート、JavaScriptファイルのサイズをさらに削減できます。ただし、画像ファイルはすでに別の方式で圧縮されているため、GZIP圧縮の対象にはなりません。圧縮によって最大70%のサイズ削減を実現した例もあります。

WordPressサイトにおいて、最も簡単に実施できる最適化の一つと言えるでしょう。なお、KinstaではGZIP圧縮がデフォルトで有効になっています。

Enable GZIP Compression（gzip圧縮を有効化する）
Enable GZIP Compression（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のリダイレクトはサイト表示を遅くする要因になります。そのため、訪問者が体験するリダイレクト数をできるだけ減らすことが重要です。

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

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

「Specify a cache validator（キャッシュバリデータを指定する）」という改善項目は、HTTPキャッシュヘッダーが不足している場合に表示されます。これらのヘッダーは、キャッシュの有効性を検証し、保持期間を設定する役割を持つため、すべてのオリジンサーバーのレスポンスに含めるべきです。

これらのヘッダーが存在しない場合、リソースに対するリクエストが毎回新たに生成され、サーバー負荷の増加につながります。キャッシュヘッダーを適切に利用することで、以降のリクエストではサーバーからリソースを再取得する必要がなくなり、帯域幅の節約やユーザーパフォーマンスの向上につながります。

なお、制御できないサードパーティ製リソースに対しては、この問題を修正することはできません。

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

この改善項目を解消するには、複数のHTTPキャッシュヘッダーを利用できます。詳しくは、キャッシュバリデータを指定する方法をご覧ください。

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

CSSによって画像サイズを変更しないのと同様に、画像サイズを明示的に指定することも重要です。つまり、HTMLコード内で画像のwidth（横）とheight（縦）を指定する必要があります。

誤り

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

良い例

<img src="https://domain.com/images/image1.png" width="200" height="100">
Specify Image Dimensions（画像の寸法を設定する）
Specify Image Dimensions（画像の寸法を設定する）

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

CSSファイルやJavaScriptファイルのURL末尾には、通常「domain.com/style.css?ver=4.6」のようにバージョン情報が付与されています。しかし、一部のサーバーやプロキシサーバーは、cache-control:publicヘッダーが存在していても、クエリ文字列付きURLをキャッシュできない場合があります。そのため、クエリ文字列を削除することで、キャッシュ効率が向上することがあります。これは、コードの修正や無料のWordPressプラグインを使って簡単に実現できます。

詳しくは、静的リソースからクエリ文字列を削除する方法をご覧ください。なお、制御できないサードパーティ製リソースについては、この問題を修正することはできません。

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

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

これはHTTPヘッダーの一種であり、クライアントが圧縮されたコンテンツを処理できるかどうかをブラウザに伝える役割を持つため、すべてのオリジンサーバーのレスポンスに含める必要があります。通常、GZIP圧縮を有効にすると、この問題もあわせて解消されます。詳しくはこちらをご覧ください。

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

Waterfall

GTmetrixの「Waterfall（ウォーターフォール）」タブには、ウェブページ上で発生するすべての個別リクエストが表示されます（以下参照）。これにより、各リクエストを分析し、サイトの遅延やパフォーマンス低下の原因を特定できます。

以下では、各リクエストに表示される色の意味について、より詳しく解説します。

GTmetrixの「Waterfall」タブ
GTmetrixの「Waterfall」タブ

Blocking（茶色）

ブラウザがウェブページを読み込む際、JavaScriptやCSSリソースは通常、ダウンロードと処理が完了するまでページの表示をブロックします。この待機時間は、GTmetrixのウォーターフォールチャート上では「blocking」として表示されます。レンダリングをブロックするJavaScriptとCSSを解消する方法はこちらをご覧ください。

Blocking
Blocking

DNS Lookup（青緑）

DNSルックアップは、電話帳のようなものだと考えるとわかりやすいでしょう。Domain Name Server（DNSサーバー）には、ウェブサイトに関する情報と、どのIPアドレスへ接続すべきかという情報が保存されています。

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

DNS Lookup
DNS Lookup

GTmetrixでサイトを2回目にテストすると、DNS情報がすでにキャッシュされているため、再度DNSルックアップを実行する必要がなくなります。これが、GTmetrixで複数回テストを実行するとサイトが高速化したように見える理由の一つです。

以下のスクリーンショットでもわかるように、2回目のテストでは、最初のDOC読み込み時のDNSルックアップ時間が0msになっています。この点は、多くの人が誤解しやすいポイントです。

そのため、DNSルックアップ時間もレポートに含めたい場合を除き、テストは複数回実行し、その平均値を参考にすることをおすすめします。

二度目のDNSルックアップ結果
二度目の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接続、つまりTCP接続を確立するまでに必要な合計時間を指します。この仕組みを詳しく理解する必要はありませんが、これはホスト／クライアントとサーバー間で行われる通信方式の一つです。

gtmetrix connecting
Connecting

Sending（赤）

「Sending」はウェブブラウザがサーバーにデータを送信するのにかかった時間を意味します。

gtmetrix sending
Sending

Waiting（紫）

GTmetrixにおける「Waiting」は、実際にはTTFBを指しています。TTFBは一部のツールでも使用される指標で、ウェブサーバーやその他ネットワークリソースの応答性を測定するために用いられます。

一般的に、100ミリ秒未満であれば良好なTTFBとされています。一方で、300〜400ミリ秒に近づいている場合は、サーバー設定に問題があるか、より高性能なウェブスタックへの移行を検討した方がよいかもしれません。以下のテストでは、TTFBは約100ミリ秒であり、非常に優れた結果となっています。

gtmetrix waiting
Waiting

TTFBを短縮する簡単な方法としては、サーバー環境で適切なキャッシュが設定されていることを確認し、CDNを活用することが挙げられます。

詳しくは、WordPressサイトのTTFBを改善する方法について解説した記事をご覧ください。また、エッジキャッシュについて理解を深めるのもおすすめです。エッジキャッシュを利用することで、サイトのページを読者へより高速に配信できるようになります。

Receiving （灰色）

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

gtmetrix receiving
Receiving

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

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

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

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

個別のリクエストをクリックすると、HTTPレスポンスヘッダーも確認できます。HTTPレスポンスヘッダーには通常、有用な情報が含まれています。

例えば、以下のスクリーンショットでは、たとえばウェブサーバーでgzip圧縮が有効になっていること、HHVM上で動作していること、キャッシュから配信されていること（キャッシュされていない場合は「MISS」と表示）、cache-controlヘッダー、サーバー構成（常に表示されるとは限りません）、expiresヘッダー、ブラウザのユーザーエージェントなどが一目でわかります。

GTmetrixのHTTPレスポンスヘッダー
GTmetrixのHTTPレスポンスヘッダー

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

Video（動画）

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

GTmetrixの録画機能
GTmetrixの録画機能

History（履歴）

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

「History」タブ
「History」タブ

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

GTmetrixでレポートを比較
GTmetrixでレポートを比較

導入事例で使用したドメインの設定

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

アーキテクチャ

  • 導入事例用ドメイン（perfmatters.io）は、アメリカ（中央部）のデータセンターからKinstaで稼働しています。KinstaではHTTP/2、Nginx、MariaDBを採用し、これらが高速な読み込み時間に貢献しています。
  • HHVMを使用しています。現在、KinstaではHHVMよりさらに高速なPHP 7.3も利用可能で、ボタンをクリックするだけでPHPバージョンを切り替えることができます。
  • キャッシュプラグインを使用していません。Kinstaではサーバーレベルですべてのキャッシュ処理が行われるため、設定が大幅に簡素化され、多くの場合より高速なパフォーマンスを実現できます。

WordPressプラグイン

関連記事

まとめ

このように、GTmetrixの速度テストツールの仕組みや各グラフの意味を理解することで、パフォーマンス改善において、よりデータに基づいた判断ができるようになります。特にウォーターフォール分析は、各アセットがどのように読み込まれているかを把握するうえで非常に重要です。

また、Pingdomと比較する際には注意が必要です。両者は異なる仕組みで測定を行う別々のツールであり、計測方法も異なります。そのため、比較を行う場合は、どちらか一方のツールに統一して使用することをおすすめします。

Brian Jackson

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