表示速度のチェック項目｜公開前に見る点

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。LPと計測のどちらに原因があるのか、実際の数字で切り分けます。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

表示速度のチェックでは最初に何を確認すればいいですか

表示速度を改善するときに避けたいのは、サイトを触った印象だけで「遅い」「速くなった」と判断することです。
同じページでも、端末、通信環境、アクセス地域、キャッシュの有無によって表示速度は変わります。

最初に、チェック対象となるページを決めます。
トップページだけではなく、広告の遷移先となるLP、商品ページ、問い合わせページ、記事ページなど、集客や売上に直結するページを優先します。

広告運用の観点では、広告クリック後に最初に表示されるLPを優先して確認します。
広告のCTRやCPCが良くても、LPの読み込みに時間がかかれば離脱が増え、結果としてCVRの低下やCPAの悪化につながる可能性があります。

PageSpeed Insightsで現在地を確認する

PageSpeed Insightsでは、URLを入力することでモバイルとデスクトップの状態を確認できます。
スコアだけを見るのではなく、LCP、INP、CLSなどの指標と、改善候補として表示されている項目を見ることが大切です。

スコアが80点だから問題なし、40点だから即座に全面改修、という判断は適切ではありません。
実際には、ページの役割やユーザー環境、CVへの影響まで含めて判断します。

また、一度の計測結果だけで決めないようにします。
ネットワークやサーバー状況によって結果が多少変わるため、複数回測定して大きな傾向を確認します。

実際のユーザーデータとテスト結果を分けて見る

表示速度の計測データには、実際のユーザーから集められたフィールドデータと、一定条件で機械的に測定したラボデータがあります。

フィールドデータは実態把握に向いています。
一方、ラボデータは改善箇所を特定するときに使いやすいデータです。

この2つを混同すると、「自分の端末では速いのに数値が悪い」「テストでは良いのにユーザー側では遅い」という状態を理解しにくくなります。

表示速度を確認するときの基本項目

表示速度チェックでは、まず「どのページを、誰の環境で、どの指標を使って評価するか」を決めます。
ここが曖昧なまま画像圧縮やコード改修を始めると、効果の小さい作業に時間を使いやすくなります。

LCPはどのようにチェックすればいいですか

LCPはLargest Contentful Paintの略で、ユーザーがページを開いたときに主要なコンテンツが表示されるまでの速さを見る指標です。

広告LPでは、ファーストビューに大きな画像や動画を置くケースが多いため、LCPが悪化しやすくなります。

たとえば、ファーストビューの画像ファイルが必要以上に大きい場合、ブラウザが画像を取得して表示するまでに時間がかかります。
画像そのものだけではなく、画像を取得する前にCSSやJavaScriptの処理を待っている場合もあります。

LCPの対象になっている要素を特定する

最初に確認したいのは、何がLCPの対象になっているかです。
ファーストビューのメイン画像であることもあれば、大きなテキストブロックや商品画像になっている場合もあります。

対象を特定せずにサイト全体の画像を一括圧縮しても、肝心のLCP改善につながらないことがあります。

ブラウザの開発者ツールや計測ツールの診断結果を使い、どの要素がLCPとして判定されているかを確認します。

ファーストビュー画像の容量と形式を見る

LCP対象が画像の場合、画像サイズと画像形式を確認します。
PC用の大きな画像をそのままスマートフォンにも配信していると、必要以上の通信量が発生します。

表示幅が数百ピクセルしかないのに、数千ピクセルの画像を読み込んでいるケースもあります。
この場合、端末に合わせた画像サイズを用意することで軽量化できます。

WebPやAVIFなど、圧縮効率の高い形式を利用できるかも確認します。
ただし、単純に画質を落とせばよいわけではありません。

広告LPでは、商品の質感やブランドイメージを伝える画像がCVに影響することがあります。
表示速度とクリエイティブ品質の両方を見ながら調整します。

LCP対象を遅延読み込みしていないか確認する

画面下部にある画像を遅延読み込みすることは有効ですが、ファーストビューの主要画像まで遅延読み込みすると、表示がかえって遅くなることがあります。

ページを開いてすぐ必要になる画像と、スクロールしないと見えない画像を分けて設定します。

画像をすべて同じルールで処理するのではなく、表示位置によって読み込み方法を変えることが必要です。

INPはどのように確認すればいいですか

ページが見た目上は表示されていても、ボタンを押したときの反応が遅ければユーザー体験は悪化します。

INPはInteraction to Next Paintの略で、クリック、タップ、キーボード入力などの操作に対して画面がどれだけ素早く反応するかを見る指標です。

広告LPでは、CTAボタン、フォーム入力、アコーディオン、モーダル、商品選択などの操作に影響します。

ボタン操作の反応速度を見る

CTAをタップした直後に反応せず、少し待ってから画面が切り替わる場合、ユーザーは「押せていない」と感じることがあります。

その結果、同じボタンを何度も押したり、ページから離脱したりする可能性があります。

