自社サイトの表示が遅いと感じたとき、測定ツールの点数だけで改善内容を決めようとしていませんか?企業サイトの速度改善は、訪問者が待つ場面を確かめ、表示・操作・画面のずれに分けて進めると、担当者が変更範囲を判断しやすくなります。
この記事では、ページ速度の測定結果の読み方と、自社の利用場面に合う改善の優先順位について取り上げます。画像や読み込み処理の見直し方、変更後の確認手順、社内と制作会社の分担もお伝えします。
この記事でわかること
表示・操作・画面のずれを分ける速度改善の考え方
訪問者の端末と利用場面に応じた改善の優先順位
症状と原因に対応した改善方法の比較と想定例
測定から変更後の再確認までの手順と社内の役割
速度改善で起きやすい問題の予防と修正方法
変更範囲と検証体制に応じた内製・外注の分担
目次
ページ速度は、表示・操作・画面のずれを分けて改善 改善の優先順位は、訪問者の端末と利用場面で判断 症状と原因を対応させる改善例と比較 測定から再確認までの進め方と社内の役割 速度改善で起きやすい問題と修正方法 内製と外注は、変更範囲と検証できる体制で分担 まとめ この記事からわかるQ&A 引用・参考資料
ページ速度は、表示・操作・画面のずれを分けて改善
企業サイトの速度改善では、担当者が「内容が見えるまで」「操作後に反応するまで」「表示中に内容が動く場面」を分けて確認します。それぞれの原因が異なるため、総合点を上げることだけを目標にすると、担当者は改善対象を選びにくくなります。
Core Web Vitalsで確認する3つの状態
Core Web Vitalsは、読み込み・操作への応答・画面の安定性を測る指標です。Google「About PageSpeed Insights」(2024年10月更新)では、次の基準と、実際の利用データによる判定方法を説明しています。
指標 測る状態 良好の基準 LCP(Largest Contentful Paint) 画面内の最も大きな画像や文章が表示されるまでの時間 2.5秒以下 INP(Interaction to Next Paint) クリックやタップなどの操作から、次の画面描画までの応答時間 200ミリ秒以下 CLS(Cumulative Layout Shift) 予期しない画面のずれの大きさ 0.1以下
実利用データの判定には、測定値を小さい順に並べた75%の位置の値を使います。この値は、平均値や担当者の一度の体験とは異なる方法で求めた結果です。担当者はモバイルとパソコンの結果を分け、端末ごとの問題を整理できます。
検索順位との関係は公式説明の範囲で把握
SEOは、検索エンジンが内容を把握しやすいように整える取り組みです。GoogleはCore Web Vitalsをランキングシステムで使用すると説明しています(Google検索セントラル、2026年9月更新)。同時に、良好な結果でも上位表示は保証しないと明記しています。
たとえば、大きな画像の表示待ちがある場合、担当者はその画像の容量と読み込み方から調べます。操作への反応が遅い場合は、操作時の処理を調査対象に含めます。改善後の問い合わせ増加や順位上昇については、担当者は速度の数値だけでは判断しません。
改善の優先順位は、訪問者の端末と利用場面で判断
担当者は、訪問者が使う端末、よく見るページ、そこで行う操作を整理してから改善対象を選びます。企業紹介を読む場面と問い合わせを送る場面では、確認する内容が異なります。問題の大きさに加え、利用場面への影響と変更の範囲も判断に含めてください。
スマートフォンで情報を探す訪問者が多い場合
スマートフォンからサービスや商品を調べる人が多い場合、担当者はモバイルの測定結果と実機での操作を先に確かめます。社内のパソコンだけで確認すると、担当者は訪問者と異なる条件で判断する場合があります。
確認対象には、検索から訪れるページ、サービスの説明、問い合わせまでの移動を含めます。文字が読めるまでの時間と、メニューを開いたあとの反応を別々に記録すると、制作会社にも症状を説明しやすくなります。
一方、利用者が主にパソコンで資料や商品情報を確認する企業では、その利用場面から着手する選択もあります。端末の比率を一般論で決める必要はありません。担当者が自社で把握している利用状況を判断材料にします。
問い合わせや購入の途中で待ち時間がある場合
問い合わせや購入を増やしたい場合は、訪問者が入力・選択・送信する場面を優先して確認します。最初の表示が速くても、ボタンを押したあとの反応が遅ければ、担当者は操作処理の調査を依頼する候補にできます。
ここでは、送信処理そのものの時間と、画面が反応するまでの時間を区別します。入力エラーの表示や選択項目の切り替えなど、待ち時間が発生した操作まで記録してください。単に「フォームが遅い」と伝えるより調査範囲を絞れます。
同じ症状が複数のページで発生する場合
複数のページで似た遅さがある場合、担当者は共通の画像設定や読み込み処理から調べます。特定のページだけに問題がある場合は、そのページ固有の画像や埋め込み内容を調査対象に含めます。
新規制作では、担当者と制作会社が代表ページの確認条件を先に共有します。公開中のサイトでは、両者が問題のあるページと正常なページを比較し、影響範囲を整理して調査対象を絞ります。どちらの場合も、この確認を終えるまで、両者はすべてを一度に変更しません。
症状と原因を対応させる改善例と比較
画像の圧縮、操作処理の見直し、表示領域の確保は、それぞれ対象が異なります。担当者と技術担当者は、確認した症状と調べた原因を対応させて改善方法を選びます。以下は、症状と改善方針の関係を説明するために想定した例です。成果や改善率を示す実績とは区別します。
大きな画像の表示が遅い企業紹介ページ
前提として、ページを開いたあとに企業紹介の大きな画像が遅れて表示され、本文は先に読める状態を想定します。担当者は画像の容量と画質を確認し、制作会社はその画像がLCPの対象か、読み込み開始が遅れているかを調べます。
担当者と制作会社は、表示に合う画像サイズと形式を比較し、対象画像を早く読み込み始める設定を検討します。参考資料は、Googleのweb.dev「The most effective ways to improve Core Web Vitals」(2024年10月更新)です。Googleはこの資料で、LCP画像の発見と読み込み優先度を改善項目に挙げています。
画像を軽くしても改善が小さい場合は、制作会社が読み込み開始までの待ち時間も確認します。同じ構成を使う商品紹介ページにも、この調べ方を応用できます。担当者は写真の見え方を確かめ、技術担当者は測定値を比較する分担です。
ボタンを押したあとの反応が遅いページ
ここでは、画像や文章を表示したあと、メニューを開く操作や入力項目の変更に時間がかかる例を取り上げます。制作会社は、画面の動作を制御するJavaScriptのプログラムを調べ、操作と同時に重い処理が実行されていないか確かめます。
制作会社は、処理に時間がかかることで利用者が操作への反応を待たされる場合に、不要な処理を減らして長い処理を分割します。web.devも、INP改善の方法として不要なJavaScriptの削減と長い処理の分割を説明しています。
担当者は、どのボタンや入力で遅さを感じたかを再現手順にまとめます。この方針は問い合わせフォームにも応用できますが、処理を変更したあとは入力確認と送信テストを行います。表示の測定だけでは、変更後の機能を確認しきれません。
症状ごとに選ぶ改善方法
確認した症状 主な調査対象 改善の方針 変更後の確認 大きな画像の表示が遅い 画像の容量、寸法、読み込み開始時期 画像の調整と読み込み順の見直し 画質とLCP ボタンや入力への反応が遅い 操作時の処理、外部サービスの処理 不要な処理の削減、処理の分割 操作の反応と機能 画像表示後に文章が動く 画像や埋め込み内容の表示領域 読み込み前に領域を確保 CLSと実際の画面 最初の表示まで全体が待たされる サーバー応答、ページ生成、配信方法 キャッシュや配信設定の検討 応答時間と更新内容
キャッシュは、取得・生成したデータを保存して再利用する仕組みです。CDNは複数の配信拠点からデータを配信する仕組みで、サーバー応答が原因の場合に、制作会社はキャッシュとともに検討します。web.devも、応答時間の改善策としてキャッシュとCDNを挙げています。
担当者は症状と測定結果を共有し、技術担当者が原因を確認したあとに変更対象を選びます。「画像を変える」「サーバーを変更する」と手段から決める場合より不要な作業を避けやすく、外部サービスの処理が原因なら、担当者は利用目的も社内で確かめます。
測定から再確認までの進め方と社内の役割
担当者は、代表ページの選定、測定、実際の操作、変更後の再測定を同じ記録にまとめます。点数の画像に加え、URL、端末、発生した操作、測定日時も共有すると、担当者と制作会社は調査と確認の範囲を合わせやすくなります。
工程1:対象ページと担当者を決定
最初に、担当者がトップページ、主要なサービスページ、問い合わせページなど、利用場面の異なるページを選びます。問題が一部に限られる場合は、症状のあるページと比較用のページを含めます。すべてのURLを最初から詳しく調べる必要はありません。
社内では、Web担当者が記録をまとめ、営業や問い合わせ対応の担当者が確認する操作を補足します。その記録をもとに、制作会社または社内の技術担当者が技術変更を進めます。ただし、判断者と作業者を分ける場合、作業者は判断者が承認する範囲を決めるまで変更に着手しません。
工程2:PageSpeed Insightsで測定
PageSpeed Insightsは、Googleが提供するページの性能測定ツールです。担当者は測定するURLを入力し、モバイルとパソコンの結果を保存します。Googleの公式説明では、実利用データと試験環境でのデータを使うとしています(2024年10月更新)。
実利用データは、過去28日間の利用状況を集計した結果です。ページのデータが足りない場合は、サイト全体に相当する集計が表示されることもあります。担当者は、結果が入力したページを示しているか、より広い範囲の集計かを確認してください。
試験環境のデータは、一定の条件で読み込みを試した結果です。担当者は原因の調査に使えますが、実際の訪問者全員の体験を示していません。通常のLighthouseの読み込みテストではINPを測らないため、担当者は実利用データと指標の違いを確認します。
工程3:操作確認と改善対象の選定
担当者は実際の端末でもページを開き、メニュー、入力、送信などを試します。測定結果と操作時の症状を合わせて、制作会社と変更対象を選びます。同じ条件で複数回測定し、一度の点数の増減で結論を出さない進め方です。
Google Search Consoleは、検索状況などを確認するGoogleのツールです。サイト内のCore Web Vitalsを確認する際に使えます。詳細な読み込み調査は、技術担当者がLighthouseやGTmetrixを補助的に使う範囲とします。
工程4:変更後の再測定と機能確認
変更後は、Web担当者が同じURLと条件で再測定し、画質、表示のずれ、メニュー、フォーム送信も確かめます。記録には変更内容と公開日時を加え、測定値の改善と機能の維持を分けて評価します。
実利用データには変更前の期間も含まれるため、担当者は試験環境の結果で公開直後の状態を確かめ、その後は新旧の状態が混在する実利用データを追います。画像や外部サービスを追加したあとも、担当者は代表ページを再確認します。
速度改善で起きやすい問題と修正方法
速度改善では、担当者と技術担当者が測定値と実際の表示・操作をセットで確かめます。両者は画像の見え方や必要な処理を維持できるように変更範囲を絞り、問題が出た場合に戻せる手順も共有します。
画像を軽くしたあとに文字や製品の細部が読めない場合
強い圧縮や過度な縮小によって訪問者が製品の細部や画像内の文字を確認しにくくならないか、担当者は変更前の画像を保存して変更後の画像と見比べます。使用する画面サイズで問題が出た場合は、担当者が圧縮の程度や寸法を調整します。
WebPは画像形式の一つですが、変換による容量の変化は画像と設定によって異なります。形式名だけで選ばず、担当者が容量と画質を比較してください。拡大して確認する用途がある場合は、その利用場面も制作会社に伝えます。
最初の大きな画像まで遅延読み込みした場合
遅延読み込みは、必要な時期に画像などを読み込む方法です。制作会社は画面の下にある画像への適用を検討し、最初に表示する大きな画像とは対象を分けます。最初の大きな画像まで対象にすると、その画像の読み込み開始が遅れる場合があります。
web.devは、LCP画像から遅延読み込みの設定を外すことを改善策に挙げています(2024年10月更新)。制作会社は画像ごとに設定を分け、担当者は初期表示の見え方と測定結果を変更前後で比較します。
画像や埋め込み内容の表示後に文章が動く場合
画像や動画の表示後に周囲の内容が動くのを防ぐため、制作会社は幅・高さや縦横比を指定し、読み込み前に表示領域を確保します。web.devも、画像や埋め込み内容のサイズ指定をCLS改善策として説明しています。
担当者はページを開いてから表示が落ち着くまでを観察し、押そうとしたボタンが動かないかも確かめます。修正後に別の画面幅で崩れた場合は、技術担当者が領域の指定を調整します。測定値が良好な場合も、担当者はこの操作確認を省きません。
処理の削除やキャッシュ変更で動作が変わった場合
外部サービスの処理を削除する前に、担当者が用途と利用部署を確認します。フォームや計測に関係する処理なら、技術担当者が影響範囲を調べる順番です。変更後に動作が変わった場合は、変更を戻して原因を切り分けます。
キャッシュを変更する際は、担当者が更新内容の表示と速度を別々に確かめます。古い内容が残る場合、制作会社は更新時の保存データの扱いを見直し、速度と内容の鮮度の両方を満たす設定を選びます。
内製と外注は、変更範囲と検証できる体制で分担
担当者は内製か外注かを一括で決める前に、作業ごとの権限と確認体制を整理し、社内で安全に変更できる画像や掲載内容は内製で進めます。プログラム、共通の表示設定、サーバーやキャッシュの変更は、影響を調べて検証できる担当者に任せます。
社内で進める範囲
Web担当者は、対象URLの選定、測定結果の保存、操作の再現手順、画像の画質確認を担えます。CMSという掲載内容を管理・更新する仕組みで画像を差し替える場合は、担当者が変更前の素材と設定を残してから作業します。
複数ページに影響する設定を画像の差し替えとともに変える場合、担当者は技術担当者に影響範囲を尋ねます。更新権限がある場合も、担当者は技術設定を変更できる範囲を別途確認し、安全に戻せるか、変更後の確認方法を把握しているかを内製で進める前に確かめます。
技術担当者や制作会社に任せる範囲
操作処理、共通の表示構成、配信設定などは、制作会社または社内の技術担当者が調べます。原因が分からない場合、担当者は調査と改善案の提示を先に依頼し、その結果から原因と変更範囲を把握します。サイト全体を作り直すかどうかは、担当者がこれらを確認するまで決めません。
担当者は依頼時に、対象ページと具体的な症状を記載します。制作会社から原因、変更案、影響する機能の説明を受けたあと、担当者が依頼する作業を決めます。特定のツールを導入するかどうかは、依頼前に決める必要はありません。
速度改善の依頼で確認する項目
費用は調査の深さ、共通部分への変更、検証対象によって変わるため、担当者は見積もりで対象ページと端末、変更する設定、機能テスト、再測定の範囲を確かめます。そのうえで、担当者は金額と各見積もりに含まれる作業を比較します。
完了条件には、比較する測定結果と、維持する機能を含めます。実利用データの経過確認まで依頼するかも共有してください。制作会社が点数や成果を保証する形より、担当者が変更内容と確認結果を受け取れる範囲で合意すると、社内でも判断しやすくなります。
まとめ
次の作業を決める際は、担当者が代表ページのURL、端末別の測定結果、待ち時間が発生する操作を一枚の記録にまとめます。画像の表示待ちか、操作への反応か、画面のずれかを整理すると、技術担当者に調査範囲を示しやすくなります。
改善の優先順位は、訪問者の利用場面と問題の広がりによって変わります。特定ページの素材を調整する範囲なら社内で進める選択があり、複数ページの共通設定に影響する場合は技術担当者と検証範囲を合わせます。
着手前には、変更前の記録、戻す方法、変更後に試す操作を確認してください。測定値と実際の利用を比較し、次の変更を判断できる状態までを一つの作業として扱います。
この記事からわかるQ&A
PageSpeed Insightsは100点を目指す必要がありますか?
担当者は、100点を目指すかどうかをSEO以外の目的も含めて判断します。Googleは、SEOだけを理由に満点を目指しても、時間を最も有効に使えるとは限らないと説明しています(Google検索セントラル、2026年9月更新)。試験環境の点数が良好でも、実際の訪問者の状態は異なる場合があります。担当者は問題のある操作、対象ページ、改善後に確認する指標を決め、実際の利用時にも確かめます。
実利用データが表示されないサイトは、速度を評価できませんか?
試験環境の測定と実機での確認は行えます。Googleの説明では、公開直後や十分な利用データがないページでは、実利用データが表示されない場合があります(2024年10月更新)。データ不足だけで速度の良否は判断できません。サイト全体の集計が表示される場合もあるため、担当者は対象範囲を確認します。その集計と入力したページの結果を区別したうえで、担当者は個別の測定と操作確認を進めます。
表示が遅い場合は、サイト全体を作り直す必要がありますか?
担当者は問題が特定ページに限られるか、共通部分に広がるかを確認し、制作会社が示す変更範囲をもとに、画像や一部の処理の変更で対応できるかを確かめます。既存の仕組みで変更や検証が難しい場合は、担当者がより広い改修も検討します。担当者は速度の点数、残せる部分、変更対象、変更後の確認方法を比較するまで、作り直すかどうかを決めません。
画像をWebPに変換すれば、画質を保ったまま速くなりますか?
形式を変えるだけでは、画質と速度の両方を保証できません。担当者は変換後の容量と見え方を比較し、製品の細部や画像内の文字を読む用途がある場合は、その条件でも確認します。画像を軽くしても読み込み開始が遅ければ、別の調整が候補に入ります。Googleのweb.devは、LCP画像の読み込み開始と優先度も改善項目として説明しています(2024年10月更新)。
改善した直後にCore Web Vitalsの判定は変わりますか?
PageSpeed Insightsの集計には、過去28日間の実利用データと改善前の利用状況が含まれています(Google、2024年10月更新)。担当者は公開直後の判定に改善前の状態も反映されていることを踏まえ、試験環境で変更の影響を調べ、実際の操作も試します。その後は、担当者が実利用データの推移を追い、変更前の期間の混在と利用者の条件による違いも考慮して評価を進めます。
引用・参考資料