サイトが重くて離脱される原因と対策｜AIで表示速度を改善

デロイトがGoogleの委託で実施し2020年に公開した調査「Milliseconds Make Millions」は、欧米37ブランドのサイトで3,000万を超えるユーザーセッションを30日間分析し、モバイルサイトの表示速度をわずか0.1秒改善しただけで、小売サイトのコンバージョン率が8.4%、旅行サイトでは10.1%増加したと報告しています。1秒ではありません。0.1秒です。ページの重さは「なんとなく体感が悪い」という感覚の問題ではなく、問い合わせや売上の数字に直結する、計測と改善が可能な経営課題です。本記事では、サイトが重くて離脱される課題を、課題→原因→対策の順に整理し、生成AIを計測の読み解きと改善の実装にどう活かすかを解説します。

0.1秒の改善が数字を動かす：公表データが示す速度の価値

冒頭で触れた「Milliseconds Make Millions」の中身をもう少し見てみましょう。この調査の特徴は、実験室のシミュレーションではなく、実在するブランドサイトの実ユーザーデータを分析した点にあります。モバイルの表示速度を0.1秒改善したときの変化は、業種ごとに次のように報告されています。

業種	0.1秒改善で観測された主な変化
小売	コンバージョン率+8.4%、平均注文額+9.2%
旅行	コンバージョン率+10.1%、チェックアウト完了率+2.2%
ラグジュアリー	商品詳細からカートへの進行率+40.1%
リード獲得型サイト	フォーム送信ページへの進行率+21.6%、ページビュー+7%

BtoBのサイト担当者に特に見てほしいのは、最後のリード獲得型サイトの行です。ECのように購入が完結しないサイトでも、フォームにたどり着く人の数が速度で2割以上変わったと報告されています。問い合わせ獲得を目的とするBtoBサイトにとって、表示速度はフォーム到達率を左右する変数だということです。もちろんこれは特定条件下の調査結果であり、どのサイトでも同じ数字が出るわけではありません。それでも「速度の改善は売上側の指標に波及する」という方向性は、この規模の実データが裏づけています。

課題：「重い」を感覚から数字にする——Core Web Vitals

では、自社サイトの「重さ」をどう測ればよいのでしょうか。ここで使うのが、Googleが提唱するCore Web Vitals（コアウェブバイタル）です。これは読み込みの速さ・操作への反応・表示の安定性という3つの体験を数値化した、ユーザー体験の共通指標で、現行の3指標と良好の基準は次のとおりです。

指標	何を測るか	良好の基準
LCP（Largest Contentful Paint）	主要コンテンツが表示されるまでの時間	2.5秒以内
INP（Interaction to Next Paint）	操作してから画面が反応するまでの時間	200ミリ秒以下
CLS（Cumulative Layout Shift）	表示中のレイアウトのずれの累積量	0.1以下

評価方法にも公式の決まりがあります。判定に使われるのは実ユーザーの計測値の75パーセンタイル、つまり訪問の75%がその値より良い状態かどうかで、モバイルとデスクトップは別々に集計されます。平均値ではなく75パーセンタイルを使うのは、一部の速い環境に引っ張られず、大多数のユーザーの体験を保証するためです。「自分のPCでは速く見える」が当てにならない理由が、この集計方法にあります。

INPは2024年3月導入：クリックしてから画面が動くまで

3指標の中で最も新しいのがINPです。2024年3月に、それまでの応答性指標だったFID（First Input Delay）と正式に入れ替わりました。両者の違いは測る範囲です。FIDが計測するのはページ読み込み中の最初の操作の遅延だけでしたが、INPはページ滞在中のすべての操作を対象に、操作してから次の描画が画面に反映されるまでの時間を評価します。読み込み直後は快適でも、使い込むほどもたつくページはFIDでは見えず、INPで初めて可視化されるようになりました。

この入れ替えで、これまで合格だったサイトが不合格に転じるケースが実際に発生しています。特に、開閉メニュー・絞り込み・タブ切り替えなどJavaScriptで動く要素の多いサイトは影響を受けやすい構造です。注意したいのは、古い解説記事やAIの回答に、いまだにFIDが現行指標として登場することです。2024年3月以降の現行指標はLCP・INP・CLSの3つ。社内資料や改善計画を作る際は、この前提から書き始めてください。

