測定条件を固定する
GTmetrixの通常レポートは、指定した条件でChromeを動かすlab、つまり合成測定です。条件が違えば、同じURLでも値は変わります。改善前後を比較する基準セットと、主要利用者を再現する確認セットを分けて持つと判断が安定します。
Location
テストサーバーと配信元の距離はlatencyへ影響します。主要利用者に近い場所を選び、比較中は変更しません。無料で選べる地域やPROの範囲は公式画面で確認します。
記録例:Tokyo相当 / Seattle固定
Device / Browser
DesktopとSimulated Mobileでは画面幅、CPU、配信画像、レスポンシブ分岐が変わります。アクセス解析で多い端末を基準にします。
記録例:Chrome Desktop 1366×768
Connection Speed
既定のUnthrottledは非常に速く、一般利用者を代表しない場合があります。実利用に近い4G、LTE、Broadbandなどを選び、速度名も保存します。
記録例:LTE / 4G Slow / Broadband
正確なURL
httpとhttps、末尾slash、query、ログイン状態で結果が変わります。最終URLだけでなく、測定へ入力したURLとredirect chainを記録します。
記録例:https://example.com/page/
追加オプション
Adblock、Video、Cookie、HTTP Authenticationなどは測定内容を変えます。有効・無効を明示し、比較途中で切り替えません。
記録例:Adblock off / Video on
時刻と回数
共有基盤、CDN cache、第三者script、負荷で結果が揺れます。実務では同条件で3回以上測り、単発値ではなく中央値と範囲を残します。
記録例:3〜5回の中央値 + 最小最大
現行UIで測定する
GTmetrixは現在、レポートを見るために検証済みアカウントへのログインを求めています。旧記事の「登録なしで利用できる」は現行仕様ではありません。無料枠や回数制限は変わり得るため、作業日のアカウント画面を正とします。
1. 対象を決める
代表URLをページ種類ごとに選定
トップだけでなく、記事、商品、フォームなど異なるtemplateから代表URLを選びます。改善対象と成功条件も先に決めます。
2. URLを入力
Enter URL to Analyze
公開URLを入力します。認証が必要なページは、権限やCookieを不用意に共有せず、専用のテスト環境と公式オプションを使います。
3. 条件を選択
Location / Device / Connection
Analyzeを押す前に3項目とAnalysis Optionsを確認します。Presetを使う場合も中身を記録し、名前だけで条件を判断しません。
4. 連続測定
同条件で3〜5回
初回だけを採用せず、同じ設定で複数回測ります。cache warm/coldを比較する場合は別系列として扱います。
5. report URLを保存
日付・条件・report link
Gradeだけ転記せず、測定日時、各条件、主要指標、report URL、変更内容を一緒に保存します。
6. 基準値を確定
median + variation
中央値を基準にし、ばらつきが大きければ原因を調べます。改善後も同じ回数と条件で比較します。
既定値は代表ユーザーとは限らない
2026年5月更新の公式資料では、既定条件はSeattle、Chrome Desktop、Unthrottledです。Unthrottledだけでモバイル利用者の体験を判断せず、解析データに合う条件を追加してください。
レポートのタブを目的別に読む
Summaryだけで改善内容を決めず、症状に応じて詳細タブへ進みます。GTmetrix Gradeは入口であり、原因ではありません。
| タブ | 主な表示 | 判断に使う問い |
|---|---|---|
| Summary | Visualization / Top Issues / Page Details | どこから調べるかを決める入口です。上位issueを仮説として扱い、関連する詳細タブで確認します。 |
| Performance | FCP / SI / LCP / TBT / CLS | lab測定で、表示、block、layout shiftのどこが遅いかを把握します。Browser Timingsは補助情報です。 |
| Structure | Lighthouse audits / GTmetrix audits | どの実装候補が指標へ影響したかを調べます。scoreを100にするためでなく、該当resourceと効果を確認します。 |
| CrUX | LCP / INP / CLS / TTFB / FCP | 実利用者のfield dataを見ます。対象URLに十分なデータがなければ表示されず、GTmetrixでは全端末等を集約した値です。 |
| Waterfall | request / status / timing / initiator | 遅いrequest、redirect、第三者script、cache、接続、backend待ちを時系列で切り分けます。 |
| Video / History | 再生 / 経時グラフ | 見た目の進行と長期傾向を確認します。Videoは事前に有効化が必要で、Historyは同条件の系列を比較します。 |
Labとfieldを混ぜない
通常タブの値は指定条件のlab測定、CrUXは過去28日間の実利用者集計です。同じ瞬間・同じ母集団ではないため、数値が一致しなくても異常とは限りません。
INPとTBTは同じ指標ではない
INPはfieldで実操作への応答を測り、TBTはlabのload中main-thread blockingを測ります。GTmetrixは比較用proxyとしてTBTを示しますが、置き換えではありません。
PageSpeed Insightsと直接比較しない
同じLighthouse系でもhardware、場所、network、throttling手法、版が異なります。別ツールのscore差より、各ツール内の同条件推移を見ます。
UI名は更新される
旧PageSpeed/YSlow画面を前提にしません。現行のSummary、Performance、Structure、CrUX、Waterfallを基準にし、公式更新履歴を確認します。
指標を症状と原因候補へ変換する
scoreが低いだけでは変更内容を決められません。metricで症状を特定し、auditとWaterfallでresourceを絞り、実装上の原因を確認します。
まず確認する組み合わせ
- LCPが遅い：LCP要素、画像取得、server response、render-blockingを確認
- TBTが大きい：long task、JavaScript評価、third-party script、main threadを確認
- CLSが大きい：寸法のないmedia、font、遅いrequest、挿入iframeを確認
- TTFBが遅い：redirect、connect、backend、cache、地域差をWaterfallで確認
- 転送や失敗がある：status、Location、request initiator、依存先を確認
すぐ断定しないこと
- Gradeが低いだけでサーバー乗換えを決めない
- Structure Score 100を実利用者性能の保証にしない
- TBTが良いだけでfieldのINPも良いと断定しない
- 一回の測定差を改善効果として報告しない
- 異なる場所・端末・接続・Lighthouse版のscoreを同じ系列にしない
「High」を全部直す前に、resourceと影響を確かめる
Top IssuesのImpactは優先順位の手掛かりですが、サイトの目的、実装コスト、副作用、field dataを含めて判断します。複数auditが同じresourceを指す場合は、原因を一つ直すことで複数の値が変わることがあります。
原因を切り分ける実務フロー
変更候補を、観測した症状と具体的resourceへ結び付けます。WordPressプラグインやサーバー移行を先に決めず、証拠から対策を選びます。
- 1
症状を一つ選ぶ
LCP、TBT、CLS、TTFB、転送、request sizeなど、今回改善する指標を一つに絞ります。Gradeだけを目標にしません。
- 2
該当要素・requestを特定する
PerformanceとStructureの詳細を展開し、DOM要素、URL、potential savings、main-thread taskなどを確認します。
- 3
Waterfallで順序を見る
documentからLCP resourceまでの依存、DNS・connect・SSL・backend、redirect、第三者requestの開始点と待ち時間を見ます。
- 4
変更を一つ選ぶ
画像形式・寸法、preload、cache、script defer、third-party削減、server処理などから、観測した原因へ直接効く変更を選びます。
- 5
副作用とrollbackを決める
機能、表示、計測、広告、フォームを壊さないか確認し、設定変更前の値と戻し方を保存します。cache pluginの重複導入は避けます。
- 6
同条件で再テストする
変更前と同じURL・場所・端末・接続・オプションで同回数測り、中央値、ばらつき、対象指標、他指標への影響を比較します。
サーバー変更は最後に因果を確認する
TTFBが複数地域・複数回で継続して遅く、application処理、cache、database、外部API、配信構成を切り分けた後に、現行環境の制約と移行効果を評価します。単一のGTmetrix結果だけで乗換えを推奨しません。
同条件で再テストし、長期傾向を確認する
labの即時検証とfieldの長期確認は時間軸が違います。公開直後はlabで回帰を見て、十分な期間が経ってからCrUXや実測監視で利用者への反映を確認します。
条件表を添付する
URL、Location、Device/Browser、Connection、画面幅、日時、Preset、Video/Adblock、test回数、tool版を変更前後へ添えます。
中央値と範囲を見る
単発の最良値を採用せず、複数回の中央値と最小・最大を確認します。ばらつきが効果量より大きければ結論を保留します。
対象指標と回帰を見る
狙ったLCP等だけでなく、CLS、TBT、request数、page size、機能、見た目も確認します。別指標の悪化を隠しません。
Historyの系列を分ける
異なるAnalysis Optionsは別系列として扱います。LighthouseやGTmetrixの大きな更新日はnoteに残し、前後のscoreを単純比較しません。
CrUXは期間を待つ
CrUXは最新28日間のfield集計で、十分なtrafficがないURLはデータがありません。公開直後の効果判定をCrUXだけで行いません。
実利用の指標も併用する
RUM、Search Console Core Web Vitals、business event、error rateを併用し、速度変更が利用者や機能へどう影響したかを確認します。
公開停止・rollback条件
表示崩れ、フォーム不動、計測欠落、error増加、CLS悪化、主要端末での性能低下があれば変更を戻します。scoreだけ改善しても、機能やfield体験が悪化した変更は採用しません。
2025〜2026年の公式画面で位置を確認する
画面名を暗記するより、入力前のAnalysis Optionsと、report内のlab・fieldの境界を確認してください。次の画像はGTmetrix公式記事から取得し、出典時点を明記しています。
根拠資料
GTmetrixはUI、無料枠、測定条件、score計算を更新します。作業時は公式の最新版も確認してください。
GTmetrixのよくある質問
GTmetrixは登録なしで使えますか？
現行仕様では、生成したレポートを見るために検証済みアカウントへのログインが必要です。無料枠の回数、保持期間、選べる地域や端末は変更されるため、作業日の公式アカウント画面で確認してください。
GTmetrix GradeがAならCore Web Vitalsも合格ですか？
同じ意味ではありません。GradeはGTmetrixのPerformanceとStructureを組み合わせた評価です。Core Web Vitalsの合否はCrUXのLCP・INP・CLSのfield dataで確認し、十分なデータがないURLでは判定できません。
GTmetrixとPageSpeed Insightsの点数が違うのはなぜですか？
場所、hardware、network、throttling方法、Lighthouse版、Analysis Optionsが異なるためです。点数を直接一致させず、各ツール内で条件を固定した変化を追ってください。
LCPだけを改善すればよいですか？
いいえ。LCPはloadingを示しますが、応答性はINPやlab proxyのTBT、視覚安定性はCLSで確認します。機能、error、実利用者データも含めて評価します。
何回測定すればよいですか？
実務では同条件で最低3回、揺れが大きければ5回以上測り、中央値と範囲を比較します。回数を増やしても条件が違えば有効な比較になりません。
TTFBが遅ければサーバーを乗り換えるべきですか？
一回の値だけでは決めません。Waterfallでredirect、connect、backendを分け、複数地域・複数回で再現し、cache、application、database、外部APIを切り分けてから環境の制約を評価します。
あわせて確認したい記事
GTmetrixは、同条件で仮説を検証するための道具
主要利用者に合う条件を決め、同じ設定で複数回測り、Summaryから詳細タブへ原因を掘ります。変更は一つずつ行い、中央値とばらつき、機能回帰、field dataを確認してください。点数を上げることではなく、観測した利用者体験の問題を安全に減らすことが目的です。
執筆・検証
Finite Field 編集部
GTmetrix公式の更新資料、現行UI画像、LighthouseとCrUXの測定条件を確認し、再現可能な比較と変更後の回帰確認を重視して編集しています。
Web性能改善の相談
測定条件から改善・再検証まで整理
複数template、第三者script、cache、CDN、application処理が絡む場合は、RUM・lab・Waterfall・server logを合わせて原因と優先順位を整理します。
性能診断を相談するGTmetrix Grade、Core Web Vitals、検索順位、流入、売上の改善は保証しません。対象条件と変更リスクを確認して対応範囲を決めます。