
AI で実施するサイトスピード改善

はじめに
Greria の Web サイトは、企画からデザイン、実装、原稿、公開後の運用まで、AI を前提に作っています。人が決めるのは「何を載せるか」「どう見せたいか」「これで出していいか」。手を動かす部分の多くは、Claude Code を中心とした AI に任せています。9月にリニューアルを公開し、10月に入ってからは検索エンジンと生成 AI の両方から正しく拾われるための整備(meta description、構造化データ、llms.txt など)を順に進めてきました。
その一連の作業の最後に残っていたのが、表示速度です。
最初の計測結果
Google が無料で提供している表示速度の診断ツール、PageSpeed Insights でトップページを測ったところ、結果はこうでした。
| 項目 | スマホ | PC |
|---|---|---|
| パフォーマンス | 62 | 91 |
| ユーザー補助 | 95 | 95 |
| おすすめの方法 | 100 | 100 |
| SEO | 100 | 100 |

PC は問題なく、スマホだけが黄色でした。内訳を見ると、最初の描画(FCP)が 4.3秒、メインの画像が出るまで(LCP)が 7.1秒。Google が目安にしている LCP 2.5秒を大きく超えています。
正直なところ、サイト本体は軽いはずでした。サーバーの応答は 30ミリ秒、HTML は小さく、CSS もひとつだけ。それでも 7秒かかっている。どこで時間を使っているのかを、まず特定する必要がありました。
ここが AI の出番
表示速度の改善でやること自体は、昔から変わりません。計測結果を読み、重いものを見つけ、ひとつずつ直し、また測る。ただ、この「読む」と「直す」の往復に時間がかかります。PageSpeed Insights の中身である Lighthouse のレポートは数百項目のデータ(JSON)で、どれが効いていてどれが些細かを見分けるのに慣れが要りますし、直す側もテンプレート、CSS、プラグイン設定、計測タグと、触る場所がばらばらです。
今回はこの往復を、Claude Code に任せました。レポートの JSON をそのまま読ませて原因を挙げてもらい、修正をローカルで当てて、開発環境で再計測し、本番に反映する。判断が必要なところだけ私が決める、という分担です。
診断で分かった原因は 4つでした。
| 原因 | 中身 |
|---|---|
| Web フォント | Google Fonts の CSS が描画を止めていた。しかもアイコンフォントは全アイコン入りの 324KB のファイルを、10個ほどのアイコンのために毎回読んでいた |
| 画像サイズ | テンプレートが画像 URL を直書きしていて、画面幅に合わせて画像サイズを選ばせる指定(srcset)が無く、スマホにも PC 用の大きい画像を配信していた |
| WebP | 画像最適化のプラグインは入っていたが、JPEG より軽い画像形式(WebP)への変換がオフのままだった |
| 計測タグ | Google タグマネージャー(GTM)と Google アナリティクス(GA4)の処理が、メインの画像の描画を遅らせる要因として計上されていた |
まとめると、本体は速いのに、外から読み込むフォント・画像(サイズと形式)・計測タグの 3種類が足を引っ張っている、という構図です。
ひとつずつ直す
対策も、原因に合わせて 4つです。
フォントは Google Fonts を読むのをやめ、必要な文字とアイコンだけを切り出したフォントファイルを自前で配信するようにしました。アイコンフォントは 324KB から 4.6KB になりました。途中、切り出しから漏れたアイコンが文字のまま表示される(フッターの地球アイコンが「LANGUAGE」と出る)という失敗もあり、これはスクリーンショットで気づいて直しています。
画像は、ブラウザが画面幅に合わせてサイズを選べる形(srcset)で WordPress に出力させるよう、テンプレート側を書き換えました。スマホで最初に目に入るトップページの Mission の画像には優先読み込みの指定を付け、逆に薄く敷いている背景画像は優先度を下げています。
WebP はプラグインの設定を有効にして、既存の画像を一括変換しました。
計測タグは読み込みのタイミングを変えました。最初は「ページの読み込み完了直後」にしたのですが、これだとスコアは 78 止まりでした。内訳を見ると、タグの処理が画像の描画遅延として 4秒以上計上されていました。そこで「最初の操作があったとき、または読み込み完了の 3秒後、のどちらか早い方」に変えたところ、スコアが一気に上がりました。計測が欠けていないことは、画面のないブラウザを自動で動かす方法(ヘッドレスブラウザ)で、実際に計測データが送られているのを見て確認しています。
これらを、計測から本番反映まで同じ日のうちに終えました。
結果
翌朝、同じ PageSpeed Insights で測り直した結果です。
| 項目 | 対策前 | 対策後 |
|---|---|---|
| パフォーマンス(スマホ) | 62 | 98 |
| パフォーマンス(PC) | 91 | 100 |
| FCP(最初の描画) | 4.3秒 | 1.2秒 |
| LCP(メイン画像の描画) | 7.1秒 | 1.8秒 |
| 操作がブロックされる時間 | 200ミリ秒 | 130ミリ秒 |

LCP は 7.1秒から 1.8秒へ。Google の目安である 2.5秒を切りました。
まとめ
今回の作業で感じたのは、表示速度の改善は「知識」より「往復の回数」で決まる、ということです。原因の候補は Lighthouse が教えてくれます。難しいのは、それを読み解いて、直して、測り直すサイクルを何度も回すことです。ここに人の時間を使うと、半日や一日が消えていきます。
AI にレポートを読ませ、修正を書かせ、再計測させると、一往復が数分で済みます。人がやるのは、どの対策を採るか、計測タグをどこまで遅らせてよいか、アイコンが文字になっていないかといった判断と確認です。
Greria が METHOD で書いている「判断は人、作業は AI」は、サイトの表示速度のような地味な領域でこそ効きます。同じ進め方は、お客様のサイトにも使えます。「スコアが低いのは分かっているが、どこから手を付けていいか分からない」という場合は、計測結果を見せていただければ、原因と対策の見立てをお出しします。





