モバイルのLCPが9.1秒。有料のWordPressテーマを使っていた頃の、このブログの実測値です。最初はテーマを疑いもしませんでした。有料テーマなのだから表示速度に問題はないはずで、遅いならサーバーのほうだろうと思っていたんです。
で、結果から書くと、いまこのブログはLCP 2.4秒、PageSpeed 96点で表示されています。対話型AIに実装を任せながらテーマ「Journal」を自作して、切り替えた結果です。不要なJavaScriptは553KBから223KBへ、プラグインは18個から6個まで減りました。
ただ、「自作テーマに変えたから速くなった」と言い切れないのが正直なところです。モバイル表示を2秒以上遅らせていた主な原因は、テーマではなくGoogle AdSenseの自動広告でした。テーマを作り直す過程で、必要な機能と外部スクリプトを一つずつ調べ直せたことが、改善につながったんだと思っています。
9.1秒から2.4秒までに外したもの、残したもの
ブログに必要な機能だけをJournalに入れ、プラグインは18個から6個へ整理した。重いJavaScriptと画像配信を見直し、モバイル描画を遅らせていたAdSenseの自動広告も外した。速くなった理由は自作そのものではなく、読み込んでいるものを一つずつ調べ直したことにある。
有料テーマへの不満は、機能不足ではありませんでした
以前使っていた有料テーマに、機能の不満があったわけではありません。むしろ、使い切れないほど多機能でした。それでも運用を続けるうちに、気になることが3つ出てきました。
- 設定項目が多く、どこで何を変更したのか追いにくい
- 用意されたデザインの枠を越えた変更には、妥協が必要になる
- 有料テーマを使っているのに、PageSpeed Insightsの数値が低い
3つを並べて眺めると、引っかかっていたのは「有料か無料か」ではなく、使わない機能まで読み込まれ、必要な変更を自分で追えないことでした。それなら、ブログに必要な機能だけを持つテーマを作って、どこを、なぜ変えたのかまで自分で追える形にしたほうが扱いやすいはずです。そう考えて、自作へ踏み切りました。
テーマの自作は、AIへの要件出しから始めました
趣味でコードを書くとはいえ、WordPressテーマを一人でゼロから書き上げる時間はありません。なので、必要な機能とその優先順位、公開前に満たす条件までは自分で決めて、実装のたたき台はAIに任せる形にしました。この分け方は、アプリを5つ作ったときと同じです。最初にAIへ渡したのは、コードではなくこの機能リストです。
- 表示機能：ダークモード、追従目次、コードハイライト、シェアボタン、関連記事
- 記事装飾：吹き出し、ボックス、マーカー、内部ブログカード、手順・FAQ・比較のブロックパターン
- SEOと回遊：OGP、構造化データ、投稿別SEO設定、公開日と更新日の分離表示、一元管理CTA
- 運用：キーボード操作、チェックサム付きの自動更新、管理画面からのテーマ更新
リストを眺めると、プラグインでやっていたことのかなりの部分はテーマ側へ移せそうでした。実際、目次、コードハイライト、問い合わせフォームなどはJournalへ取り込み、プラグインは18個から6個になりました。あわせて、データベースもMySQL 5.7からMariaDB 10.5へ移行しています。
120KBのコードハイライトを軽い実装へ替えた
重かった部品も入れ替えています。コードハイライト用のJavaScriptは約120KBあったものを、もっと軽い実装へ替えました。記事一覧のサムネイルも、表示サイズに合った画像を配信する形にしています。
このとき実感したのが、AIへ「軽くして」とだけ頼むと、何をもって完了なのかが曖昧なままだということです。残す機能と測る数値、どの状態を完成と呼ぶかを先に決めておくと、返ってきた実装の確認がずっと楽になりました。
切り替えた直後、記事本文が表示されなくなりました
移行そのものは、すんなり終わりませんでした。テーマを切り替えた直後、HTMLの入れ子が崩れて記事カードのリンクが壊れ、本文が表示されなくなったんです。凝った処理で失敗したわけではなく、複数のHTML要素を組み合わせた箇所で入れ子が崩れていた、それだけの話でした。原因を切り分けて構造を直し、最後は実際のページを開いて表示を確かめました。
もう一つ厄介だったのが、モバイルだけ表示速度が大きく落ちる問題です。冒頭で疑っていたサーバーは、調べてみると原因ではありませんでした。長い記事に広告枠を差し込むGoogle AdSenseの自動広告が、本文の描画を2秒以上遅らせていました。自動広告を外すと、数値は大きく改善しました。
この2件で思い知ったのは、コードが生成できることと、本番で正しく動くことは別だという点です。AIが書いた差分だけを眺めていても、HTML同士の組み合わせや外部スクリプトが実際のページへどう影響するかまでは読み取れません。
遅れていたのはサーバー応答ではなく描画だった
最初に疑ったサーバーは外れでした。PageSpeedの合計点だけを見ず、LCP、不要なJavaScript、外部スクリプトを分けて確認すると、どこで描画が止まっているのかが見えてきます。テーマ、プラグイン、広告をひとまとめにしないことが、切り分けの前提です。
移行前後の実測値
移行の前後で、数値はここまで変わりました。
| 指標 | 移行前 | Journal移行後 |
|---|---|---|
| 表示速度（モバイルLCP） | 9.1秒 | 2.4秒 |
| PageSpeedスコア | 低評価 | 96点 |
| 不要なJavaScript | 553KB | 223KB |
| プラグイン数 | 18個 | 6個 |
これは同じブログを移行したときの実測値で、Journalへ変えればどのサイトでも同じ数字になるという意味ではありません。テーマと一緒に、プラグイン、画像、コードハイライト、広告スクリプトまで見直した結果の数字だからです。
それでも、必要な機能だけに絞ると、読み込むファイルも、何かあったときに確認する場所も減ります。私にとっては、速くなったことと同じくらい、「なぜこのコードがあるのか」を自分で追えるようになったことが、自作へ移って得たものでした。
作って終わりにせず、更新できる形で公開しました
Journalはこのブログ専用にはせず、インストール用のZIPとして公開しています。WordPress 6.4以上、PHP 7.4以上で動き、導入後はWordPressの管理画面からそのまま更新できます。
公開ZIPに加えて、自動更新情報とチェックサムも用意しました。AIとテーマを作っていた時間より、実際のサイトで使いながら直していく時間のほうがずっと長いからです。
公開後のいまも、下書きの投入や画像の設定、公開ページの確認にはAIを使っています。ただ、どこまで確認できたら完了にするかは、変わらず自分で決めています。
振り返ると、9.1秒という数字の前で必要だったのは、高性能な別テーマを探すことではなく、表示を遅くしているものを一つずつ調べて、このブログに要らないものを外すことでした。個人の趣味の時間でそこまでやり切れたのは、実装の多くをAIに任せられたからです。
その結果が、LCP 2.4秒、PageSpeed 96点で動いているいまのこのブログです。不要なJavaScriptは223KBで、プラグインは6個。9.1秒だった頃との一番の違いは、速さの数字そのものより、遅くなったときにどこを見ればいいか分かるようになったことだと思っています。
XserverのWordPress運営をAIで効率化｜任せた作業と人が決めたことXserverのWordPress運営にAIとWP-CLIを使い、15記事のアイキャッチ差し替えや下書き…
