作成：IILL Editorial · URL・端末・ネットワーク・リリースを記録して結果を比較してください。
「スマートフォンで遅い」という感想だけでは、直す順番を決められません。同じURLを 同じ端末とネットワーク条件で開き、**主要コンテンツが表示されるまで（LCP）、操作に 反応するまで（INP）、読みながらレイアウトが動くか（CLS）**を分けて記録します。これらは 問題を見つける指標であり、検索順位や問い合わせ数を保証する点数ではありません。
三つの指標を別の問題として読む
| 指標 | 確認すること | 最初に見る場所 |
|---|---|---|
| LCP | ファーストビューの主要コンテンツはいつ見えるか | ヒーロー画像、サーバー応答、CSS・フォント |
| INP | メニューやフォームを押したあといつ反応するか | 長いJavaScript処理、イベント、外部スクリプト |
| CLS | 読んでいる途中で画面が動かないか | サイズのない画像、後から出るバナー、フォント交換 |
web.devのCore Web Vitals解説は、各指標が異なる ユーザー体験を表すと説明しています。LCPだけを下げても、問い合わせフォームが動かなければ サイトの目的は達成できません。
測定条件を先に固定する
公開前後を比較するなら、次の値を残します。
- 最終URLとリダイレクト
- 端末、ブラウザー、viewport
- ネットワーク・キャッシュ状態と測定時刻
- デプロイのcommitまたはassetのバージョン
- ログイン、パーソナライズ、広告、外部ウィジェットの有無
一回のLighthouse結果を顧客事例の平均のように書かないでください。同じ条件で確認し、 どの変更のあとに値が変わったのかを残します。
公開前のモバイル確認手順
1. ファーストビューで一番大きい要素を見る
大きすぎるヒーロー画像や、画面下のカルーセルを先に読み込んでいないか確認します。 画像の表示サイズと形式を指定し、下のメディアは安全な範囲で遅延読み込みにします。 LCPの最適化ガイドを原因の確認に使い、 最後はサイトの実際のHTMLと応答で判断します。
2. 指で操作する
メニュー、FAQ、フォームの入力、入力エラーをスマートフォンで実行します。イベントが 計測されたことと画面が素早く反応することは別です。INPが悪い場合は長いJavaScript処理や、 不要な計測・チャット・アニメーションを分けて原因を絞ります。
3. 画面が動く瞬間を探す
画像・動画・バナーの領域を先に確保し、フォント交換で見出しやCTAが押し下げられないか 確認します。スコアのために重要な情報を隠すのではなく、領域と表示順を安定させます。
4. 速度と問い合わせを同時に試す
速いページでもフォームが送信できなければ役に立ちません。CTA、フォーム開始、入力エラー、 成功、失敗を一度ずつ実行し、サーバーが受け付けた成功だけを主要コンバージョンにします。 計測の定義はランディングページのGA4ガイドに つなげて確認します。
公開後に見るタイミング
初日はcanonical URL、モバイルメニュー、フォーム通知、404とリダイレクトを確認します。 一週目は公開されたassetと外部script、Search ConsoleのインデックスとCore Web Vitalsの 警告を確認します。28日後に検索からの訪問とGA4の有効な問い合わせ完了を別々に比較します。 一度に一つの変更を公開し、観測期間を残してください。
公開前チェックリスト
- URL、端末、viewport、ネットワーク、リリース版を記録した。
- 同じ条件でLCP・INP・CLSを比較した。
- ヒーロー画像とフォントが最初の有用な表示を妨げない。
- メニュー、フォーム、エラー、成功状態をモバイルで試した。
- 画像・バナー・フォントでレイアウトがずれない。
- 問い合わせ成功イベントが個人情報なしで一度だけ送られる。
- canonical、sitemap、robots、title、descriptionが画面と一致する。
- ひとつのスコアを順位や成果の保証として書いていない。
ホームページ制作の期間ガイドで公開までの依存関係を、 保守範囲ガイドで公開後の担当範囲を確認できます。
Webサイト制作、何から決めるべきか迷っていませんか？
現在の状況と必要な成果を伺い、制作範囲と次のステップを先に整理します。