PageSpeed Insightsのスコアは、BtoBサイトのCV（コンバージョン）率を左右する重要な指標です。LCP・FID・CLSという3つのCore Web Vitalsを中心に、ページの読み込み速度やインタラクション品質を数値化してくれます。スコアが低いサイトは、検索エンジンの評価が下がるだけでなく、ページを離脱するユーザーが増え、問い合わせにたどり着く前に機会を失うリスクがあります。
正直なところ、「スコアの数字は見ているけど、何から手をつければいいかわからない」という状況はあるあるです。PageSpeed Insightsが出力するレポートは情報量が多く、改善項目を優先順位づけしないまま手を動かしてしまうと、工数をかけても成果につながらないことがあります。本記事では、スコアの正しい読み方から、BtoBサイトで最もCVRに直結する改善順序まで、一気通貫した実践手順をお伝えします。
こんな方にオススメ
- PageSpeed InsightsのスコアがどのようにCV率や検索順位に影響するか知りたい方
- 改善項目が多すぎて何から手をつければよいか迷っているマーケ担当者
- 技術的な施策の費用対効果を社内で説明・稟議したい方
この記事を読むと···
- PageSpeed Insightsのレポートを正しく読み解き、BtoBサイトに特化した改善優先順位を判断できるようになります
- LCP・CLS・FIDそれぞれの改善アプローチを実践的に理解し、すぐに施策を動かせます
- 速度改善の成果をCVR・CPLの観点で定量的に説明する方法がわかります
目次
PageSpeed InsightsとCore Web Vitalsの基本的な関係
PageSpeed Insightsを使いこなすためにまず押さえておきたいのは、「スコアそのものより、その内訳となる指標を読む」という視点の切り替えです。総合スコアはあくまで複数指標の加重平均であり、BtoBサイトの収益に直結するのはLCP・CLS・INPの3指標です。それぞれの意味と閾値を理解することが、改善の生命線になります。
LCP（Largest Contentful Paint）とは何か
LCPはページ内で最も大きなコンテンツ要素（主にファーストビューの画像や見出しテキスト）が画面に描画されるまでの時間を計測します。Googleの基準では2.5秒以内が「良好」とされており、4.0秒を超えると「要改善」の赤判定になります。BtoBサイトにおいてLCPが遅いと、訪問者は「このサイト重いな」と感じてブラウザバックする確率が高まります。
LCPの主な遅延原因は、ファーストビューに置かれた未圧縮の大容量画像、JavaScriptによるレンダリングブロック、そしてサーバーのTTFB（Time To First Byte）の長さです。特に人材派遣業や不動産業のようなサービスサイトでは、トップページにビジュアル訴求のヒーロー画像を配置するケースが多く、ここが最初のボトルネックになりやすいという傾向があります。
対策の優先順位は「①画像の次世代フォーマット（WebP/AVIF）への変換 → ②fetchpriority=”high”属性の付与 → ③TTFBの短縮（CDNやサーバー応答最適化）」の順で進めるのが成功への近道です。この順序で取り組めば、工数対効果の高い改善から着実にスコアを積み上げられます。
CLSとINP：レイアウトのズレとインタラクション速度の重要性
CLS（Cumulative Layout Shift）は、ページ読み込み中にコンテンツが予期せずズレる現象を数値化したものです。0.1以下が良好で、0.25を超えると「低評価」となります。
問い合わせフォームのボタンが読み込み中に動いて押し間違えた経験を持つ方は多いはずです。まさにああいった現象がCLSスコアに反映されます。
INP（Interaction to Next Paint）は2024年3月にFIDから置き換えられた比較的新しい指標で、クリックやタップへの応答速度を計測します。BtoBサイトの場合、問い合わせフォームの入力補助やチャットウィジェットの起動など、ユーザーが行動するタイミングでの遅延を捉えます。200ms以内が良好基準です。
CLSの主な原因はサイズ未指定の画像・広告・埋め込みコンテンツです。HTMLの<img>タグにwidthとheight属性を明示するだけで大幅に改善できるケースが多く、工数対効果の面で見極めやすい施策です。INPについては不要なJavaScriptの分割（コード分割）やメインスレッドの解放が鍵になります。
PageSpeed Insightsのレポート構造：「診断」と「機会」の読み分け
PageSpeed Insightsのレポートは大きく「フィールドデータ」と「ラボデータ」の2種類に分かれています。フィールドデータ（CrUX）が実際のユーザー体験の実測値であり、SEO評価と直結する数字です。ラボデータはGoogleのサーバーからシミュレートした参考値なので、両者が乖離している場合はフィールドデータを優先して読みましょう。
その下に表示される「改善できる事項」と「診断」セクションは内容が異なります。「改善できる事項」はスコアに直接影響する施策、「診断」は長期的なベストプラクティスに関わる情報です。限られた開発リソースで動く場合は「改善できる事項」に絞って対応するのが実践的活用力の発揮どころです。
あなたに関連しそうなCreative Driveの機能・サポート一覧
機能・サポート一覧を見る →
BtoBサイトの改善優先順位の正しい決め方
PageSpeed Insightsのレポートを見ると、改善項目が10件以上並ぶことは珍しくありません。しかし、すべてに同等のリソースをかけるのは非効率です。BtoBサイトにおける改善優先順位は「CVRへの影響度 × 実装工数の逆数」で判断するのが、差別化を図るうえでの実践的な考え方です。
「LCP改善 → 画像最適化 → JS遅延」の黄金ルート
BtoBサイトにおける改善の黄金ルートは、①LCPの主因となる画像最適化 → ②レンダリングブロックするJavaScriptの遅延読み込み → ③サーバー応答速度（TTFB）の短縮の3ステップです。この順序で着手することで、最小工数で最大のスコア改善を期待できます。
画像最適化は技術的な難易度が比較的低く、次世代フォーマットへの変換と適切なサイズ指定を行うだけで、LCPを1〜2秒単位で短縮できるケースがあります。一方でJavaScriptの最適化はコードの把握が必要なため、既存の開発ドキュメントやバンドル構成を確認する情報収集が欠かせません。
サーバー応答（TTFB）の改善はCDN導入やキャッシュ設定が主な手段です。特にWordPressサイトでサーバーキャッシュが未設定の場合、TTFBが500ms〜1秒以上になることがあり、これだけで全体のスコアを大幅に押し下げる原因になります。まずTTFBが200ms以内に収まっているかを確認するところから始めるとよいでしょう。
モバイルとデスクトップ、どちらのスコアを優先すべきか
PageSpeed Insightsはモバイルとデスクトップで別々のスコアを表示します。BtoBサイトの場合、まずデスクトップのスコア改善を優先するケースが多いです。その理由は、BtoBサービスの問い合わせは依然としてPC環境からが多い傾向があり、フィールドデータを確認するとデスクトップセッションの比率が高いサイトが少なくないからです。
ただしこれは一律の正解ではなく、実際のGoogleアナリティクス（GA4）でデバイス別セッション比率を確認してから判断することが重要です。モバイル比率が50%を超えているサイトであれば、モバイルスコアを先に対応する必要があります。感覚論で判断するのではなく、データで見極めることが生き残る鍵になります。
改善ロードマップを社内稟議に通す「定量的な見通し」の作り方
技術施策への投資判断で最も難しいのは、社内の意思決定者に対してCVRへの影響を定量的に説明することです。「6ヶ月後にどう変わるか」という数字の見通しを示せないと、稟議が通らないというのは多くの企業で共通の課題です。感覚論では動けない組織が大多数という現実を踏まえると、改善ロードマップには必ず「現状スコア → 目標スコア → 期待されるCVR改善幅」の3点セットを含めることをお勧めします。
Googleの公開データによると、ページの読み込み時間が1秒から3秒に増加するとモバイルでの離脱率は32%増加するとされています（Google/SOASTA調査）。この種の業界データを出発点に、自社のGA4データと組み合わせて試算シートを作ることで、社内説明の説得力が大きく変わります。CreativeDriveでは、こうした定量的な見通しを提案段階から提示するアプローチを採用しており、稟議が通りやすい形でクライアントの意思決定をサポートしています。
POINT
改善施策の社内提案では「スコアが上がる」だけでなく、「離脱率が〇%下がると月〇件の問い合わせ増加が見込める」という形で、CVRとリード数への影響を具体化することが稟議を通す最短ルートです。
PageSpeed Insightsの具体的な改善手順と実装方法
ここからは実際に手を動かすフェーズです。改善を「画像 → JavaScript → サーバー」の順で進める際の具体的な実装手順を、現場で使える粒度でお伝えします。情報収集が欠かせない工程と、ツールで自動化できる工程を分けて理解することが、限られたリソースで成果を出す鍵です。
画像最適化の具体的な実装手順
画像最適化は3つのアクションで構成されます。① フォーマット変換（WebP/AVIF）、② サイズの適正化、③ 読み込み優先度の制御です。この3つを組み合わせることで、LCPの改善効果を最大化できます。
フォーマット変換はSquoosh（無料のブラウザツール）やImageOptimなどで手動変換することもできますが、WordPressであれば「Imagify」「ShortPixel」などのプラグインで自動化できます。変換後のファイルサイズ削減率は一般的に30〜50%程度になるとされており、大容量のファーストビュー画像ほど効果が顕著です。
読み込み優先度の制御はfetchpriority="high"属性をLCPとなる画像のimgタグに追加するだけで実装できます。逆にファーストビュー外の画像にはloading="lazy"を付与して遅延読み込みを有効にしましょう。この掛け合わせによって、ブラウザが最初に描画すべき要素に集中できる環境を作るのが実践的な手順です。
- 1
PSIでLCPの原因要素を特定する
レポートの「診断」→「最大コンテンツの描画要素」でLCPの実体（画像URL or テキスト）を確認。画像の場合はそのURLをメモする。
- 2
画像をWebP形式に変換してサーバーに差し替える
元の画像と同じURL構造でWebPを配置し、htaccessまたはpicture要素でWebPを優先配信する設定を追加する。
- 3
LCP画像に fetchpriority=”high” を付与する
該当imgタグに属性を1行追加するだけ。WordPress環境では
wp_get_attachment_imageフィルターで一元管理できる。 - 4
スコアを再測定してLCPの改善幅を確認する
PSIでBefore/Afterを記録し、次のステップ（JS最適化）に移るかを判断する。
JavaScriptのレンダリングブロック解消手順
JavaScriptの最適化は、「defer属性追加 → 不要プラグイン・スクリプトの棚卸し → コード分割」の順序で進めることで、リスクを抑えながら改善できます。一度にすべてのJSを書き換えようとするのではなく、影響範囲の小さなものから着手するのが現場では賢明です。
まず<script>タグにdeferまたはasync属性が付いているかを確認します。どちらもないスクリプトはHTMLのパース（読み込み）をブロックするため、スコアを著しく下げます。GoogleタグマネージャーやチャットツールのSDKなど、外部から読み込むスクリプトが多いサイトほど、この影響が大きいという傾向があります。
次に行うのが使っていないプラグインやスクリプトの棚卸しです。WordPressサイトでは導入したまま使っていないプラグインが大量のJSを読み込んでいるケースが散見されます。WP-Optimize、Asset CleanUpなどのプラグインで各ページで読み込まれているスクリプトを可視化し、不要なものを無効化することで、開発コストをかけずにスコアを改善できます。
サーバー応答速度（TTFB）の改善とCDN活用
TTFB（Time To First Byte）は200ms以内が理想とされており、これを超えるとLCP全体に悪影響を与えます。TTFBの改善手段は「CDN導入」「サーバーサイドキャッシュ」「ホスティング環境の見直し」の3つが主軸です。
CDNはCloudflareの無料プランから始められます。静的アセット（CSS・JS・画像）をエッジサーバーから配信することで、地理的な距離によるレイテンシを削減できます。WordPressの場合はW3 Total CacheやWP Rocket（有料）と組み合わせることで、ページキャッシュとCDNを一気通貫した形で設定できます。
サーバー環境を見直す場合、共有ホスティングから専用サーバーやクラウド（AWS・ConoHa WINGなど）への移行が有効な場合があります。ただし移行コストと得られるTTFB改善幅を比較して、本当に投資対効果があるかを見極めることが必要です。まずはサーバーキャッシュの有効化から試し、改善幅を確認してから移行を検討する順序が安全です。
| 改善項目 | 対象指標 | 実装難易度 | CVRへの影響度 |
|---|---|---|---|
| 画像のWebP変換 | LCP | 低（ツール活用可） | 高 |
| fetchpriority=”high”付与 | LCP | 低（1行追記） | 高 |
| スクリプトのdefer化 | LCP・INP | 中（動作確認必要） | 中〜高 |
| 画像サイズ・height/width属性指定 | CLS | 低（HTML修正） | 中 |
| CDN導入 | LCP（TTFB） | 中（DNS設定変更） | 中〜高 |
| サーバーキャッシュ有効化 | LCP（TTFB） | 低〜中（プラグイン活用） | 中 |
スコア改善がCVRに与える影響をどう測るか
PageSpeed Insightsのスコアを上げること自体が目的ではなく、あくまでCVR改善・問い合わせ増加という事業目標への手段です。この因果関係を正確に把握するためには、速度改善の前後でGA4のデータを比較する設計が欠かせません。施策を打つ前からトラッキング体制を整えておくことが、実践的活用力のある組織とそうでない組織の大きな違いです。
GA4で速度改善の効果を計測するセットアップ方法
速度改善の効果をGA4で計測するには、施策前のベースライン期間（最低4週間）のデータをセグメントとして保存しておくことが第一歩です。具体的には「改善対象ページ」「デバイス別」「オーガニック流入のみ」のセグメントを事前に作成し、直帰率・滞在時間・CV数の基準値を記録します。
施策完了後も同じセグメントで4週間以上計測し、前後の数値を比較します。この際、季節性や広告予算の変動などの外部要因が混入しないよう、前年同期比での比較も併用するとデータの信頼性が上がります。
また、Search Consoleと連携することでオーガニック検索のCTRや表示回数の変化も追跡できます。速度改善がCore Web Vitalsの評価向上を通じて検索順位に影響を与えているかを検証するうえで、この連携データは強みを活かせる領域の一つです。
「スコア60点でも問い合わせは来る」に潜む構造的リスク
「現状でもそれなりに問い合わせは来ているから、速度改善の優先度は低い」という判断は要注意です。これは競合も同じように遅い場合に成立する仮説であり、競合がスコアを改善した瞬間に検索順位と問い合わせ率の逆転が起きるリスクを内包しています。
Googleは2021年のPage Experienceアップデート以降、Core Web Vitalsをランキングシグナルとして採用しています。同一のキーワードで競合するページのスコア差が大きくなると、コンテンツの質が同等でも順位差が生まれやすくなるとされています。特にBtoBサービスのように指名検索以外で競争するキーワードでは、この影響が顕在化しやすいという傾向があります。
CPL（リード獲得単価）の観点からみたスコア改善の費用対効果
技術施策の費用対効果を語るうえで有効な視点が、CPL（Cost Per Lead）との比較です。広告経由のリード獲得単価が高騰している中、オーガニック経由の問い合わせコストを下げることが多くのBtoB企業にとっての課題となっています。
PageSpeed Insightsのスコア改善による離脱率低下→CV数増加という経路は、広告費を増やすことなくCPLを圧縮できる手段の一つです。実装コストが一定であるのに対し、効果が継続的に積み上がる性質がコンテンツSEOとの相性もよく、技術SEOとコンテンツ戦略を掛け合わせて新しい価値を生むという発想が今後ますます重要になります。
よくある改善ミスと対策：スコアを上げたのにCVが増えないパターン
「PSIのスコアは改善したのに問い合わせが増えない」という状況は、あるあるです。ここには技術指標の改善とビジネス成果の間に存在するいくつかの構造的な落とし穴があります。ミスのパターンを知っておくことで、施策設計の段階から強みを活かせる領域に集中できます。
ラボデータのみ改善してフィールドデータが変わっていないケース
PageSpeed Insightsで表示されるラボデータ（Lighthouse）のスコアは改善されたのに、フィールドデータ（CrUX）が変化していないというケースは少なくありません。ラボデータはGoogleが制御された環境でシミュレートした数値であり、実際のユーザーが多様なデバイス・回線環境でアクセスする現実とは乖離することがあります。
フィールドデータが改善するには一定のユーザーデータ蓄積期間が必要です。Googleが28日間のローリングウィンドウでCrUXデータを集計しているため、施策完了から少なくとも1ヶ月は経過した後でフィールドデータを再確認するようにしましょう。
またフィールドデータは訪問数が少ないサイトでは表示されないことがあります。その場合はSearch Console内の「ウェブに関する主な指標」レポートでデータを確認するか、ラボデータとGA4のパフォーマンス計測を組み合わせて間接的に評価する方法が現実的です。
速度は改善したがCVポイント（フォーム）自体に問題があるケース
ページの読み込み速度が改善されても、問い合わせフォームの入力ステップが多い・エラーメッセージがわかりにくい・確認ページで離脱が発生しているなど、フォーム自体のUXに問題がある場合はCVR改善に直結しません。速度改善とフォーム最適化は別の施策として並行して取り組む必要があります。
GA4のイベントトラッキングでフォームの各ステップ通過率を計測することで、どのステップで離脱が集中しているかを可視化できます。速度改善の前にこの計測設計を入れておくことで、施策間の効果の切り分けが明確になります。
- ラボデータのみを見てフィールドデータの確認を怠る（実際のユーザー体験と乖離する）
- デスクトップのスコアだけ改善してモバイルを放置する（検索評価はモバイルファーストで行われる）
- スコアが高くなったことに満足してCVRのBefore/After計測をしない（ROIが不明になる）
- サードパーティスクリプト（チャット・広告タグ等）の影響を無視する（これらはPSIスコアに大きく影響する）
- 施策後の計測期間を1〜2週間で打ち切る（フィールドデータ反映には28日以上必要）
サードパーティスクリプトのスコアへの影響を見落とすケース
チャットサポートツール、マーケティングオートメーション（MA）の計測スクリプト、リターゲティング広告タグなど、サードパーティスクリプトはPageSpeed Insightsの「サードパーティコードの影響」セクションに一覧表示されます。これらは自社での直接制御が難しく、改善の選択肢が限られるため、先に自社制御可能なファーストパーティの最適化を完了させてから向き合う順序が現実的です。
どうしてもサードパーティスクリプトのスコアへの影響が大きい場合、Googleタグマネージャーで読み込みのトリガーを「ユーザーが操作した後」に遅延させる設定が有効な場合があります。ただしこの設定は計測タイミングに影響することがあるため、MAチームとデータチームと連携して実施することが大切です。
CreativeDriveによる技術SEO × コンテンツ戦略の統合アプローチ
PageSpeed Insightsのスコア改善は、実施すれば終わりという性質の施策ではありません。サイトリニューアル・新規コンテンツの追加・サードパーティツールの導入のたびに再計測と改善を繰り返す継続的なサイクルが必要です。正直なところ、この継続的な改善サイクルを内製リソースだけで回すのは、多くの企業にとってハードルが高いのが実態です。
CreativeDriveでは、技術SEO（PageSpeed改善・Core Web Vitals対応）とコンテンツマーケティングを一気通貫した形で支援しています。月50本のAI記事量産パイプラインで潜在顧客が情報収集するフェーズから接点を作りながら、技術的なサイト品質を維持・改善することで、オーガニック流入とCV率の両方を長期的に高める設計を採用しています。「スコアが上がったが問い合わせが増えない」という状況を防ぐために、記事ごとの動的CTA設計と業種別のリード育成トラッキングを掛け合わせて新しい価値を生む仕組みを構築しています。
技術SEOへの投資判断に必要な「6ヶ月後の定量的な見通し」をご提案段階で提示できますので、稟議が通りにくい組織でも意思決定をスムーズに進めていただけます。サイトの現状スコアと改善余地の把握から始めたい方は、ぜひ弊社へご相談ください。
技術SEOとコンテンツ戦略を掛け合わせて成果を出す方法について、CTVRマーケティング — データ計測・分析手法も合わせてご確認ください。
まとめと実装チェックリスト
PageSpeed InsightsはBtoBサイトのCVR改善において重要な生命線となる計測ツールです。しかし「スコアを上げること」を目的にするのではなく、「LCP・CLS・INPの3指標がユーザー体験にどう影響するか」を理解した上で優先順位を決めることが、差別化を図るうえでの本質的な取り組みです。
改善の黄金ルートは「①画像最適化（WebP変換・fetchpriority設定）→ ②JavaScriptの遅延読み込み → ③サーバー応答速度（CDN・キャッシュ）」の順序です。また、改善効果を社内に説明するためには、GA4のセグメント設計と6ヶ月後の見通しを定量的に示すことが稟議を通す成功への近道になります。
- PSIでフィールドデータ（CrUX）とラボデータの両方を確認済み
- LCPの主因要素（画像 or テキスト）を特定済み
- ファーストビュー画像をWebP/AVIFに変換済み
- LCP画像にfetchpriority=”high”を付与済み
- スクロール外の画像にloading=”lazy”を付与済み
- 全画像にwidth・height属性を明示済み（CLS対策）
- 主要スクリプトにdefer/async属性を付与済み
- 未使用プラグイン・スクリプトの棚卸しを実施済み
- TTFBが200ms以内であることを確認済み
- CDNまたはサーバーキャッシュが有効になっている
- GA4に施策前のベースラインセグメントを保存済み
- 施策後28日以上経過した後のフィールドデータを再確認予定
- PageSpeed Insightsのスコア改善と問い合わせ増加を同時に実現したい方
- 社内リソースが限られており、技術施策の優先順位判断を外部に委ねたい方
- 稟議に必要な「6ヶ月後の定量的な見通し」を提案段階から受け取りたい方
CreativeDriveのサポート範囲について
よくある質問
