広告から開いたLPの画像がなかなか出ない。制作担当に「軽くしてください」と頼みたいものの、どこをどう直すか説明できない。この場面では、PageSpeed Insightsで対象URLを調べ、遅く見える症状と診断結果を組にして渡すと依頼が具体的になります。

最初に見るのは総合点の高低だけではありません。広告のリンク先URLとモバイル・PCの条件をそろえ、実際の訪問者のデータと、テスト環境での診断を分けます。そのうえで、冒頭の画像が遅いのか、ボタンを押しても反応が遅いのかなど、利用者が困る箇所に対応する修正を選びます。

広告で使っているURLを、そのまま診断対象にする

LPは広告から訪れた人が最初に読むページです。会社のトップページが速くても、広告専用のページだけ重い場合があります。まず管理している広告の最終的なリンク先を開き、実際に表示されるページを確認します。途中で別のページへ移動する場合は、最初に指定したURLと移動先を制作担当へ伝えます。

PageSpeed Insightsへ対象URLを入力して分析し、主に来訪する端末に合わせてモバイルまたはパソコンの結果を読みます。スマートフォンからの広告流入を改善したいなら、最初からパソコンのスコアだけで判断しないことが大切です。

同時に実際のスマートフォンでも、ページを開く、冒頭を読む、申込ボタンへ進むという一連の流れを試します。「遅い」という感想を「見出しは出るが画像がしばらく空白」「入力欄を押した後の反応が遅い」と分けると、診断と対応づけやすくなります。一台の感想だけで全訪問者が同じ状態と断定せず、問題を再現する手がかりとして使います。

実ユーザーの28日間と、その場のテストを混ぜない

Google公式の説明では、PageSpeed Insightsはフィールドデータとラボデータを提供します。フィールドデータは実際の訪問者による直近28日間の集計、ラボデータは条件を決めた環境でページを読み込む診断です。前者は実際の体験、後者は問題の調査に役立ちます。

ここで、結果が「このURL」のものか、オリジン全体のものかを確かめます。オリジンとは、同じプロトコル・ホスト名・ポートでまとまるサイトの範囲です。対象ページのデータが足りない場合、サイト全体のデータへ切り替わることがあります。さらに全体も不足すると、実ユーザーデータは表示されません。

新しいLPで実測が出ないことは、問題がない証明でも、アクセスがゼロという意味でもありません。その場合はラボ診断と実機での操作から、修正候補を絞れます。一方、オリジン全体の良好な評価を、そのLPだけの良好な評価として制作担当へ渡さないでください。

修正した直後に実ユーザーの評価が変わらなくても、失敗と判断するのは早すぎます。28日間の中には修正前の閲覧も含まれます。公開後すぐの確認には再診断と実機操作を使い、実測の変化は期間が進んでから評価します。

数字を、利用者が困っている場面へ置き換える

LCPは、表示領域の大きな画像や文章が表示されるまでの時間を捉える指標です。冒頭の主要な画像が長く空白になるなら、LCPとその対象要素、診断で指摘されたリソースを一緒に見ます。ただし、LCPが悪い原因を画像の容量だけに決めつけず、診断結果を制作担当に確認してもらいます。

INPはクリックや入力などへの応答、CLSは予期しないレイアウトのずれに関わります。「申込を押そうとしたら位置が動いた」「操作しても反応したか分からない」といった症状は、単に画像が出るまでの時間とは別の問題です。専門用語を全部覚えるより、どの場面で困ったかを説明できる方が依頼には役立ちます。

総合点が低いと、すべての提案を一度に適用したくなります。しかし、広告の計測や申込フォームに必要な処理まで削れば、目的を果たせなくなります。診断は改善候補を探す道具です。変更の必要性と影響範囲を判断する作業は残ります。

制作担当へ渡す依頼を、症状と完了条件で書く

説明用の仮例として、冒頭画像の表示待ちが長く、診断でも画像に関する改善候補が出た場合を考えます。次のように伝えると、点数だけを上げる依頼から一歩進められます。

「広告で使用中の対象LPをモバイルで開くと、冒頭画像の表示を待つ状態になります。診断結果のLCP対象と画像関連の指摘を添付します。画像が原因かを調べ、必要なら表示サイズに合う画像への変更や圧縮を提案してください。修正後は同じURL・端末条件で再診断し、画像内の文字の読みやすさと申込フォームの正常動作も確かめたいです。」

この例は特定サイトで確認した障害や実績ではありません。画像が原因候補にないなら、同じ依頼文を使わず、実際の症状に置き換えます。画像の圧縮を頼む場合も、読めない品質まで落とすことは避けます。広告の訴求を理解するために必要な写真や説明を、容量削減だけのために消すのも適切ではありません。

添付するのはURL、確認した端末条件、診断日時、問題が出る操作、該当結果です。担当者が同じ症状を追える形にしておくと、原因調査と修正案の相談が進みます。変更前後を比べたいなら、別のLPへの差し替えや訴求変更も同時に行わない方が、結果を読み取りやすくなります。

速くなったことと、問い合わせが増えたことを分ける

公開直後は、同じURLと端末区分で再診断し、実機でも広告からページ、申込までの流れを試します。スコアの一回の上下だけを追うのではなく、もともとの空白や操作の遅れが解消したかを確認します。診断時の条件による変動もあるため、条件をそろえて見直すことが必要です。

問い合わせへの影響は、通常の比較期間で、流入元や広告内容が大きく変わっていないかも含めて評価します。表示が速くなったことは、相談したくなる情報が十分になったこととは別です。速度の改善だけで問い合わせ増加や検索順位の上昇を約束することはできません。

ページは読めるのに申込へ進まない場合は、広告とLPの期待のずれを直す方法が次の確認先です。成果の数字そのものに疑問がある場合は、コンバージョンの二重計上を直す手順で計測の問題を切り分けます。

本記事は2026年9月26日に実読したPageSpeed Insightsの公式説明をもとに、広告担当者から制作担当への依頼方法を整理したものです。個別LPの実測や、修正による成果検証を報告する記事ではありません。