速度と Core Web Vitals
遅いサイトの原因を直します。症状ではなく。
速度改善の多くは、キャッシュプラグインと圧縮ツールを入れて、期待を込めて再計測するだけです。それではラボのスコアが動くだけで、本当の問題は残ったままです。私は時間が実際にどこで使われているのかを計測し、そこを直し、ご自身のパソコンで再現できる改善前後の結果をお渡しします。
01デモお使いのブラウザからリアルタイムで
このページを、読んでいる今この瞬間に計測。
速度改善を売る人なら誰でも、うまくいった計測結果のスクリーンショットを見せられます。これは、あなた自身のブラウザがこのページを読み込んだときに記録した数値を、Google が使う基準値と並べたものです。ネットワークタブを開いて確かめてみてください。
マークアップ、スタイル、スクリプト、3 つの書体。今読んでいる内容を表示するのに必要なすべてです。
HTTP Archive が記録した Web ページの重さの中央値。
02診断時間が実際に使われている場所
遅さは症状です。原因はこちら。
私のもとに届く遅いサイトは、ほぼすべてが以下のうち 2 つか 3 つの理由で遅くなっています。診断の目的はそれがどれなのかを突き止めることです。原因ごとに対策はまったく異なり、間違った対策を買うことこそ、速度改善に二度お金を払うことになる理由だからです。
サーバーの処理に時間がかかっている
Time to First Byte が長いということは、ブラウザに 1 バイトも届かないうちに処理が行われているということです。WordPress では、テンプレートのループ内のキャッシュされていないクエリ、数 MB にまで膨らんだ autoload のオプションテーブル、ページ描画中に外部 API を呼ぶプラグインなどがよくある原因です。フロントエンドをいくら最適化しても、ここには手が届きません。
画面で最も大きな要素が巨大すぎる
横幅 4000 ピクセルで書き出され、PNG で配信されるメイン画像は、それだけで Largest Contentful Paint を不合格にします。対策は地味です。正しいサイズ、最新の画像形式、スマートフォンがデスクトップ版を読み込まないための srcset、幅と高さの明示、そして本当に重要な 1 枚への fetchpriority の指定です。
スクリプトが描画を止めている
head 内の同期スクリプトはどれも、ブラウザが描画を始める前の一時停止標識です。タグマネージャー、チャットウィジェット、A/B テストツール、フォントローダーがよくある容疑者で、1 ページでしか使わない機能のために全ページで読み込まれていることも少なくありません。
読み込み中にページがずれる
Cumulative Layout Shift は、場所を確保しないまま遅れて届く要素が原因です。サイズ指定のない画像、別のサイズで差し替わる Web フォント、既存コンテンツの上に差し込まれる Cookie バナーや広告など。3 つの中でいちばん安く直せて、いちばん不快に感じられる問題です。
操作の反応が重く感じる
2024 年 3 月、Interaction to Next Paint が First Input Delay に代わりました。これははるかに厳しい指標です。最初の操作だけでなく、訪問全体を通じて、操作から目に見える反応が出るまでの時間を計測します。不合格になるのは、メインスレッドを奪い合う JavaScript が多すぎるからです。
03進め方本当に順番どおりに
作業の進み方。
- 01
見積もりの前に診断
- サイトを分析し、時間がどこで使われているかを、御社へのコストの大きさと直しやすさの順に並べて文書でお送りします。ご依頼いただくかどうかに関係なく、その文書はお手元に残ります。
- 02
実ユーザーデータで基準を取る
- ラボのスコアは計測のたびに揺れます。まず Chrome UX Report の実ユーザーデータを記録し、最後に比べるのが、別々の日のラボ計測ではなく実際の訪問者が体験したものになるようにします。
- 03
大きな原因から順に直す
- 作業はステージング環境で、1 回に 1 つの変更ずつ行い、それぞれを個別に計測します。10 個の変更をまとめても、どれが効いたのかは何もわかりません。悪影響を与えた変更だけを元に戻すこともできなくなります。
- 04
検証し、方法ごとお渡しする
- 改善前後の結果、その両方を再現する手順、そして成果を少しずつ崩していくものについてのメモをお渡しします。たいていは次に誰かがインストールするプラグインです。
04よくある質問よく聞かれる質問に、率直にお答えします
ご依頼の前によく聞かれること。
キャッシュプラグインで Core Web Vitals は直りますか？
良くても一部だけです。キャッシュはサーバーの応答時間を改善するので、Time to First Byte には効果があります。しかし、大きすぎるメイン画像による Largest Contentful Paint にはほとんど効かず、サイズ指定のない要素によるレイアウトのずれにも、重い JavaScript による Interaction to Next Paint にもまったく効きません。私のもとに来るサイトの多くは、すでにキャッシュプラグインが入っているのに不合格のままです。
PageSpeed Insights のスコアが毎回変わるのはなぜですか？
上部の大きな数字は、低速な端末を模したラボテストの結果で、計測のたびに変わります。その下にある Chrome UX Report の実ユーザーデータこそ Google が実際に使うもので、実際の訪問者の 28 日間の移動平均です。実ユーザーデータを追いかけ、ラボスコアの小さな上下は気にしないでください。
改善が Google に反映されるまでどのくらいかかりますか？
実ユーザーデータは 28 日間の移動期間なので、変更が完全に反映されるまで約 4 週間を見込んでください。十分なサンプルが集まるまで時間のかかるアクセスの少ないサイトでは、さらに長くなります。すぐに順位が変わると約束する人は、意味のあるほうではなく、ラボのスコアの話をしています。
どの程度の改善を約束できますか？
見る前には何も約束できません。だからこそ、診断が先で、見積もりはその後です。プラグインが多く、メイン画像が最適化されていないサイトには、簡単に伸ばせる余地がたくさんあります。フロントエンドはすでに軽いのにデータベースで遅いサイトは、別の仕事で、別の料金です。今すぐ見栄えのいい数字を出すより、1 時間分析したあとで本当の数字をお伝えしたいと考えています。
サイトを作り直す必要がありますか？
たいていは必要ありません。速度の問題の多くは根本的な欠陥ではなく、少数の具体的な原因によるもので、それを直すほうが作り直すよりずっと安く済みます。今の作りでできることの限界に達していると判断すればそうお伝えしますが、それは例外で、私が最初にそれを勧めるのは御社の利益になりません。
INP とは何ですか？FID に代わったのですか？
2024 年 3 月、Interaction to Next Paint が First Input Delay に代わって Core Web Vitals の指標になりました。FID が計測していたのは、最初の操作をブラウザが処理し始めるまでの遅延だけでした。INP は、訪問全体を通じて、操作全体が目に見える反応を生むまでにかかった時間を計測します。合格はかなり難しく、不合格の理由はほぼ 1 つ、メインスレッド上の JavaScript が多すぎることです。
速かったサイトが遅くなりました。何が変わったのでしょう？
経験上、ほぼ必ず次の 3 つのどれかです。あとから追加されたプラグインやトラッキングスクリプト、カメラからそのままフル解像度の画像をアップロードするコンテンツ担当者、または静かに膨らんだデータベース（投稿のリビジョン、期限切れの transient、autoload のオプションテーブル）。どれも、原因がわかれば安く直せます。
次のステップ
URL を送ってください。何が問題かをお伝えします。
最初にお渡しするのは、どちらにしてもお手元に残る書面の診断です。正直な答えが「すでに問題ない」であれば、文書にはそう書きます。