プラグインではなく症状から始める
ページの応答が速くても、遅く感じられることがあります。Time to First Byte（TTFB）はナビゲーションが応答の最初の1バイトを待つ時間、Largest Contentful Paint（LCP）は最も大きな表示要素、Interaction to Next Paint（INP）はクリック・タップ・キーボード操作への反応を表します。どれか一つを改善しても、他が自動的に良くなるわけではありません。
これは診断のためのガイドであり、計測済みのクライアント案件の報告ではありません。変更が効いたかどうかは、ご自身の変更前後のデータで判断してください。
比較できる基準値をつくる
- 代表的なテンプレート（記事、カテゴリー、商品、チェックアウト）を選びます。ログイン中と匿名のセッションを両方含めます。
- 端末、回線、場所、URL、キャッシュの状態、デプロイしたバージョンを記録します。最良のスコアを選ぶのではなく、同じ条件でラボテストを繰り返します。
- PageSpeed Insights や Search Console でフィールドデータを確認します。アクセスの少ない URL には個別のデータがないことがあり、オリジン単位のデータはより広い範囲を表すので、その旨を明記します。
- キャッシュのヒットとミスを分けて考えます。ウォームキャッシュの速い応答が、無効化時やアクセス急増時の遅いオリジンを隠していることがあります。
サーバーの処理を安全に減らす
ブラウザのネットワークパネルでドキュメントのリクエストを調べ、次に PHP、データベースクエリ、外部 API の呼び出しをプロファイルします。遅いクエリ、繰り返されるリモート呼び出し、プロセスの飽和、遠いオリジンは、それぞれ別の対策が必要です。永続オブジェクトキャッシュはデータベースの重複処理を減らせますが、HTML レスポンス全体をキャッシュすることとは別物です。
ページ全体のキャッシュは、匿名で閲覧される記事ページに効果があります。アカウントページ、カート、チェックアウト、認証済みのレスポンス、個人情報を含むレスポンスを公開キャッシュに入れてはいけません。Cookie、リクエストメソッド、クエリパラメーター、キャッシュキーについてホスティング会社と確認しましょう。デプロイ前に独立した2つのセッションでテストし、コンテンツを編集すると該当するキャッシュが無効化されることを確認します。
ブラウザが描画する内容を改善する
パフォーマンストレースで実際の LCP 要素を特定します。画像なら、その URL を初期 HTML に含め、適切なサイズの画像を用意し、遅延読み込みにしないでください。テキストなら、描画をブロックするスタイルとフォントの読み込みを確認します。画像や埋め込みの領域を確保して、レイアウトのずれを減らしましょう。
INP については、遅い操作を再現してメインスレッドを調べます。不要な処理を減らし、長いタスクを分割し、レイアウトの読み取りを書き込みの前にまとめます。処理を後のタスクに回すのは、そのタスク自体が大きな塊にならない場合にだけ効果があります。
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.デプロイ後に体験を確認する
Core Web Vitals の「良好」の基準は、訪問の75パーセンタイルで評価して LCP が2.5秒以下、INP が200ミリ秒以下、CLS が0.1以下です。TTFB は診断に役立ちますが、それ自体は Core Web Vitals には含まれません。Lighthouse の読み込みテストでは、実際のセッションの INP は測れません。
チェックアウト、ナビゲーション、同意管理ツール、サードパーティのウィジェットを再テストします。フィールドの計測値は時間をかけて追いましょう。集計期間は移動するため、リリースがすぐに反映されるわけではありません。変更内容と回帰があればそれも計測値と一緒に記録します。
よくある質問
Core Web Vitals に合格すれば順位は上がりますか？
いいえ。高速な体験は読者の役に立ち、検索でのパフォーマンスを後押しすることはありますが、関連性、有用なコンテンツ、その他のシグナルも引き続き重要です。速度は順位の約束ではなく、測定できる製品改善として扱いましょう。
TTFB は Core Web Vitals の一つですか？
いいえ。TTFB は応答の最初の1バイトまでの遅延を測るもので、サーバーとネットワークの経路の診断に役立ちます。Core Web Vitals は LCP、INP、CLS です。TTFB で遅い応答を調べたうえで、有用なコンテンツがいつ表示されるか、操作がどう反応するかを別々に確認してください。
キャッシュされたトップページは速いのに、チェックアウトが遅いのはなぜですか？
公開トップページはキャッシュ済みの HTML を再利用できますが、チェックアウトではセッションごとに新しい処理が必要です。キャッシュされないリクエストを計測し、データベースクエリ、拡張機能、外部サービスを調べてください。テスト結果を良くするためだけにチェックアウトを公開キャッシュの対象にしてはいけません。プライバシーと取引の正しさを確認しましょう。
変更前後のパフォーマンスはどう比較すればよいですか？
URL、端末、回線プロファイル、キャッシュの状態をそろえ、テストを繰り返します。結果の幅を記録し、同じ顧客操作をテストします。フィールドデータは得られ次第活用しましょう。一度の速いラボテストだけでは、すべての訪問者を表せません。より広い確認手順はパフォーマンスのチェックリストにまとめています。
出典と参考資料
あわせて読みたい
監査の範囲を広げるにはWordPress 高速化チェックリスト47項目を使うか、Web パフォーマンス改善サービスをご覧ください。
Leave a Reply