Googleはランキングでどう扱うか（公式見解）

表示速度対策の話になると、「順位のためにやるのか、ユーザーのためにやるのか」という議論が起きがちです。Google検索セントラルの公式ドキュメントは、Core Web Vitalsをその他のページエクスペリエンスの要素とともにコアランキングシステムがランキングを決定する際に考慮する要素と位置づけ、サイト所有者に改善を強くすすめると明記しています。ランキングに無関係ではない、というのが公式の立場です。

ただし過大評価も禁物です。同じくGoogleは、優れたページ体験がコンテンツの質を上回るわけではないことを繰り返し説明しており、検索順位の主役はあくまで内容の有用性です。実務的な整理としては、順位への直接効果は補助的なものと見込みつつ、本丸の効果は離脱率・フォーム到達率・広告の品質への波及と捉えるのが健全です。冒頭のデロイトのデータが示したとおり、速度改善の投資対効果は検索順位を経由しなくても十分に説明できます。順位はおまけ、体験と転換率が本体。この優先順位で取り組むことをおすすめします。

計測手順：PageSpeed Insightsで現状を知る

課題を数字にする最初の道具は、Googleが無償提供するPageSpeed Insightsです。URLを入力するだけで、実ユーザーのデータとシミュレーション診断の両方を確認できます。次の手順で、まず現状を記録しましょう。

あわせて、Search ConsoleのCore Web Vitalsレポートも開いてください。PageSpeed Insightsが1ページずつの精密検査だとすれば、こちらはサイト全体のどのURLグループに問題があるかを俯瞰する健康診断です。不良・改善が必要と判定されたURLグループから優先的に精密検査にかける、という二段構えが効率的です。

なお、訪問の少ないサイトやページでは、上段の実ユーザーデータそのものが表示されないことがあります。フィールドデータは、十分な訪問量が集まった場合にだけ集計されるためです。この場合は、Search Consoleのレポートと下段のラボ診断を組み合わせて判断します。データが出ない＝問題がない、ではない点には注意してください。むしろ流入を増やす施策と並行して、ラボ診断で見つかる明らかな重さを先に取り除いておくのが得策です。

フィールドデータとラボデータ：数字が食い違う理由

計測を始めるとすぐ、不思議な現象に出会います。同じページなのに、実ユーザーデータでは不合格なのに診断スコアは高い、あるいはその逆が起きるのです。これは不具合ではなく、2種類のデータの性質の違いです。フィールドデータ（実ユーザーデータ）は、実際の訪問者の端末や回線で計測された値で、Chromeユーザーの統計（CrUX）から集計されます。ラボデータは、ツールが一定条件でシミュレーションした値で、Lighthouseによる診断がこれに当たります。検索の評価に使われるのはフィールドデータです。

使い分けの原則はこうです。合否の判断と優先順位づけはフィールドデータで行い、原因の切り分けと改善前後の比較はラボデータで行う。ラボデータは条件が一定なので、施策の効果検証に向いています。もう一つ重要な注意として、ラボ計測ではINPは測れないという制約があります。シミュレーションにはユーザーの操作が存在しないためで、Lighthouseでは代替指標が使われます。INPの改善は、実ユーザーデータの推移か、後述するDevToolsでの実操作の記録で確認する必要があります。

本格的に運用するなら、実ユーザー計測（RUM）を自社で持つ選択肢もあります。Googleはweb-vitalsというJavaScriptライブラリを公開しており、これを組み込むと自社の解析基盤でLCP・INP・CLSを収集できます。外部の集計を待たずに、ページ単位・施策単位で速度と成果の関係を自社データで追えるのが利点です。導入の実装もAIにコード例を出させれば、検討のハードルは高くありません。

原因(1)：LCPを遅らせる正体——画像とサーバー応答

ここからは、指標ごとに悪化の典型原因を見ていきます。LCPの悪化要因としてまず疑うべきは、ファーストビューの大きな画像です。撮影したままの数MBの画像をそのまま載せている、スライダーで複数の大画像を先頭に読み込んでいる、といったパターンは、BtoB企業サイトでも頻繁に見つかります。次に疑うのがサーバーの応答時間です。ページの生成に時間がかかるCMS、混み合った共用サーバー、キャッシュの不在などが、ブラウザが最初の1バイトを受け取るまでの時間を引き延ばします。