実機でLPを開き、CTA、フォーム、メニューなど主要な操作を確認します。
計測ツールの数値だけではなく、ユーザーが実際に行う操作を一通り試すことが必要です。

JavaScriptが長時間処理されていないか確認する

INP悪化の原因として多いのがJavaScriptです。
大量のスクリプトがメインスレッドを占有すると、ユーザーが操作してもブラウザがすぐに処理できません。

計測タグ、チャットツール、ヒートマップ、ABテストツール、接客ツールなどを追加しているサイトでは特に注意が必要です。

マーケティング施策を増やすほどタグが増えやすいため、表示速度をチェックするときは「現在使っているタグか」まで確認します。

過去の施策で導入したタグが残り続けているケースもあります。
タグマネージャー内を整理し、利用していないスクリプトを削除できるか確認します。

操作速度が遅いときに確認する項目

表示速度チェックでは、ページが何秒で見えたかだけでは不十分です。
「表示されたあとに問題なく操作できるか」まで確認することで、CV導線上の問題を見つけやすくなります。

CLSはどのようにチェックすればいいですか

CLSはCumulative Layout Shiftの略で、ページ表示中にレイアウトがどれくらい動いたかを見る指標です。

ユーザーがCTAを押そうとした瞬間に画像が読み込まれ、ボタンの位置が下へずれるような状態が典型例です。

ページ自体の読み込み時間が短くても、レイアウトが頻繁に動けば使いにくいサイトになります。

画像や動画の表示領域が確保されているか確認する

画像の横幅と高さが事前に指定されていないと、画像が読み込まれたタイミングでスペースが追加されることがあります。

その結果、それより下の文章やボタンが押し下げられます。

画像や動画の表示領域をあらかじめ確保しておけば、コンテンツ読み込み前後の位置変化を抑えられます。

LP制作では、PCでは問題なくてもスマートフォンだけ画像比率が変わり、レイアウトが動くことがあります。
実機またはモバイル表示で確認します。

後から挿入される要素を確認する

Cookie同意バナー、キャンペーン告知、チャットボタン、広告枠などがページ読み込み後に追加されることがあります。

これらが既存コンテンツを押し下げる構造になっていると、CLSが悪化します。

画面上に重ねて表示するのか、あらかじめスペースを確保するのかを設計段階で決める必要があります。

Webフォントによる文字ずれを見る

Webフォントの読み込み前後で文字サイズや文字幅が変わると、文章の改行位置が変わり、レイアウトが動くことがあります。

ブランド指定のフォントを使っているページでは確認しておきたい項目です。

読み込み速度だけを改善しても、ページ上の要素が動き続ければユーザー体験は改善しません。
表示の速さと表示の安定性は別々に確認します。

画像はどこまでチェックすればいいですか

画像は、Webページのデータ容量の中で大きな割合を占めやすい要素です。

特にECサイト、美容、住宅、人材、飲食、旅行など、ビジュアルを多く使用するサイトでは、画像の確認を優先します。

画像容量を確認する

まず各画像のファイルサイズを確認します。

数MBの画像が複数配置されていると、スマートフォン回線では読み込み負荷が大きくなります。

制作会社から納品された高解像度画像を、そのままCMSにアップロードしているケースもあります。
Web上で実際に表示されるサイズに合わせて調整します。

ただし、「画像は何KB以下なら正解」という一律の基準で判断する必要はありません。
画面いっぱいに表示するメインビジュアルと、小さなアイコンでは必要な画質が異なるためです。

表示サイズより大きすぎる画像を使っていないか確認する

たとえば説明のための仮の値として、スマートフォン上で横幅390ピクセル程度しか表示しない画像に、横幅3000ピクセルの画像を配信しているとします。

この場合、必要以上に大きなデータをユーザーへ送っている可能性があります。

画面サイズに応じて適切な画像を配信するレスポンシブ画像の設定も確認します。

ファーストビュー以外は遅延読み込みを検討する

記事やLPの後半にある画像は、ページを開いた瞬間にすべて読み込む必要がない場合があります。

スクロールして表示領域に近づいた段階で読み込む遅延読み込みを使えば、初期表示を軽くできます。

一方、ファーストビュー画像まで遅延読み込みするとLCPが悪化する場合があります。

画像のチェックでは、「軽くする」だけではなく「いつ読み込むか」まで確認します。

CSSとJavaScriptは何をチェックすればいいですか

画像を軽量化しても表示速度が改善しない場合、CSSやJavaScriptがボトルネックになっている可能性があります。

ブラウザはHTMLを受け取ったあと、CSSやJavaScriptを読み込みながらページを描画します。
この処理を止めるコードが多いと、画面表示までに時間がかかります。

初期表示を妨げているファイルを確認する

計測ツールでは、レンダリングを妨げるリソースとしてCSSやJavaScriptが指摘されることがあります。

