Luccaの高速化設定を
安全に調整する

Lucca 1.0.13の高度な設定には、Twigキャッシュ、フロントjQuery無効化、FontAwesomeの読み込み方法、WordPressコアCSS最適化があります。既定値はTwigキャッシュが有効、フロントjQuery無効化が有効、FontAwesomeはCDN、コアCSS最適化はオフです。速度改善では、この既定値を基準に一項目ずつ比較します。

高速化は、すべての機能を無効にすれば成功するわけではありません。削減できた通信量よりも、読者が目的の情報へ早く到達できるか、フォームやメニューが確実に動くかを優先します。そのため、数値、見た目、操作の三つを同じ条件で比較します。

変更前に基準値を残す

ログアウト状態で、トップ、投稿、問い合わせなど代表的な3ページを測ります。PageSpeed Insightsの点数だけでなく、LCP、CLS、操作できるまでの時間、コンソールエラー、見た目の崩れを記録します。キャッシュの有無で結果が変わるため、同じURLを同じ条件で複数回測り、中央値を比較します。

代表ページはテンプレートの違いで選びます。トップが速くても、画像の多い投稿やフォームを含む固定ページが遅ければ、読者の体験は改善していません。アイキャッチあり・なし、ブロック数の多い記事、外部埋め込みを使う記事など、サイト内で負荷の高いページも一つ含めます。

測定時には、日時、端末、URL、キャッシュ状態、変更した設定を記録します。点数はネットワーク状況で揺れるため、一度の結果だけで判断しません。変更前後を同じ方法で3回程度測り、体感でも差があるかを確認すると、意味のない調整を残しにくくなります。

Twigキャッシュ

Twigキャッシュはテンプレートのコンパイル結果を再利用します。本番では有効が基本です。テンプレートや子テーマを編集中に変更が見えない場合は、キャッシュディレクトリの書き込み権限とキャッシュ削除を確認します。「高速化したのに古い表示になった」というとき、ブラウザキャッシュだけでなくTwig側も切り分けるのがポイントです。

本番環境でキャッシュを無効にしたままにすると、同じテンプレートを表示するたびに余分な処理が増えます。一方、制作中はコードを直しても古い結果が残ると、修正が反映されていないように見えます。開発時と公開時で設定を分け、公開前に有効へ戻したことをチェック項目に入れます。

表示が更新されない場合は、Twig、WordPressのページキャッシュ、CDN、ブラウザの順に層を分けて確認します。すべてを同時に削除すると一時的には直っても原因が分かりません。どのキャッシュを消したときに変化したかを記録すると、次回の更新が短時間で済みます。

フロントjQuery無効化

Lucca本体のフロント処理はjQueryに依存しないため、既定ではjQueryを読み込みません。ただし、プラグインや子テーマのJavaScriptがjQueryを前提にしていると、スライダー、フォーム、モーダルなどが動かなくなることがあります。無効化を維持するかは、主要操作とブラウザのコンソールを確認して判断します。不具合があればこの設定だけを戻して再確認します。

依存の有無は、ページを眺めるだけでは分からないことがあります。メニューの開閉、検索、画像ギャラリー、目次、フォームの入力補助、確認画面への遷移など、JavaScriptが動く操作を実際に試します。コンソールにjQuery is not definedや$ is not definedが出る場合は、プラグインまたは子テーマの依存を疑います。

jQueryを戻すと直る場合でも、直ちにプラグインを削除する必要はありません。まずその機能がサイトに必要か、代替機能があるか、プラグイン側で読み込み方法を変更できるかを確認します。互換性を優先して読み込みを残す判断も正しく、数十KBの削減だけを目的に重要な操作を不安定にしないことが大切です。

jQuery設定の読み違いに注意：「フロントjQuery無効化」をオフにすると、無効化処理が止まります。コードではjquery、jquery-core、jquery-migrateの登録と読み込みを解除しているため、依存するプラグインのスクリプト自体が読み込まれなくなる場合もあります。コンソールにエラーがなくても、フォームの送信まで試してください。チェックを外す操作はjQueryを必ず追加する操作ではなく、必要なプラグインが通常どおり要求できる状態へ戻す操作です。

FontAwesomeの読み込み

CDN読み込みは多数のアイコンを使う場合に便利ですが、外部接続とCSSが増えます。アイコンを使っていない、またはモバイルDockをカスタムSVGだけで構成している場合は「読み込まない」を試せます。変更後はヘッダー、SNS、Dock、ウィジェットを確認し、文字化けした四角や空白がないか探します。

棚卸しでは、トップページだけでなく投稿末尾のシェアボタン、404、検索結果、サイドバーも確認します。普段は表示しないメニューや、ログインしていない利用者だけに出る要素でアイコンが使われている場合があります。CSSのクラス名にfa-があるかを検索する方法も補助になります。

読み込みを止めて問題がなければ、変更前後の通信リクエスト数と転送量を比較します。外部CDNを減らす効果は環境によって異なるため、数字がほとんど変わらない場合は、将来アイコンを追加する運用の分かりやすさも含めて判断します。

コアCSS最適化

WordPress本体が出力するCSSを削減する設定です。ブロックやプラグインはコアCSSを前提にする場合があるため、既定ではオフです。利用中のブロックを洗い出さずに強くすると、管理画面のプレビューでは分からない部分だけ崩れることがあります。投稿本文、ギャラリー、検索フォーム、コメント、埋め込みを含むページで確認してください。

特に注意したいのは、普段使わないブロックを含む過去記事です。新しい記事だけ確認すると、引用、テーブル、ボタン、カラム、画像キャプションなどのスタイル不足を見逃します。アクセス数の多い記事と、ブロック種類の多い記事をテスト対象へ加えます。

最適化後は、画面幅を変えながら余白、横スクロール、文字の重なりを見ます。表示崩れが一箇所でも出た場合、追加CSSで症状だけを直す前に設定を戻して比較してください。削減効果が小さいなら、既定のオフを維持する方が更新時の互換性を保ちやすくなります。

コアCSS最適化の選択肢は「無効（標準）」「安全な範囲で削減」「積極的に削減（上級者向け）」です。「安全な範囲」という名称でも、すべてのプラグインとの互換性を保証するものではありません。まず一段階だけ変更し、既存記事のブロック表示を比較します。

安全な調整順

測定結果を判断するための記録例

以下は数値を記入するためのひな形です。未測定欄を実際の結果で埋め、同じ端末条件で比較します。初回アクセスとキャッシュが温まった状態は別の行で扱います。

変更前後の値が大きく重なる場合は改善を断定しません。点数が上がっても必要なアイコンが消えた場合は採用を見送ります。測定条件の読み方はPageSpeed Insightsの公式説明も確認してください。

複数の設定を同時に変えると、改善した理由も壊れた理由も判別できません。次の順番で一項目ずつ変更し、測定と操作確認が終わってから次へ進みます。

合格条件も先に決めます。「LCPが改善し、主要操作にエラーがなく、レイアウト差分がない」のように、数値と品質の両方を条件にします。改善幅が測定誤差に収まる設定は無理に残さず、構成を単純に保つことも高速化の一部です。

まとめ

Luccaでは、TwigキャッシュとjQuery非依存という土台が既定で有効です。追加の削減はサイト構成によって効果が変わるため、既定値を出発点に、計測できる改善だけを残します。

テーマ設定だけで変化が小さい場合は、画像容量、サーバー応答、外部スクリプトの影響も確認してください。全体の切り分けはWordPress表示速度改善の基本で整理しています。