原因の見当をつけるには、PageSpeed Insightsの診断項目が役立ちます。「適切なサイズの画像を配信する」「次世代フォーマットでの画像の配信」が上位に出るなら画像が主因、「サーバーの初期応答時間を短縮する」が出るならサーバー側が主因です。画像が主因の場合の対策は後述の画像最適化の章で、サーバーが主因の場合はキャッシュの導入やホスティングプランの見直しが検討対象になります。主因がどちらかで打ち手がまったく違うため、対策の前にこの切り分けを必ず行ってください。

原因(2)：INPを悪化させる正体——重いJavaScript

INPの悪化は、ほとんどの場合JavaScriptの処理に行き着きます。ブラウザは画面の描画とスクリプトの実行を同じ処理系で行うため、重いスクリプトが動いている間、クリックへの反応は後回しにされます。典型的な犯人は、計測タグやチャットツールなどの外部スクリプトの積み重ね、古いプラグインやテーマが読み込む大量のライブラリ、そして操作のたびに走る重い処理です。特にタグは、マーケティング部門が歴代で足してきたものが棚卸しされずに残り、誰も使っていないタグがページを重くし続けているケースが目立ちます。

対策の第一歩は、タグとプラグインの棚卸しです。タグマネージャーの一覧を出し、発行部署と利用状況を確認して、使われていないものを削除する。これだけでINPが目に見えて改善することがあります。開発リソースがある場合は、処理の分割や遅延読み込みといった実装レベルの改善に進みますが、その際の指示書づくりは後述のとおり生成AIに手伝わせると効率的です。まずは「消せるものを消す」から。追加の開発なしでできる改善が、INPには意外と多く残っています。どうしても削除できないタグには、読み込みの優先度を下げる、ユーザーの操作後まで実行を遅らせるといった次善策もあります。

原因(3)：CLSを起こす正体——後から動くレイアウト

CLSは速さではなく、表示の安定性の指標です。読み込み中に画像や広告が後から現れて本文が押し下げられ、読んでいた行を見失う——あの現象の累積量を測っています。原因の典型は、サイズ指定のない画像や埋め込み要素です。ブラウザは画像の寸法が事前にわからないと場所を確保できず、読み込み完了時にレイアウトを組み直します。ほかにも、後から挿入されるバナーやお知らせ帯、読み込み後に置き換わるWebフォントなどが、ユーザーが操作しようとした瞬間のずれを生みます。

対策は原因に対して素直です。画像とiframeには幅と高さの属性を指定して場所を先に確保する、後から挿入する要素には表示領域をあらかじめ確保しておく、フォントの切り替えによるちらつきを抑える設定を入れる、といった手当てです。CLSはLCPやINPに比べて、原因と対策が1対1で対応しやすく、直した効果がラボ計測でも確認しやすい指標です。3指標の中では着手しやすい改善対象と言えます。ただし修正はテンプレート単位に及ぶことが多いため、次章のAI活用で作業量を圧縮しましょう。

対策(1)：AIに診断結果を渡して、改善コードを出させる

原因の見当がついたら、いよいよ生成AIの出番です。最も再現性の高い使い方は、PageSpeed Insightsの診断結果を丸ごと渡して、対処の優先順位と具体的な修正コードを出させる方法です。プロンプトの型を示します。

あなたはWebパフォーマンスの専門家です。以下はPageSpeed Insightsの診断結果です。

・サイトの環境：WordPress、テーマは（テーマ名）、主な流入はモバイル
・診断結果：（改善できる項目・診断の内容を貼り付け）

出力してほしいもの：
1. 影響の大きい順に並べた対処リスト（工数の目安つき）
2. 各対処の具体的な修正方法（コードが必要なものはコード例）
3. 専門知識がなくても実施できる項目とできない項目の区別

ポイントは、環境情報を必ず添えることと、出てきたコードをそのまま本番に入れないことです。AIの提案には、環境によっては不要な最適化や、テーマの実装と噛み合わない修正が混ざることがあります。テスト環境で適用し、ラボ計測で前後を比較してから本番に反映する。この検証の一手間をルール化すれば、AIは「診断結果を読める人がいない」という中小規模チームの壁を取り払う、強力な相棒になります。

