WordPressを速くしたいときは、スコアより先に、どの表示が遅れているかを確認しましょう。原因が画像かJavaScriptか応答時間かによって、試す設定が変わるためです。当サイトではConoHa WINGとSWELLの一環境でPageSpeed Insightsが70から100になりました。以下は成功・失敗を含む当時の記録で、同じ結果を保証する設定集ではありません。
自分のサイトへ応用するときは、まず測定対象のURLとモバイル・PCの条件をそろえてください。
スコアは一回の数値だけで判断せず、詳細に出る遅延要因も確認します。今回の記録では、最初にLCPへ注目しました。
そこからが苦闘の始まりでした。
何が足を引っ張っているのか？ プラグインの干渉か？ それとも設定ミスか？
原因を徹底的に追求し、仮説と検証を繰り返すこと2週間。 やっとの思いで、この画面にたどり着くことができました。
変更した内容だけでなく、効果が分からなかった点や表示が崩れた試行も残しています。試す場合は、一度に一項目ずつ変え、戻せる状態で確認してください。
- 画像を圧縮してもスコアが伸びない
- 高速化プラグインを入れたら表示が崩れた
- 結局、どの設定が正解なのか知りたい
今回私は2週間にかけて改善に徹した内容をまとめて、この記事にしました。
最初から設定をすべてコピーせず、自サイトのレポートで同じ問題が起きている箇所を選んで読んでください。
ConoHa WINGなのに遅い？ 絶望のスコア70点
まずは現状把握からスタートです。
「体感速度は悪くないのに、なぜスコアが低いのか？」
PageSpeed Insightsの詳細レポートを開き、赤い警告が出ている項目をチェックしました。
すると、ある一つの指標が致命的に悪いことが判明しました。
LCP（Largest Contentful Paint）：5.8秒
LCPは、最初の画面にある大きな画像やテキストなどが描画されるまでの時間を示す指標です。対象は必ずしもヘッダー画像とは限りません。GoogleのLCP解説で定義を確認できます。
私のブログの場合、トップページの一番上にある「メインビジュアル（スライドショー）」がこれに当たります。
この計測では、主な表示要素が出るまで時間がかかっていました。対象要素を確認してから、画像と表示処理を分けて見直しました。
犯人は「メインビジュアル」だった
当時の私は、SWELLの「記事スライダー」機能を使い、高画質な写真を3枚スライドさせていました。
綺麗な写真を見せたい一心で、PNG画像をそのままアップロードしていたのです。
「画像が重すぎるのが原因だ」
そう確信した私は、まず「画像のダイエット」から着手することにしました。
【検証1】救世主プラグイン「CompressX」の導入
画像をそのままアップロードして利用すると、サイトが重くなる。
これは聞いたことがあり、Tiny PNGなどで圧縮してアップロードしている方も多いのではないでしょうか？
目安にはなりますが、圧縮すると画像の容量が大幅に削減することができます。
| 元の形式 | 変換候補 | 容量の比較 | 確認する点 |
| JPG | WebP・AVIF | 同じ表示サイズ・許容できる画質で実ファイルを比較 | 写真の輪郭や細部が崩れていないか |
| PNG | WebP・AVIF | 変換後に軽くなるとは限らないため元画像とも比較 | 透過、細い文字、ロゴの輪郭を確認 |
| WebP | AVIF | 再変換の効果がある画像だけ採用 | 容量だけでなく画質と配信環境を確認 |
有料級の圧縮率！なぜ有名プラグインではなく「CompressX」なのか
まず疑ったのは、トップページで大きく表示している「メインビジュアル」の画像サイズです。
多くのブロガーは「EWWW Image Optimizer」や「Converter for Media」といった有名プラグインを使っています。 私も最初はこれらを検討しました。
しかし、ここで壁にぶつかります。
AVIFやWebPの利用条件はプラグインとサーバー環境で異なります。形式だけで決めず、変換できるか、画質と容量が適切かを確認します。
そこで、当時の環境で画像を変換できる手段としてCompressXを試しました。
それが「CompressX」です。
また、このプラグインを選んだ理由は、以下の2つの機能が「無料」で使える点に尽きます。
- AVIF変換が無料: CompressXはWebP・AVIFへの変換と圧縮に対応。サーバー上で利用できるか、まず少数の画像で確認する。
- 変換後の容量を確認できる: 元画像より大きくなった変換画像を自動削除する機能がある。採用した形式が実際に配信されているかも確認する。
画像最適化は、元画像を残して少数から試します。写真、透過画像、文字入り画像を1枚ずつ選び、容量だけでなく細部とスマホでの表示を比べると、まとめて処理してよい条件を判断できます。生成された形式と実際に配信される形式も確認し、表示が変わらない原因と画質の問題を分けてください。
実際に、メインビジュアルに使っていた画像を処理してみたところ、
アップロードしたオリジナル画像に対して、
- Webpに圧縮した場合：34.11％の削減
- AVIFに圧縮した場合：48.74％の削減
という風に圧縮率がわかり、圧縮率が高い方を自動的に表示してくれます。
当時の確認では見た目を保てた画像もありましたが、文字入り画像や細部は別に確認が必要です。容量だけを基準に画質を下げないようにします。
PNGからJPGへ、元画像のアップロード形式も見直そう
アップロードする際に美しく見せようとしすぎていて、全てPNGでアップロードしていました。
写真は表示幅に合わせてサイズを調整し、当時はJPGへの差し替えも行いました。透過や細かな文字が必要な画像ではPNGが適することもあるため、一律には変換しません。
【施策2】「足かせ」を外す、断捨離したプラグインと設定
自分のサイトを確認していくと、不要なJavascriptがたくさん裏で読み込まれており、遅延に繋がっていることがわかりました。【施策2】では不要なプラグインの削除と、コードスニペットを利用した先読みの対策をご紹介していきます。
Site Kit by Googleの削除（SWELL標準機能へ移行）
当時はSite Kitの利用方法を見直しました。すべての環境で重いと断定するのではなく、読み込む計測機能と管理上の利点を分けて判断します。
既に導入されている、SEO SIMPLE PACKの設定に、認証コードとGA4のIDを埋め込み、
Googleアナリティクスとサーチコンソールの数値の確認は、ページをブックマークし、直接確認するようにしました。
右クリック禁止プラグインの削除（JS負荷の軽減）
コピー防止プラグインも見直しました。追加した処理の量と、必要な操作まで制限していないかを確認するためです。
右クリックを制限しても転載を完全には防げません。当サイトでは、読者の操作と管理の負担を考え、利用をやめる選択をしました。
ConoHa WING「WEXAL」の無効化
ConoHa WINGでサーバーを契約していると、高速化設定の「WEXAL」を無料で利用することができます。
当時の検証では、高速化設定の重複を切り分ける必要がありました。現在の各製品で同じ競合が起きるとは限りません。
SWELLとWEXALを併用する場合は、遅延・最適化・キャッシュをどちらで管理するか確認します。一つずつ設定を変えて表示と測定値を比較してください。
不要なPreload（先読み）記述の削除
画像の遅延読み込みは、最初の画面で必要な画像にも適用されていないか確認します。
今回の環境では、メイン画像の読み込み順も確認対象にしました。
遅延読み込みを除外するコードを試した記録を下に載せています。現在のHTMLとテーマ設定を確認し、対象が一致する場合に検証用環境で試してください。
組み込んだPHPコード
// SWELLメインビジュアルのHTMLを、ブラウザに出力される「直前」に捕まえて強制書き換え
add_action( 'template_redirect', function() {
ob_start( function( $buffer ) {
// "p-mainVisual__img" というクラスを持つ img タグを探し出す
// その中の loading="lazy" を loading="eager" に、さらに fetchpriority="high" を追加して置換
$buffer = preg_replace_callback(
'/<img[^>]+p-mainVisual__img[^>]+>/i',
function( $matches ) {
$img_tag = $matches[0];
// loading="lazy" を強制的に "eager"（即読み込み）に書き換え
// 同時に fetchpriority="high"（最優先）を追加
if ( strpos( $img_tag, 'loading="lazy"' ) !== false ) {
$img_tag = str_replace( 'loading="lazy"', 'loading="eager" fetchpriority="high"', $img_tag );
} else {
// もしlazyがなくても、念の為eagerとhighを追加しておく
$img_tag = str_replace( '<img ', '<img loading="eager" fetchpriority="high" ', $img_tag );
}
return $img_tag;
},
$buffer
);
return $buffer;
} );
}, 1 ); // 優先度1：誰よりも早く監視をスタートさせるコードの追加には、無効化して戻せる仕組みを用意します。Code Snippetsなどを使う場合も、利用版が扱えるコードの種類と実行範囲を確認してから登録します。
【施策3】爆速の基盤を作る：「WP Super Cache」とキャッシュ管理
キャッシュ機能を追加する前に、テーマ・サーバー・既存プラグインで有効な機能を確認します。重複させると更新反映や表示確認が難しくなることがあります。
なぜWP Super Cacheを導入したのか？
「SWELLにもキャッシュ機能があるのでは？」と思われたかもしれません。確かにSWELLは優秀ですが、役割が少し違います。
- SWELLのキャッシュ： ブログパーツやメニューなど、「部品」をキャッシュして組み立てを速くする機能（料理の下準備）。
- WP Super Cache： 「ページ丸ごと」をHTML化して保存する機能（完成した弁当）。
この環境では、ページ全体のHTMLを保存して返すWP Super Cacheも試しました。動的なページやログイン状態を含め、適用範囲を確認する必要があります。
TTFBはサーバーから最初の応答が届くまでの時間です。LCPの前段階に影響するため、画像だけでなく応答の遅れも切り分けます。
- 導入前：サーバーの応答待ちで 0.5秒〜1.0秒 ロスしていた。
- 導入後：応答待ちがほぼ 0.1秒以下 になり、その分、画像の表示開始が早まった。
つまり、「画像を表示するためのスタートダッシュを決めるため」に導入した、ということです。
ただし、干渉する設定は機能をOFFにして使っております。
簡単タブ＞キャッシング利用＞キャッシング利用 (推奨)にチェック。
高度な設定タブ＞その他＞ページを圧縮し、訪問者により速くページを供給する。 (推奨)にチェック。
ここで再計測をする際の注意点
「2段階キャッシュクリア」の徹底をしましょう。
- SWELLのキャッシュクリア：コンテンツとブログカード
- WP Super Cacheのキャッシュクリア
この二つのキャッシュクリアを行わないと、改善しても計測するときに古いデータが読み込まれてしまいます。
再計測する前にキャッシュクリアを徹底しましょう。
【最終結論】SWELL標準「メインビジュアル」を捨てて自作する。
ここまでの過程を実行し、スコア85～スコア90は安定して出るようになりましたが、どうせならスコア90以上を安定出るようにしたいと思いました。しかし、そこには既存の設定のままでは突破できない壁がありました。
スコアを追う前に、実際の操作や本文表示に支障がないことを確認します。無理に100を目指して必要な機能を失わないようにしてください。
今回の環境でメインビジュアルの構成を見直した理由
SWELLでメインビジュアルを設定する際、「外観 ＞ カスタマイズ」から画像をアップロードしますよね。 私は当初、ここで3枚の画像を設定し、スライドショーにしていました。しかし、これがLCP（表示速度）に悪影響を与えていると知り、「画像1枚だけ」の設定に変更しました。
Yuu「画像が1枚なら、スライドもしないし、軽くなるはず」
そう思ったのですが、スコアは改善しませんでした。
この構成では、画像を一枚にしてもスライダー用の処理が残っていました。現在のSWELLでも同じかは、出力HTMLと読み込まれるスクリプトを確認する必要があります。
当時の調査で確認した表示処理を、以下に整理します。
1. 表示されるまで「隠蔽工作」をしていた
今回の表示では、初期化前に要素が見えない状態になる処理があり、描画が遅れる一因と考えました。すべてのSwiper利用サイトで同じ遅延が起きるという意味ではありません。
// 準備ができるまで、全体を透明にする
if (!isInitialized) {
wrapper.style.opacity = '0';
}
// 準備完了！透明化を解除してやっと表示
on('init', function() {
wrapper.style.opacity = '1';
});画像が小さくなってもLCPが改善しない場合は、画像の取得完了と表示開始を分けて見ます。この検証では表示を待たせる処理も確認対象でした。容量をさらに削る前に、自サイトでも同じ要素がLCPなのか、いつ取得されいつ描画されるのかをレポートで照合してください。
2. 必要のない「計算」と「監視」
静止画に切り替えたい場合は、移動や初期化に関わる処理が残るかも確認対象になります。
- レイアウトの処理： 初期表示や画面幅の変更時に、サイズ計算が発生する場合がある。処理回数や所要時間は、使用中の設定とブラウザの計測結果で確認する。
- タッチ操作の処理： イベントリスナーがあるだけで、常に重い処理が走るわけではない。操作時に実行される処理と、スクロールを妨げる設定がないかを確認する。
- 描画とアニメーション：
transformは描画を効率化する場合もある。translate3dの使用だけで無駄な負荷と決めつけず、レイヤー数や描画時間を計測する。
使わない機能を減らす場合も、表示に必要な依存関係まで外さないようにします。
3. なぜコードで「強制停止」できなかったのか？
Yuu「じゃあ、そのプログラム（JS）だけ削除すればいいのでは？」
私もそう思い、コードで無理やりSwiperを停止させてみました。するとどうなったか？
デザインが崩壊し、画像が縦に並んでしまったのです。
これは、Swiperが動きだけでなく「見た目の骨組み（HTML/CSS）」まで支配していたからです。
例えるなら、「家（スライダー）を建てている最中に、大工さん（プログラム）だけを追い出した」ようなもの。
材料（画像）だけが現場に残され、組み立てる人がいなくなったため、家として機能せずバラバラに崩れ落ちてしまったのです。
この検証では、標準のメインビジュアルを無理に改変するより、固定ページの構成を作り直す方法を選びました。すべてのSWELLサイトに必要な変更ではありません。
【解決策】「Swiperの呪縛」を解く鍵は「フルワイド×カバーブロック」
「いちからトップページを自作するなんて、難しそう…」 そう身構えてしまうかもしれません。しかし、ご安心ください。SWELLには、専門知識がなくても直感的にトップページを作れる強力な武器が標準搭載されています。
それが「フルワイドブロック」と「カバーブロック」です。
フルワイドやカバーブロックで静的な構成を作る方法もあります。画像容量、背景の表示、スマホの文字位置まで確認し、元のページと比較してください。
まとめ：変更前後を測り、必要な機能を残して改善する
今回の記録で役立ったのは、追加機能を探す前に、必要な表示と不要な処理を整理したことです。
ただし、機能を減らせば必ず100になるわけではありません。各変更の効果は、同じ条件で測った数値と実際の操作で判断します。
- 画像を見直す：表示寸法と画質を合わせて形式を比較し、文字や透過が崩れない範囲で軽量化する。
- 機能を見直す：使っていない機能や重複する計測を確認し、必要な機能を残して変更前後を測る。
- キャッシュを確認する：サーバーや既存機能と重複しない方式を選び、動的なページと更新反映を確認する。
- 構造を比較する：画像1枚で足りる場合はカバーブロックも試し、必要な表現と表示速度を比較する。
固定ページへの作り直しは、今回の環境で選んだ方法の一つです。テーマ変更やページの再制作を急ぐ前に、レポートが示す対象を確認してください。
速度の改善は、本文を読み始めるまでの待ち時間や操作のしやすさを整えるために行います。
利用端末や通信環境で結果が変わるため、ラボのスコアと実ユーザーの指標を分けて確認します。
次の作業は、自サイトの代表URLを一つ決め、計測条件と遅延要因を記録することです。その原因に対応する一項目だけを変え、同じ条件で再計測し、メニュー・画像・フォームなどの操作も確認しましょう。数値が良くても使いづらくなった変更は戻します。テーマやサーバーの購入判断は、この検証の100点だけで決めないでください。
まだ、SWELLを利用していない方へ
今回ご紹介した高速化のノウハウは、WordPressテーマ「SWELL」環境下での検証データに基づいています。
もちろん他のテーマでも応用は可能ですが、機能や設定項目が異なるため、同じように設定しても「スコア100」という結果が出るとは限りません。
ここで示したのは当時の一環境の結果です。SWELLの導入効果を他テーマと同条件で比較した結果ではありません。
- 今のテーマだと、どうしても速度が上がらない…
- 高速化プラグインの設定で悩みたくない
- この記事の設定を参考に、自分のサイトで改善点を検証したい
テーマを比較する場合は、速度の点数だけでなく、普段の編集機能と移行作業を確認してください。
次の記事では、CocoonとSWELLを編集作業と移行負担から比較しています。現在のテーマで解決できることも含めて判断できます。
設定変更を始める前に、戻せる準備をする
バックアップと変更後の確認項目をそろえてから、改善作業を進められます。
