このブログ（著者サイト）では、複数の要因を見直した結果としてモバイルLCPが9.1秒から2.4秒になりました。AIで自作したテーマ単独の効果でも、ほかのサイトで同じ値を再現できるという話でもありません。
有料テーマを使っていた頃の記録では、移行後にPageSpeed 96点、不要なJavaScript 553KBから223KB、プラグイン18個から6個という変化がありました。テーマをJournalへ切り替えたことに加えて、プラグイン、画像、コードハイライト、広告スクリプトも見直しています。
この記録には、測定日時、どのURLのどの画面を測ったか、端末・ネットワーク・地域、ログイン状態とCookie、広告とキャッシュの状態、ラボ測定かフィールド測定か、反復回数、LCP要素、JavaScriptの計測方法が残っていません。したがって、9.1秒から2.4秒という値を現在の再測定値や、AIテーマの一般的な効果として扱うことはできません。
私のサイトでは、モバイル表示を2秒以上遅らせていた主な原因はテーマではなくGoogle AdSenseの自動広告だった、と記録しています。自動広告を外すと数値は大きく改善しましたが、これはこのサイトでの体験です。テーマ自作、AdSense、プラグインのどれか一つだけが、どのサイトでも同じ結果を生むとは判断していません。
LCPは何を測る数字か
LCP（Largest Contentful Paint）は、ページの読み込みを始めてから、画面内で最大の画像・テキストブロック・動画が描画されるまでの時間です。接続確立、リダイレクト、サーバーの応答なども含まれるため、測定面をそろえない数字は比べにくくなります。定義と測定対象は、web.devのLCP解説で確認できます。
目安として、モバイルとデスクトップを分けたページロードの75パーセンタイルで、LCP 2.5秒以下が示されています。これは実ユーザーの分布に対する基準であり、1回のラボ測定が2.5秒以下だったことだけで、サイト全体が基準を満たしたとは言えません。
ラボデータは、決めた端末やネットワークの条件で読み込む制御環境の値です。同じ条件で繰り返し、変更の影響を調べるのに向いています。フィールドデータは、実ユーザーの端末、回線、地域などを含む訪問ごとの分布です。期間と分布を持つため、単一のラボ結果を訪問者全体の75パーセンタイルと読み替えられません。両者の違いは、web.devのラボデータとフィールドデータの説明にも整理されています。
自作を考えた理由は、有料かどうかではなかった
以前の有料テーマに機能が足りなかったわけではありません。使い切れないほど多機能だった一方で、設定項目が多く、どこで何を変更したのか追いにくい状態でした。用意されたデザインの枠を越える変更にも妥協が必要で、PageSpeed Insightsの数値も低いままでした。
- 使わない機能まで読み込まれ、影響する場所を追いにくい
- 必要な表示だけを残したいのに、テーマの枠に合わせる必要がある
- 遅さを感じても、テーマ、プラグイン、広告のどこを見るべきか分けにくい
そこで、ブログに必要な機能だけを持たせ、どこをなぜ変えたのか自分で追える形を目指しました。ここでの判断は、速いテーマへ交換すれば解決するという意味ではありません。何が読み込まれているかを切り分けられる状態を作ることが、自作を検討した理由でした。
AIには実装のたたき台を任せ、残す機能と測るものを決めた
WordPressテーマをゼロから書く時間には限りがあったため、必要な機能と優先順位、公開前に確認する条件は自分で決め、実装のたたき台をAIに任せました。表示機能、記事の装飾、構造化データ、キーボード操作、更新方法など、残すものを先に並べ、AIへ単に軽くしてと頼むだけにしないようにしました。
実際に、目次、コードハイライト、問い合わせフォームなどをJournal側へ取り込み、プラグインは18個から6個になりました。コードハイライト用のJavaScriptも約120KBあったものを、より軽い実装へ替えています。記事一覧のサムネイルは表示サイズに合った画像を配信する形へ見直しました。
この作業で分かったのは、軽さを求めるなら、残す機能と測る数値、完成と呼ぶ状態を先に決める必要があることです。JavaScriptの量だけ減っても、本文やリンクが壊れたり、キーボード操作や構造化データが失われたりすれば、サイトとしては改善したことになりません。
切り替え直後には、HTMLの入れ子崩れで本文が消えた
移行はすんなり終わりませんでした。テーマを切り替えた直後、HTMLの入れ子が崩れて記事カードのリンクが壊れ、本文が表示されなくなりました。原因を切り分けて構造を直し、最後は実際のページを開いて表示を確かめています。コードが生成できることと、既存の本文やリンクを含む本番ページで正しく動くことは別でした。
もう一つの問題は、モバイルだけ表示速度が大きく落ちることでした。最初に疑ったサーバーは、私の調査では原因ではありませんでした。長い記事へ広告枠を差し込むGoogle AdSenseの自動広告が本文の描画を2秒以上遅らせていた、というのがこのサイトでの記録です。別のサイトで広告を外せば同じ改善になる、という意味にはなりません。
AIが書いた差分だけを眺めても、複数のHTML要素の組み合わせや、外部スクリプトが実際のページへ与える影響までは分かりません。変更後に本文、リンク、広告、表示速度を同じ条件で確認する工程が必要でした。
移行前後の数値は、このブログの記録として読む
移行前後に残っている値は次のとおりです。測定条件が記録されていないため、差分の大きさから一般的な改善率を計算したり、テーマだけの効果を比較したりはしていません。
| 指標 | 移行前 | Journal移行後 |
|---|---|---|
| 表示速度（モバイルLCP） | 9.1秒 | 2.4秒 |
| PageSpeedスコア | 低評価 | 96点 |
| 不要なJavaScript | 553KB | 223KB |
| プラグイン数 | 18個 | 6個 |
9.1秒から2.4秒への変化は、テーマの切り替えと同時に、広告、プラグイン、画像、コードハイライトなどを見直した結果です。この表から確実に言えるのは、このブログでは複数の変更後にこの値が記録されたことまでです。AIでテーマを自作すれば同じ値になる、という結論は出せません。
自分のサイトでは、まず同じ条件で3回測る
自作テーマを検討する前に、原因を一つずつ切り分けます。本番を直接変更せず、バックアップを取ってステージングまたは検証環境を用意してください。
1. URLと測定条件を記録する。測るURLを同じ記事またはトップページの一つに決めます。変更前後は同じ測定用の実行環境で測り、Lighthouseの実行時に表示されたUI上の項目名と値（version、device／category preset、throttlingなど、選択できる設定）を記録して、ベースラインから各要因まで同じにします。端末、OS、browser version、地域、測定日時などは、測定者が操作できる設定と、操作できず実行時に観測する環境条件を分けます。操作できない環境条件は「固定できる」と断定せず、各回の観測値として記録します。ログイン状態、Cookie、広告、キャッシュは検証環境で操作できる設定と、操作できず観測する環境条件を分け、どちらかを各回の記録へ明示します。ラボとフィールドを同じ欄の数字として扱わず、条件が変わったままの数字は変更の影響なのか測定条件の違いなのかを分けられません。
2. ラボのベースラインと各条件を少なくとも3回ずつ測る。ラボの比較ツールはLighthouse一つに固定します。実行時に表示されたLighthouseのversion、device／category preset、throttlingなどの選択可能な設定を記録し、変更前後のベースラインと各条件で同じ値にします。同じ測定用の実行環境で、まず何も変えないベースラインを少なくとも3回測ります。続いて外部スクリプト、プラグイン、広告、テーマを一つの要因ずつ変更した各条件も、同じURL・同じLighthouse設定・同じ実行環境で少なくとも3回測ります。端末、OS、browser version、地域、ログイン、Cookie、広告、キャッシュ、日時などは、操作できる設定と、操作できず観測・記録する環境条件を分け、各回の実測値を同じ表へ残します。各回はLCP、LCP要素、主なJavaScriptと外部リクエスト、本文、リンク、フォーム、広告、同意表示の状態を一行ずつ並べます。PageSpeed InsightsはLighthouseの変更前後スコアと比較せず、field dataを確認できる場合だけ、対象期間、分布、75パーセンタイルをラボ欄とは別に記録します。
3. 外部スクリプトを一つずつ止める。第三者スクリプトの影響を調べる方法は、web.devの第三者JavaScript測定手順にも示されています。ベースラインへ戻した状態から、検証環境で一つのURLまたはドメインだけを一時的にブロックし、同じURL・同じLighthouse設定・同じ実行環境で少なくとも3回再測定します。各回はベースラインと同じ表へ、LCP、LCP要素、主なJavaScriptと外部リクエスト、本文、リンク、フォーム、広告、同意表示の状態を一行ずつ並べます。測定後はブロックを解除して元の条件へ復戻し、復戻しを確認してから次の要因へ進みます。複数の変更を重ねた結果を単独要因の効果として扱いません。ブロックは診断のための操作なので、本番の機能、収益、同意表示をそのまま失わせる変更にはしません。
4. プラグインを一つずつ確認する。外部スクリプトを元の条件へ戻したことを確認してから、プラグインを一つだけ停止し、同じURL・同じLighthouse設定・同じ実行環境で少なくとも3回測ります。各回はベースラインと同じ表へ、LCP、LCP要素、主なJavaScriptと外部リクエスト、本文、リンク、フォーム、広告、同意表示の状態を一行ずつ並べます。測定後はそのプラグインを元へ戻し、前の条件へ復戻したことを確認してから次のプラグインへ進みます。停止によって本文、フォーム、ログインなどが壊れた場合や、複数の変更が重なった場合は、その結果を単独要因の効果として採用せずに戻します。プラグイン数を減らすこと自体を目的にせず、どの機能と負荷が変わったかを記録します。
5. 広告を一つの要因として切り分ける。プラグインを元の条件へ戻したことを確認してから、AdSenseなどの広告スクリプトや自動広告を一つだけ一時的に止め、同じURL・同じLighthouse設定・同じ実行環境で少なくとも3回測ります。各回はベースラインと同じ表へ、LCP、LCP要素、主なJavaScriptと外部リクエスト、本文、リンク、フォーム、広告、同意表示の状態を一行ずつ並べます。LCPだけでなく、広告の表示、同意表示、収益に関わる機能の状態も残します。測定後は広告を解除して元の条件へ復戻し、前の条件を確認してから次の要因へ進みます。改善しても、それはその条件で広告を止めた結果です。複数の変更を重ねた結果を単独要因の効果として扱わず、広告が原因だと一般化せず、本番へ反映するかは別に判断します。
6. 最後にテーマを検証する。広告を元の条件へ戻したことを確認してから、テーマを切り替える場合は、ステージング上で子テーマまたは最小構成のテーマを一つの条件ずつ試し、同じURL・同じLighthouse設定・同じ実行環境で各条件を少なくとも3回測ります。各回はベースラインと同じ表へ、LCP、LCP要素、主なJavaScriptと外部リクエスト、本文、リンク、フォーム、広告、同意表示の状態を一行ずつ並べます。WordPress公式のテーマ解説では、テーマがテンプレートをコンテンツへ統合してHTML・CSS・JavaScriptを生成し、子テーマは親テーマを直接変更せずに拡張して親の更新を受けやすくすると説明されています。テーマが生成するHTML・CSS・JavaScript・リクエストは性能と機能に関わるため、更新・保守の見通しと一緒に採用を判断します。AIが生成したテーマの本番適合までは保証されないため、速度だけで採用を決めません。
再測定では、速さとサイトの機能を同時に確認する
- 速度：同じLighthouse設定で測ったLCP、LCP要素、Lighthouseのラボスコアを変更前後で残します。
- 読み込み：JavaScriptの量と主な外部リクエストがどう変わったかを記録します。
- 表示と操作：本文、リンク、フォーム、キーボード操作、モバイルとデスクトップの表示を確認します。
- 構造と保守：構造化データが失われていないか、更新と保守を続けられるかを確認します。
一要因を変えても改善しない、重要な機能が壊れる、アクセシビリティやレスポンシブ表示が欠ける、構造化データが失われる、更新・保守の見通しが立たない。このどれかに当たる変更は、バックアップから戻します。確認していない項目を合格と書かず、テーマ自作の採用理由にも使いません。
AIテーマを採用する条件と、見送る条件
自作を候補にしてよいのは、同じ条件の測定で原因を一つずつ確かめ、既存テーマや子テーマの範囲では必要な変更を追いにくいと分かった場合です。その場合も、バックアップから戻せるステージングで、最小構成から確認します。本文、リンク、キーボード操作、レスポンシブ表示、構造化データ、更新、保守を確認し、未確認の項目があれば採用済みとは扱いません。
見送る判断になるのは、テーマを変えても同じ条件で改善しない場合、外部スクリプト・プラグイン・広告の切り分けで原因が見えている場合、本文やリンクなどの機能を戻せない場合、または更新と保守を続ける方法が決まっていない場合です。原因がテーマ以外なら、そこだけを見直して既存テーマを使い続けるほうが、変更範囲を増やさずに済みます。
このブログの9.1秒から2.4秒という記録は、テーマ自作の答えではなく、遅さの原因を一つずつ調べるきっかけでした。まず同じURLと条件でベースラインを取り、外部スクリプト、プラグイン、広告、テーマの順に一つずつ検証してください。その結果と機能・保守の確認を並べれば、自作するか、既存テーマや子テーマで直すか、変更を戻すかを自分のサイトの条件で判断できます。