対策(2)：Chrome DevToolsのAI支援で原因を深掘りする

より深い調査には、ブラウザ標準の開発者ツールであるChrome DevToolsが使えます。近年の大きな変化が、GeminiによるAI支援機能の統合です。パフォーマンスパネルで記録した実際の操作の計測データをもとに、AIに遅い箇所の解説や改善方針を対話形式で尋ねられるようになりました。従来は専門家にしか読み解けなかった処理の記録について、どの処理がLCPやINPの足を引っ張っているかを、平易な言葉で説明させられるのは大きな進歩です。Lighthouseのデータを参照して回答する機能拡張も進んでいます。

さらに開発者向けには、Chrome DevToolsをコーディングAIから直接操作できる仕組み（Chrome DevTools MCP）も公開されており、AIエージェントが実際のブラウザで計測しながら修正を検証する、といった使い方が広がりつつあります。とはいえ、サイト担当者がまず触るべきはパフォーマンスパネルの記録とAIへの質問で十分です。実ユーザーデータで問題が出ているページを開き、操作を記録し、遅い区間についてAIに尋ねる。この流れだけで、外部に調査を依頼する前の一次切り分けが自走できるようになります。

対策(3)：画像最適化——最初に効く一手

改善の実行フェーズで、費用対効果が最も読みやすいのが画像です。やることは3つに集約されます。第一に、表示サイズに合わせた寸法への縮小。第二に、WebPやAVIFといった圧縮効率の高い形式への変換。第三に、ファーストビュー外の画像の遅延読み込みです。CMSを使っているなら、アップロード時に自動で変換・圧縮するプラグインや、画像配信サービスの導入で、個別作業なしに全画像へ一括適用できます。

既存画像が大量にある場合は、AIやスクリプトによる一括処理が現実的です。画像フォルダを対象に、一定サイズ超の画像を検出して変換するスクリプトを生成AIに書かせれば、手作業では数日かかる棚卸しが短時間で終わります。あわせて、今後に向けた運用ルールも決めておきましょう。撮影画像や図版を縮小せずにアップロードしない、アップロード時に自動圧縮が効く設定にしておく——入り口で止める仕組みがあれば、画像の重さは再発しません。注意点も添えておきます。

• 圧縮しすぎると製品写真や図版の品質が落ちる。重要画像は圧縮率を分けて確認する
• 変換後も元画像は必ずバックアップしてから置き換える
• ロゴや細い線の図はWebP化で劣化が目立つことがある。仕上がりを目視確認する
• 遅延読み込みをファーストビューの画像にまで適用すると、かえってLCPが悪化する

対策(4)：CMS側の定番対策と、消してはいけないもの

WordPressなどのCMSで運用しているサイトなら、実装に踏み込む前にできる定番対策があります。キャッシュ機能の導入、使っていないプラグインの削除、軽量なテーマへの見直し、CDN（コンテンツ配信ネットワーク）の利用などです。プラグインは足し算で増えがちですが、それぞれがスクリプトやスタイルを読み込むため、削ることが最も確実な高速化になる場面が多くあります。四半期に一度の棚卸しを運用に組み込むのがおすすめです。

一方で、速くするために消してはいけないものもあります。アクセス解析や広告の計測タグを深く考えずに外すと、速度と引き換えにマーケティングの意思決定に必要なデータが失われます。削除候補のタグは、発行部署に利用状況を確認してから外すのが鉄則です。また、高速化プラグインを複数併用すると、機能が競合して表示崩れや計測不能を招くことがあります。変更は一度に一つずつ、前後を計測しながら。地味ですが、この規律が「速くなったが何かが壊れた」という事故を防ぎます。

効果を金額に換算して、社内の合意を取る

速度改善には、画像の一括変換やテーマの見直しなど、まとまった工数や外注費が伴うことがあります。そこで必要になるのが社内の合意形成です。効くのは、期待効果を件数や金額に換算して示すことです。組み立てはシンプルで、自社サイトの月間セッション数・フォーム到達率・コンバージョン率という手持ちの数字に、冒頭で紹介したような公表データの改善幅を保守的に当てはめ、フォーム到達が月に何件増える見込みかを試算します。体感が悪いから直したい、ではなく、問い合わせが月何件増える見込みかで語れると、稟議の通り方が変わります。