ファーストビューを表示するために必要なコードと、あとから読み込んでも問題ないコードを分けられるか確認します。

たとえば、ページ下部のアニメーションにしか使わないJavaScriptを最初から読み込む必要がない場合があります。

未使用のコードが残っていないかを見る

CMSでは、プラグインを追加するほどCSSやJavaScriptも増えやすくなります。

以前使っていた機能を削除しても、コードだけ残っている場合があります。

LP制作でも、テンプレートをコピーしながら制作を続けることで、使われていないCSSが蓄積することがあります。

未使用コードは、ページの見た目には影響しなくても読み込み負荷になります。

外部スクリプトも含めて確認する

自社サイト内のコードだけでなく、外部サービスから読み込むJavaScriptもチェックします。

広告計測、アクセス解析、チャット、ヒートマップ、動画埋め込み、SNSウィジェットなどが代表例です。

マーケティング担当者にとって注意したいのは、施策ごとにツールを導入した結果、ページが徐々に重くなることです。

新しいツールを入れるときは機能面だけではなく、表示速度への影響も確認します。

CSSとJavaScriptの確認項目

フロントエンドの改修は、サイトの動作不具合につながる可能性があります。
削除や読み込み順序の変更を行う場合は、ステージング環境などで表示と計測の両方を確認してから反映します。

サーバーとTTFBはどのように確認すればいいですか

ページ表示の開始そのものが遅い場合、フロント側ではなくサーバー側に原因があることがあります。

TTFBはTime to First Byteの略で、ユーザーがページへアクセスしてからサーバーから最初のデータが返されるまでの時間を示します。

TTFBが長い状態では、その後の画像やCSSをどれだけ軽くしても、ページ表示開始までの待ち時間が残ります。

サーバーの応答速度を確認する

共有サーバーや低スペックの環境では、アクセス集中時に応答が遅くなることがあります。

普段は問題なくても、広告配信を増やしたタイミングやキャンペーン開始時だけ遅くなるケースがあります。

広告予算を大きく増額する場合は、LPだけではなくインフラ側の耐久性も確認します。

CMSやデータベース処理を見る

CMSでは、ページを生成する際にデータベース処理が発生します。

プラグインが多い、複雑な検索処理を行っている、データ量が増えているといった状況では、サーバーの応答に時間がかかることがあります。

静的ページとCMSページで速度差が大きい場合は、CMS側の処理も疑います。

キャッシュが効いているか確認する

毎回同じページをゼロから生成するより、生成済みのデータをキャッシュして配信したほうが高速化できる場合があります。

ブラウザキャッシュ、ページキャッシュ、CDNなど複数の方法があります。

ただし、フォームや会員ページなど動的な情報を扱うページでは、キャッシュ設計を誤ると不具合につながります。

サーバー側の改善は、サイト構成やCMSによって対応方法が異なります。
制作会社やエンジニアへ依頼するときは、「サイトが遅い」だけではなくTTFBなどの測定値を共有したほうが原因を特定しやすくなります。

改善後の表示速度はどのように確認すればいいですか

表示速度改善では、作業を実施した時点で終わりにしないことが大切です。

改善前と改善後で同じ条件を使い、LCP、INP、CLS、TTFBなどがどのように変化したかを確認します。

ページや測定条件が異なると比較が難しくなるため、対象URL、端末条件、測定方法をそろえます。

改善前の数値を保存する

改善前の計測結果や主要指標を保存しておきます。

改修後に数字を見ても、以前の状態が分からなければ効果を判断できません。

制作会社や開発会社に依頼する場合も、改修前後を同じ形式で記録すると改善内容を評価しやすくなります。

CVRや離脱率も確認する

表示速度は目的ではなく、ユーザーがストレスなくページを閲覧し、問い合わせや購入につながりやすい状態を作るための手段です。

そのため、速度改善後はアクセス解析や広告データも確認します。

たとえば説明のための仮の値として、改善前のLPのCVRが2.0％、改善後が2.4％になったとします。

この数字だけで表示速度改善が原因だと断定することはできません。
同期間に広告クリエイティブ、配信ターゲット、価格、キャンペーン内容などが変わっていないかも確認する必要があります。

スコアを上げること自体を目的にしない

計測ツールのスコアを上げることだけを目的にすると、ユーザーや事業に必要な機能まで削ってしまうことがあります。

たとえば動画を削除すれば軽くなる場合でも、その動画が商品の理解やCVに貢献しているなら、削除以外の方法を考える必要があります。

必要なコンテンツを保ちながら読み込み方法を変える、画像を軽量化する、不要なタグだけを削除するなど、事業への影響を考えて対応します。

表示速度のチェックは一度実施すれば終わりではありません。

新しい画像、計測タグ、チャットツール、CMS機能などを追加するたびにページは重くなる可能性があります。
LPのリニューアル時や広告出稿前、サイト機能追加後などに定期的に確認できる運用を作っておくと、速度低下を早い段階で発見できます。

よくある質問

まとめ