悩み：「サイトが重い」と言われたが、どこから手をつけるべきか分からない
納品して半年ほど経つクライアントから、「最近サイトが重い気がする」という連絡が来た。正直、日々の更新作業でプラグインや画像が積み重なっているのは分かっていたので、いつか来るとは思っていた。
ただ、いざ「表示速度を改善してほしい」と言われると、どこから手をつけるべきか一瞬迷う。画像を圧縮すればいいのか、プラグインを減らせばいいのか、サーバーの問題なのか。原因の切り分けに時間をかけるより、AIに一次診断と改善提案をまとめて任せられないか試してみた。
結論を先に言うと、Google PageSpeed InsightsのAI提案機能は「何を直せば点数が上がるか」を的確かつ具体的に教えてくれて、実装コードまで出してくれるので作業自体はかなり速く終わった。ただし、点数を60点台から80点台まで上げても、クライアントからは「速くなった」という実感の声はもらえなかった。「スコアが上がること」と「体感速度が変わること」は別物だという、当たり前だけど見落としがちな事実に、実際に手を動かしてようやく気づいた。
TOI
点数が20点も上がったのに「別に変わってないですね」と言われたときは、正直へこんだ……
なぜPageSpeed InsightsのAI提案を試したか
2026年現在、PageSpeed InsightsはLighthouseのラボデータとChromeユーザーの実測データ（CrUX）を組み合わせ、AIによる改善提案を自動生成するようになっている。以前は「画像を最適化してください」のような抽象的な指摘だけだったが、今は該当する画像ファイル名や具体的な削減見込み時間まで示してくれる。
評価指標は3つで、
- LCP（Largest Contentful Paint）：メインコンテンツの表示完了までの時間。目標2.5秒以内
- INP（Interaction to Next Paint）：クリックなど操作への反応速度。目標200ミリ秒以内
- CLS（Cumulative Layout Shift）：表示中のレイアウトのガタつき。目標0.1以内
無料で診断でき、非エンジニアでも「サイトのURLを入力してボタンを押すだけ」で使えるので、まずはこれを一次診断ツールとして使ってみることにした。
実際にAI提案通りに直してみた
やった手順
- 「PageSpeed Insights」に対象ページのURLを入力し、モバイル・PC両方で計測
- 「診断」欄に出てくる改善提案を上から確認（AIが優先度順に並べてくれる）
- 提案されたコード例（画像のwidth/height属性追加、フォントのpreload指定など）をコピーして、実際にサイトのテーマファイルに反映
- WordPressのキャッシュプラグイン設定を見直し、再度計測して点数の変化を確認
これを、モバイルスコアが62点だった実際のクライアントサイト（許可を得たうえで）で試した。
AIが速かったこと
指摘の的確さと、対応コードの提示スピードには素直に驚いた。
- 「未使用のCSSを削除すると0.8秒短縮見込み」という具体的な数値付きの指摘
- 圧縮すべき画像ファイルを名指しし、推奨フォーマット（WebP）まで提示
- レンダリングをブロックしているJavaScriptファイルを特定し、defer属性を付けるコード例を出力
- フォントの読み込み順序を変えるためのpreloadタグをそのまま貼り付け可能な形で提示
「何を直せばいいか」の特定と、直すためのコードの用意までを数分でやってくれるのは、これまで手探りでやっていた作業と比べると圧倒的に速かった。実際、モバイルスコアは62点から84点まで上がった。
AIの提案通りにやっても解決しなかったこと
一方で、点数が上がったあとにクライアントへ「速くなりました」と報告しても、「うーん、そんなに変わった感じはしないですね」という反応だった。実際に自分でも改めてサイトを触ってみると、確かに数値上のスコアと、実際にページを見て感じる体感速度は必ずしも一致しないことが分かった。理由を整理すると次の3つだった。
- PageSpeed Insightsが計測しているのはトップページ1枚だけで、クライアントが日常的に見ている下層ページ（お問い合わせ完了ページなど）は未計測のまま点数が悪かった
- 初回訪問時の計測が中心で、キャッシュが効いた2回目以降のアクセス体感とはそもそも条件が違う
- AI提案の中には、既存のカスタムプラグイン（フォーム送信時のアニメーションなど）と競合し、そのままでは適用できない項目があり、結局は手作業で個別に調整する必要があった
つまりAIは「計測対象のページを、AIが認識できる範囲で速くする」ことは得意だが、「クライアントが実際に体感している重さの原因」を特定するには、こちらから対象ページや利用シーンを具体的に指定してあげる必要があった。
TOI
クライアントが「重い」と言っていたのは、実はトップページじゃなくて商品一覧ページだった、というオチ……
結局どこまでAIに任せていいか：パターン別に整理する
やってみて分かったのは、「表示速度改善」と一口に言っても、クライアントが本当に求めているものによって進め方が変わるということだ。
「なんとなく重い気がする」という漠然とした相談の場合
PageSpeed InsightsのAI提案をそのまま適用するだけで、点数もある程度改善するし、対外的な説明としても十分。まずはここから着手して問題ない。
「このページの読み込みが遅くて離脱されている気がする」など具体的な指摘がある場合
トップページだけでなく、実際に指摘された下層ページを個別にAIで診断し直す必要がある。AIに「このサイト全体を見て」と丸投げするのではなく、対象ページを明示してから相談するのがコツだった。
カスタムプラグインや独自の演出（アニメーション・スライダーなど）が多いサイトの場合
AI提案がそのまま適用できないケースが多く、提案を鵜呑みにせず、まず自分でテスト環境で動作確認してから本番に反映する必要がある。ここは結局、人力での検証を省略できなかった。
まとめ
- PageSpeed InsightsのAI提案機能は、改善すべき箇所の特定と具体的なコード例の提示までを数分でこなしてくれる
- 一方で、AIが計測しているのは指定したページの初回アクセス条件のみで、クライアントが実際に「重い」と感じている下層ページや2回目以降のアクセス体感とはズレが生じやすい
- カスタムプラグインとの競合など、提案をそのまま本番反映できないケースもあり、テスト環境での事前確認は省略できない
- 次のアクションとしては、「重い」と言われたら真っ先にトップページを計測するのではなく、まずクライアントに「具体的にどのページで感じたか」をヒアリングしてから、AIに診断してもらう順番に変えると手戻りが減る
コメント