この試算づくりも、生成AIとの壁打ちに向いた作業です。自社の現状値を渡して、保守・標準・楽観の3シナリオで試算表を組ませると、意思決定に足るたたき台が短時間で用意できます。誠実さのポイントは、公表データの数字をそのまま自社に当てはめないことです。調査対象のサイトと自社では条件が違うため、効果は幅を持たせて示し、改善後に実測で検証するところまでを提案に含めるのが信頼につながります。実測の改善幅が一度出れば、それが次の改善投資への最も強い説得材料になります。

やりがちな失敗：スコアだけを追う罠

最後に、速度改善プロジェクトが空回りする典型パターンを押さえておきましょう。

• ラボのスコア100点を目的化する：検索評価に使われるのは実ユーザーデータ。スコア競争は手段の目的化になりやすい
• FID時代の古い情報で計画を作る：現行指標はINP。古い解説やAIの回答を鵜呑みにすると対策がずれる
• 計測せずに施策を積む：前後比較がなければ効果も副作用もわからない。変更は一つずつ計測とセットで
• 速度のためにコンテンツや計測を削る：目的は見込み客の獲得。手段のために目的を壊さない

共通するのは、数字の意味を確認せずに動いてしまうことです。速度改善は、実ユーザーデータで課題を特定し、原因を切り分け、一つ直して計測する、の繰り返しに尽きます。生成AIはこのサイクルの各段階を速くしてくれますが、サイクルそのものを省略させてくれるわけではありません。また、速度対策は一度やって終わりの打ち上げ花火ではなく、定点観測の運用です。四半期ごとに主要ページを再計測し、リニューアルやページ追加のたびに数字を確かめる——この習慣まで含めて、速度対策と呼びます。

よくある質問

表示速度を改善すれば検索順位はすぐ上がりますか？

速度はランキングで考慮される要素ですが、順位の主役はコンテンツの質です。速度改善だけで順位が大きく動くことは期待しないでください。一方で、離脱率やフォーム到達率への効果は公表データでも裏づけがあり、こちらは順位と無関係に成果へ直結します。順位は副次効果、転換率が本命と考えるのが実務的です。

3指標のうち、どれから手をつけるべきですか？

実ユーザーデータで不合格になっている指標が最優先です。複数が不合格なら、原因と対策が対応しやすいCLS、費用対効果の読みやすい画像起点のLCP、構造的な調査が要るINP、という順で着手すると進めやすいケースが多いです。自社の不合格状況に合わせて決めてください。なお、同じテンプレートを使うページ群は1か所の修正が全ページに効くため、テンプレート単位で考えると費用対効果を見積もりやすくなります。

モバイルとデスクトップ、どちらを優先すべきですか？

評価はデバイス別に集計されるため、両方の確認が前提です。そのうえで、自社サイトの流入が多いデバイスを優先してください。多くのサイトではモバイルの数値のほうが厳しく出るため、モバイル起点で改善すればデスクトップも改善される、という順序が一般的です。

開発者がいない会社でも改善できますか？

できる範囲は十分にあります。画像の最適化、プラグインとタグの棚卸し、キャッシュ導入あたりは、管理画面の操作で完結することが多い領域です。実装が必要な改善も、PageSpeed Insightsの診断とAIの解説をセットにすれば、外注先への的確な依頼書が作れます。丸投げよりも費用と精度の両面で有利になります。事前にAIで論点を整理しておけば、見積もりの妥当性も判断でき、不要な工事を避けられます。

まとめ

サイトが重くて離脱される問題への取り組みは、実ユーザーデータで課題を数字にし、指標ごとの原因を切り分け、AIの力で改善を実装して検証するという一本の流れに整理できます。0.1秒の改善が転換率を動かすことは公表データが示しており、現行の物差しはLCP・INP・CLSの3指標、判定は75パーセンタイルのフィールドデータです。原因は画像・JavaScript・レイアウトのずれに大別され、診断結果の読み解きと修正コードの作成は生成AIが大幅に効率化してくれます。まずはPageSpeed Insightsに自社の主要ページを入力し、現状の成績表を確かめるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。