ホームページが遅いと感じたら？Core Web Vitalsの基本と測定結果の読み方

「遅い」を、起きている場面に分ける

ホームページの速度を相談するとき、「全体的に重い」だけでは、どの場面を再現すればよいか分かりにくくなります。ページを開いた直後なのか、メニューを押したときなのか、読み進めている途中なのかを分けると、調査の出発点を共有できます。

GoogleのWeb Vitals解説は、利用者の体験を捉える指標として、読み込み、応答性、表示の安定性を扱っています。その中心となる指標がCore Web Vitalsです。

三つの指標は、ページのどこか一つを直せば必ず一緒に改善する、というものではありません。たとえば写真が早く表示されても、メニューを開く操作が重い可能性はあります。何を待っているのか、どんな動きが邪魔なのかを言葉にしてから測定結果を見ると、数字の意味がつかみやすくなります。

LCP・INP・CLSは、それぞれ何を見るのか

公式資料で示されている三つの指標と「良好」の目安は、次のとおりです。略語を覚えるより、どの体験に対応するかを押さえると読みやすくなります。

LCPはページ内の全画像の読み込み完了時間ではなく、INPも通信時間だけを表す指標ではありません。CLSは秒数ではないため、三つの数値をそのまま足し合わせることもできません。

Googleは、モバイルとデスクトップを分け、75パーセンタイルで目標を確認する考え方を示しています。これは値を小さい順に並べたとき、おおむね75％の位置にある値です。自分の端末で一度だけ速く表示できたことと、多くの利用者に良好な体験を届けられていることを区別するための見方です。

PageSpeed Insightsの二種類のデータを分ける

PageSpeed Insightsの公式説明によると、同ツールには実際の利用者のデータと、Lighthouseによるテスト環境のデータがあります。前者は過去28日間の体験を集計したもの、後者は条件を設定してページを読み込む診断です。

実利用データは、利用者の環境で何が起きていたかを見る材料になります。テスト環境の診断は、今のページで問題の原因を探し、修正を試す際に役立ちます。対象期間や条件が違うので、両者の数字が一致しないこと自体は不思議ではありません。

また、実利用データには、対象のページ単位のものと、サイトのオリジン単位のものがあります。オリジンは、通信方式・ホスト名・ポートの組み合わせです。表示されている範囲を確認せず、サイト全体の集計を特定ページだけの実績として扱わないようにしましょう。

修正前後は、同じページ・同じ条件で比べる

たとえば、架空のサービス紹介ページで、スマートフォンから開くと冒頭の写真が長く表示されないとします。この場合は、問題が起きたURL、端末、操作、測定した日時を一緒に残すと、開発担当者が調べやすくなります。

診断に画像に関する指摘が出たとしても、それだけで原因を確定せず、対象の画像や読み込みの流れを確認してもらうのがよいでしょう。修正後は、同じURLと測定設定で診断し、実際にページを開いたときの待ち方も見直せます。これは確認方法の仮例で、改善率を実測した事例ではありません。

変更した内容を一緒に記録すると、後から別の画像や機能を追加した際にも比較できます。写真の表示が改善した一方で、必要な説明が消えていないか、メニューやフォームが使えるかも確かめれば、数字だけでは分からない使い勝手を見落としにくくなります。

公開直後の修正は、過去28日間を含む実利用データには一度に反映されません。診断で修正を確かめたことと、公開後の利用者の体験が変わったことは、記録を分けて評価する必要があります。

まとめ

速度の測定結果を読むときは、次の三点が手がかりになります。

• 困っている場面を分ける：表示待ち、操作への反応、画面のずれを区別する。
• データの範囲を見る：実利用かテストか、ページかオリジンか、端末と期間は何かを確認する。
• 変更と結果を一緒に残す：同じ条件で比較し、実際の操作も確かめる。

まずはよく見られるページを一つ選び、困る場面を短いメモにしてから診断してみましょう。点数だけを渡すより、直したい体験を担当者と共有しやすくなります。

入力や送信の分かりやすさはフォームの見直し方、継続的な改善の費用はホームページ制作と運用の費用の比べ方で扱っています。