ある日、自社サイトのPageSpeed Insightsを見て愕然としました。デスクトップは問題ないのに、モバイルスコアが57。FCP（First Contentful Paint）が8.7秒、LCP（Largest Contentful Paint）が9.0秒。スマホでページが表示されるまでに約9秒かかっている計算です。
RESONIXはWordPressのJupiter XテーマとElementorの組み合わせでサイトを構築しています。この構成はデザインの自由度が非常に高い反面、何も対策しなければ大量のCSS/JSが読み込まれ、表示速度が犠牲になります。
この記事では、スコア57から97まで改善するために実際に行った施策を、順を追って記録します。
まず原因を特定する
PageSpeed Insightsのレポートを詳しく見ると、最大のボトルネックが明確でした。
レンダリングをブロックしているリクエストが推定10,130ms（約10秒）の遅延を生んでいた。
具体的には以下のCSSファイルが読み込みを止めていました。
- サイト本体のCSS：350.7 KiB / 18,800ms
- frontend.min.css：89.0 KiB / 3,150ms
- ease.min.css：43.7 KiB / 1,950ms
- fontawesome.min.css：12.9 KiB / 600ms
- Jupiter X関連CSS：21.9 KiB / 900ms
- Elementor系のアニメーションCSS多数（wobble, grow, shrink, rotate, buzz-outなど）
さらに、未使用CSSが242 KiB、未使用JavaScriptが342 KiBも検出されました。合計600KB以上の「使っていないのに読み込まれているコード」がモバイル表示を圧迫していたわけです。
Jupiter X + Elementorの構成では、テーマとプラグインの両方が自前のCSS/JSを大量に持っており、実際にそのページで使っていない機能のスクリプトまで全部読み込みます。これがこの構成の構造的な弱点です。
施策1：キャッシュプラグインをWP Rocketに変更
当初はWP Fastest Cacheを使っていました。基本的なキャッシュ機能は問題ないのですが、無料版では「レンダリングブロックJSの遅延」や「Lazy Load」がPremium機能となっており、今回の問題の核心部分に手が届きませんでした。
WP Rocketに乗り換えた理由は、CSS/JSの最適化機能がElementorとの相性が良く、一つのプラグインで以下の機能がすべてカバーできるからです。
- CSSファイルの結合
- 未使用CSSの削除（Remove Unused CSS）
- CSSの遅延読み込み（Load CSS Asynchronously）
- JavaScriptの遅延実行（Delay JavaScript execution）
- Lazy Load（画像の遅延読み込み）
- ブラウザキャッシュ
注意点として、キャッシュ系プラグインの併用は厳禁です。 WP Rocketを入れる前に、WP Fastest CacheやAsset CleanUp: Page Speed Boosterなどは必ず無効化・削除してください。キャッシュプラグインが複数動いていると競合して、逆に表示がおかしくなります。
施策2：WP Rocketの設定を最適化する
WP Rocketをインストールしただけでは十分な効果は出ません。以下の設定を有効にしました。
「ファイルの最適化」セクション
- CSSファイルの結合：有効
- 未使用CSSの削除（Remove Unused CSS）：有効
- CSSの遅延読み込み：有効
- JavaScriptの遅延実行：有効
「メディア」セクション
- Lazy Load（画像）：有効
「先読み」セクション
- サイトすべてのキャッシュを自動的に作成：有効
この時点で、レンダリングブロック時間がデスクトップで2,620ms → 680msに大幅改善しました。
施策2.5：未使用CSS削除でレイアウトが崩れた問題
ここで一つトラブルが発生しました。
WP Rocketの「Remove Unused CSS」を有効にしたところ、ヘッダー右側のソーシャルアイコンが横並びから縦並びに崩れてしまったのです。
原因は、WP Rocketがアイコンのレイアウト用CSSを「このページでは使われていない」と誤判定して削除してしまったことでした。Jupiter X + Elementorの環境では、動的に適用されるCSSクラスがWP Rocketの解析時には「未使用」と見なされることがあります。
解決方法は、CSS safelistへのセレクタ追加です。
WP Rocketの設定画面で「未使用CSSの削除」のsafelist欄に、崩れていた要素のCSSクラスを追加しました。該当するクラスはブラウザのDevTools（右クリック→「検証」）で特定できます。
この環境で関係していたのは以下のようなクラスでした。
.jet-floating-elements
.elementor-icon-list-items教訓：「未使用CSS削除」は効果が大きい反面、有効化後は必ず全ページをスマホ・PCの両方で目視確認すること。 Jupiter X + ElementorではCritical CSSの生成がうまくいかないケースがあるため、ページごとのチェックが必須です。
もし複数箇所で崩れが多発して手に負えない場合は、「Remove Unused CSS」ではなく「Load CSS Asynchronously」に切り替えるという手もあります。CSSを削除せず非同期で読み込むだけなので崩れにくいですが、その分パフォーマンス改善効果は若干落ちます。
施策3：Elementor側のパフォーマンス設定
WordPress管理画面 → Elementor → 設定 → パフォーマンスタブで以下を確認・変更しました。
有効にしたもの
- Googleフォントをローカルで読み込む：外部へのリクエストが減り、GDPR対応にもなる
- エレメントキャッシュ：Elementorウィジェットの出力をキャッシュ
すでに有効だったもの（そのまま維持）
- 画像読み込みの最適化
- Gutenbergの読み込み最適化
- 背景画像の遅延読み込み
なお、以前のElementorにあった「改善されたアセット読み込み」という設定項目は、バージョンアップに伴いUIが変わり、名称が変更されたり機能が分散配置されています。「あの設定どこ行った？」と迷った場合は、パフォーマンスタブの各項目を一つずつ確認してみてください。
施策4：functions.phpでの不要スクリプト排除
WordPressの子テーマのfunctions.phpに以下のコードを追加して、不要なスクリプトの読み込みを止めました。
reCAPTCHAをお問い合わせページだけに限定
Contact Form 7を使っている場合、reCAPTCHAのスクリプト（約1,071 KiB）が全ページで読み込まれます。お問い合わせページ以外では不要なので、条件分岐で制限しました。
add_action('wp_enqueue_scripts', function() {
if (!is_page('contact')) {
wp_dequeue_script('google-recaptcha');
wp_deregister_script('google-recaptcha');
}
});※ 'contact' の部分はお問い合わせページのスラッグに合わせてください。
dashiconsの非ログインユーザー向け無効化
管理バー用のdashiconsフォントは、ログインしていない一般訪問者には不要です。
add_action('wp_enqueue_scripts', function() {
if (!is_user_logged_in()) {
wp_deregister_style('dashicons');
}
});施策5：Font Awesomeの見直し
PageSpeedレポートで12.9 KiBのfontawesome.min.cssが600msブロックしていることがわかっていました。
Elementorの設定でFont Awesomeの読み込み方式を変更できます。サイト内で実際にFont Awesomeアイコンを使っている箇所が少なければ、「なし」か「SVGインライン」に切り替えることで読み込み量を削減できます。
最終結果
すべての施策を適用した後のPageSpeed Insightsスコアがこちらです。
| 指標 | 改善前 | 改善後 |
|---|---|---|
| モバイルスコア | 57 | 96〜97 |
| デスクトップスコア | ― | 100 |
| SEOスコア | 100 | 100 |
| アクセシビリティ | ― | 緑（合格圏） |
| レンダリングブロック（デスクトップ） | 2,620ms | 680ms |
| LCP | 9.0秒 | 2.4秒以下 |
| INP | ― | 67ms（良好） |
そして最も重要なのは、Core Web Vitals（実ユーザーデータ）がすべて合格圏に入ったことです。
PageSpeedスコアとSEOの関係について
ここで一つ、率直にお伝えしたいことがあります。
PageSpeedのスコア（Lighthouseが算出するシミュレーション値）は、実はSEOランキングにほぼ直接的な影響を与えません。Googleが順位判定に使っているのは、CrUX（Chrome User Experience Report）の実ユーザーデータ、つまりCore Web Vitals（LCP、INP、CLS）です。
レポート上部に表示される「実際のユーザーの環境で評価する」のセクションが合格していれば、Lighthouseスコアが70だろうが90だろうが、SEO上の差はほぼありません。
ただし、モバイル表示に9秒かかるサイトは、SEO以前にユーザーが離脱します。速度改善はSEOのためだけではなく、来てくれた人をちゃんと迎えるための施策です。
Jupiter X + Elementorの限界を知った上で
正直に言えば、Jupiter X + Elementorという構成には表示速度の面で構造的な限界があります。テーマとプラグインが持つCSS/JSの総量が多く、使っていない機能のスクリプトまで読み込まれる設計になっているからです。
GeneratePressやAstraのような軽量テーマに変えれば、もっと楽にスコアは出ます。ただ、Jupiter X + Elementorのデザインの自由度は魅力的で、クライアントのブランディング要件を満たすには最適な選択肢でもあります。
大切なのは、「このテーマだから遅い」と諦めるのではなく、この構成の中でどこまで最適化できるかを知ることです。今回の施策で、Jupiter X + Elementor環境でもモバイルスコア97、Core Web Vitals全項目合格まで持っていけることが実証できました。
まとめ：効果が大きかった施策トップ3
- WP Rocketの「未使用CSS削除」と「CSS遅延読み込み」 … これだけでFCP/LCPが数秒改善。ただしレイアウト崩れの確認は必須。
- functions.phpでのreCAPTCHA読み込み制限 … 1MB超のスクリプトを不要なページから排除。
- Elementorのパフォーマンス設定（Google Fontsローカル読み込み、エレメントキャッシュ） … 外部リクエストの削減。
月額数千円のWP Rocketと、functions.phpへの数行の追記。大きな投資をせずとも、正しい箇所に正しい対策を打てばここまで改善できます。
「うちのサイトも遅いかもしれない」と思った方は、まずPageSpeed Insightsで現状を確認してみてください。
この記事はRESONIXが自社サイトで実際に行った改善の記録です。WordPress × Elementor環境での表示速度にお悩みの方は、お気軽にご相談ください。
