「国内最速」を謳うConoHa WING。 そして「高速化機能」が充実しているSWELL。
この2つを組み合わせれば、何もせずとも爆速サイトができる。 私はそう信じて疑いませんでした。
つい2週間前、PageSpeed Insightsで分析をするまでは。
スコア70点。 「高速化」を売りにしている環境としては、あまりに寂しい数字です。
そこからが苦闘の始まりでした。
何が足を引っ張っているのか？ プラグインの干渉か？ それとも設定ミスか？
原因を徹底的に追求し、仮説と検証を繰り返すこと2週間。 やっとの思いで、この画面にたどり着くことができました。
この記事では、私がスコア70から100に至るまでに踏んだ「失敗」と、そこから成功に至るまでの「具体的な手順」をすべて公開します。
- 画像を圧縮してもスコアが伸びない
- 高速化プラグインを入れたら表示が崩れた
- 結局、どの設定が正解なのか知りたい
今回私は2週間にかけて改善に徹した内容をまとめて、この記事にしました。
そんな悩みを持つあなたにこそ、最後まで読んでほしい内容です。
ConoHa WINGなのに遅い？ 絶望のスコア70点
まずは現状把握からスタートです。
「体感速度は悪くないのに、なぜスコアが低いのか？」
PageSpeed Insightsの詳細レポートを開き、赤い警告が出ている項目をチェックしました。
すると、ある一つの指標が致命的に悪いことが判明しました。
LCP（Largest Contentful Paint）：5.8秒
LCPとは、ざっくり言えば「そのページで一番目立つコンテンツが表示されるまでの時間」のこと。
私のブログの場合、トップページの一番上にある「メインビジュアル（スライドショー）」がこれに当たります。
読者がサイトを開いてから、メイン画像が完全に表示されるまでに約6秒もかかっている。 これでは「遅い」と判定されても文句は言えません。
犯人は「メインビジュアル」だった
当時の私は、SWELLの「記事スライダー」機能を使い、高画質な写真を3枚スライドさせていました。
綺麗な写真を見せたい一心で、PNG画像をそのままアップロードしていたのです。
「画像が重すぎるのが原因だ」
そう確信した私は、まず「画像のダイエット」から着手することにしました。
【検証1】救世主プラグイン「CompressX」の導入
画像をそのままアップロードして利用すると、サイトが重くなる。
これは聞いたことがあり、Tiny PNGなどで圧縮してアップロードしている方も多いのではないでしょうか？
目安にはなりますが、圧縮すると画像の容量が大幅に削減することができます。
| 元の形式 | 変換後の形式 | 削減率（目安） | 特徴・使い分け |
| JPG | WebP | 25% 〜 34% OFF | バランスが良く、現在最も汎用的な次世代形式。 |
| JPG | AVIF | 50% 〜 80% OFF | WebPを凌駕する超高圧縮。写真などの複雑な画像に強い。 |
| PNG | WebP | 26% OFF (可逆) | 透過情報を維持しつつ軽量化。イラストやロゴ向き。 |
| PNG | AVIF | 30% 〜 50% OFF | 透過を含む画像でもWebPよりさらに軽くなる。 |
| WebP | AVIF | 20% 〜 30% OFF | すでに軽量なWebPからさらに追い込んで削減可能。 |
有料級の圧縮率！なぜ有名プラグインではなく「CompressX」なのか
まず疑ったのは、トップページで大きく表示している「メインビジュアル」の画像サイズです。
多くのブロガーは「EWWW Image Optimizer」や「Converter for Media」といった有名プラグインを使っています。 私も最初はこれらを検討しました。
しかし、ここで壁にぶつかります。
次世代フォーマットとして、WebPよりもさらに圧縮率が高い「AVIF（アビフ）」が注目されていますが、主要なプラグインでは課金が必要なケースがほとんどなのです。
「無料で、かつ最強の圧縮をかけたい」 そんなわがままな要望を叶えてくれるプラグインを探し回り、ついに見つけました。
それが「CompressX」です。
また、このプラグインを選んだ理由は、以下の2つの機能が「無料」で使える点に尽きます。
- AVIF変換が無料: 他では有料の機能を標準搭載。
- 賢い出し分け機能: WebPとAVIFを作成し、より容量が軽い方を自動で表示してくれる。
設定は非常にシンプルです。 インストール後、設定画面でBulk Optimizationクリックするだけ。
実際に、メインビジュアルに使っていた画像を処理してみたところ、
アップロードしたオリジナル画像に対して、
- Webpに圧縮した場合：34.11％の削減
- AVIFに圧縮した場合：48.74％の削減
という風に圧縮率がわかり、圧縮率が高い方を自動的に表示してくれます。
しかも、画質の劣化は肉眼ではほとんど分かりません。
PNGからJPGへ、元画像のアップロード形式も見直そう
アップロードする際に美しく見せようとしすぎていて、全てPNGでアップロードしていました。
元画像のサイズが大きすぎると、圧縮しても小さくならないので、アップロードする画像をPNGからJPGに変更し、すでにアップロードしている画像もメインビジュアルと、各記事のアイキャッチ画像はJPGに差し替えました。
【施策2】「足かせ」を外す、断捨離したプラグインと設定
自分のサイトを確認していくと、不要なJavascriptがたくさん裏で読み込まれており、遅延に繋がっていることがわかりました。【施策2】では不要なプラグインの削除と、コードスニペットを利用した先読みの対策をご紹介していきます。
Site Kit by Googleの削除（SWELL標準機能へ移行）
Site Kit by Googleはダッシュボードからサーチコンソールや、アナリティクスにワンクリックで移動できるとても便利なプラグインでしたが、かなり重いのプラグインです。
既に導入されている、SEO SIMPLE PACKの設定に、認証コードとGA4のIDを埋め込み、
Googleアナリティクスとサーチコンソールの数値の確認は、ページをブックマークし、直接確認するようにしました。
右クリック禁止プラグインの削除（JS負荷の軽減）
コピー対策として導入していたプラグインですが、これが、サイト全体にプロテクトがかかるのでとても重い。そもそも盗用する人はどんな手を使ってでも盗用します。
私の記事で紹介しているGoogle拡張機能、Super Copyを使えば、対策をとっていても一撃でコピーすることができるので、そもそも対策しないという選択肢を選びました。
ConoHa WING「WEXAL」の無効化
ConoHa WINGでサーバーを契約していると、高速化設定の「WEXAL」を無料で利用することができます。
何とか「SWELL」と「WEXAL」を共存させようと頑張りましたが、干渉する項目が多すぎて、無理でした。
SWELLを利用している方は、「WEXAL」をＯＦＦにすることを強くお勧めします。
不要なPreload（先読み）記述の削除
SWELL設定でloading="lazy"を利用すると落とし穴があります。
それはメインビジュアルごと、遅延読み込みしてしまう。
これを解消するためにメイン画像を遅延読み込みさせないで！というPHPコードを組み込みました。
組み込んだ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では、PHPやCSS,JSなど、様々なコードを1つの設定からコードを記述することができ、スイッチでいつでもON/OFFを切り替えることができるのでお勧めです。
【施策3】爆速の基盤を作る：「WP Super Cache」とキャッシュ管理
まず、SWELL開発者からはキャッシュ系プラグインの導入が推奨されていません。
というのも十分すぎるくらい、機能が充実しているからで、入れてしまうと干渉して逆に遅くなってしまうことがあるからです。
なぜWP Super Cacheを導入したのか？
「SWELLにもキャッシュ機能があるのでは？」と思われたかもしれません。確かにSWELLは優秀ですが、役割が少し違います。
- SWELLのキャッシュ： ブログパーツやメニューなど、「部品」をキャッシュして組み立てを速くする機能（料理の下準備）。
- WP Super Cache： 「ページ丸ごと」をHTML化して保存する機能（完成した弁当）。
100点満点（LCP 1秒台）を目指すには、組み立ての時間すら惜しかったため、ページ丸ごとキャッシュするWP Super Cacheという「劇薬」が必要でした。
TTFB（最初の1バイトが届く時間）の改善
Googleの評価において、LCP（一番大きな画像の表示）を速くするには、その前段階である「サーバーから最初のデータが届く時間（TTFB）」が爆速でなければなりません。
- 導入前：サーバーの応答待ちで 0.5秒〜1.0秒 ロスしていた。
- 導入後：応答待ちがほぼ 0.1秒以下 になり、その分、画像の表示開始が早まった。
つまり、「画像を表示するためのスタートダッシュを決めるため」に導入した、ということです。
ただし、干渉する設定は機能をOFFにして使っております。
簡単タブ＞キャッシング利用＞キャッシング利用 (推奨)にチェック。
高度な設定タブ＞その他＞ページを圧縮し、訪問者により速くページを供給する。 (推奨)にチェック。
ここで再計測をする際の注意点
「2段階キャッシュクリア」の徹底をしましょう。
- SWELLのキャッシュクリア：コンテンツとブログカード
- WP Super Cacheのキャッシュクリア
この二つのキャッシュクリアを行わないと、改善しても計測するときに古いデータが読み込まれてしまいます。
再計測する前にキャッシュクリアを徹底しましょう。
【最終結論】SWELL標準「メインビジュアル」を捨てて自作する。
ここまでの過程を実行し、スコア85～スコア90は安定して出るようになりましたが、どうせならスコア90以上を安定出るようにしたいと思いました。しかし、そこには既存の設定のままでは突破できない壁がありました。
スコア80台でも満足という方はここで読むのをやめていただいても構いません。
なぜSWELLの機能を使うと「100点」が取れないのか
SWELLでメインビジュアルを設定する際、「外観 ＞ カスタマイズ」から画像をアップロードしますよね。 私は当初、ここで3枚の画像を設定し、スライドショーにしていました。しかし、これがLCP（表示速度）に悪影響を与えていると知り、「画像1枚だけ」の設定に変更しました。
Yuu「画像が1枚なら、スライドもしないし、軽くなるはず」
そう思ったのですが、スコアは改善しませんでした。
なぜなら、画像が1枚になっても、裏側では「Swiper（スワイパー）」という巨大なスライド用プログラム（JavaScript）がフル稼働していたからです。
このプログラムが裏でどんな「余計なお世話」をしていたのか？ コードを解析すると、衝撃の事実が見えてきました。
1. 表示されるまで「隠蔽工作」をしていた
これがLCP遅延の最大の犯人です。 Swiperには、読み込み中のガタツキを見せないよう、「準備が完了するまで透明にして隠す（Opacity: 0）」という機能が備わっています。
// 準備ができるまで、全体を透明にする
if (!isInitialized) {
wrapper.style.opacity = '0';
}
// 準備完了！透明化を解除してやっと表示
on('init', function() {
wrapper.style.opacity = '1';
});つまり、画像データ自体はすでに届いているのに、プログラムが「まだだ！俺が許可するまで表示するな！」と邪魔をしていたのです。これにより、最初の数秒間、画面は真っ白なまま待たされていました。
2. 必要のない「計算」と「監視」
さらに、たった1枚の画像を表示するためだけに、CPU（脳）を酷使する処理が走っていました。
- 画面サイズの再計算： 「スマホか？PCか？幅は何ピクセルだ？」と、ブラウザが描画したレイアウトをわざわざ再計算して書き換える。
- 指の動きを監視： スライドしないのに、「いつユーザーがスワイプしてもいいように」と、タッチ操作を常に見張り続ける（イベントリスナー）。
- GPUの無駄遣い： 滑らかに動かすための「3D計算（Translate3d）」を常に準備している。
これらは全て、静止画には不要な「過剰品質」だったのです。
3. なぜコードで「強制停止」できなかったのか？
Yuu「じゃあ、そのプログラム（JS）だけ削除すればいいのでは？」
私もそう思い、コードで無理やりSwiperを停止させてみました。するとどうなったか？
デザインが崩壊し、画像が縦に並んでしまったのです。
これは、Swiperが動きだけでなく「見た目の骨組み（HTML/CSS）」まで支配していたからです。
例えるなら、「家（スライダー）を建てている最中に、大工さん（プログラム）だけを追い出した」ようなもの。
材料（画像）だけが現場に残され、組み立てる人がいなくなったため、家として機能せずバラバラに崩れ落ちてしまったのです。
SWELL標準のメインビジュアル機能を使う限り、この「Swiperの呪縛」からは逃れられません。 だからこそ、私はこの機能を丸ごと捨て、「固定ページ」でゼロから作り直すという決断をしたのです。
【解決策】「Swiperの呪縛」を解く鍵は「フルワイド×カバーブロック」
「いちからトップページを自作するなんて、難しそう…」 そう身構えてしまうかもしれません。しかし、ご安心ください。SWELLには、専門知識がなくても直感的にトップページを作れる強力な武器が標準搭載されています。
それが「フルワイドブロック」と「カバーブロック」です。
これらを組み合わせることで、余計なプログラム（JS）を一切使わずに、美しく、かつ爆速なトップページを構築できます。まさに、あの厄介な「Swiperの呪縛」から完全に解き放たれる唯一の方法なのです。
まとめ：100点満点は「引き算」と「構造改革」で手に入る
ConoHa WINGとSWELL。この「最強の組み合わせ」を使ってもスコアが伸び悩んだとき、私は何かを「足そう」としていました。 新しいプラグイン、新しい設定、新しい機能……。
しかし、正解は真逆でした。 100点満点を取るために必要だったのは、徹底的な「引き算」だったのです。
- 画像の引き算：PNGをやめ、CompressXで限界まで軽くする。
- 機能の引き算：Site Kitや右クリック禁止など、重たいプラグインを捨てる。
- 処理の引き算：WP Super Cacheで、都度生成をやめて静的HTMLを返す。
- 構造の引き算：SWELL標準のメインビジュアル（JS）を捨て、シンプルなカバーブロックにする。
特に最後の「トップページの固定ページ化」は、勇気がいる決断かもしれません。 しかし、「見た目は変わらず、中身だけ爆速になる」この手法こそが、SWELLユーザーがLCP 1秒台の壁を突破する唯一の「構造改革」です。
「高速化」とは、単なる数字遊びではありません。 あなたのブログを訪れてくれた読者に対する、最初で最高の「おもてなし」です。
表示に5秒かかるサイトは、読まれる前に閉じられます。 しかし、1秒で開くサイトは、それだけで信頼され、読んでもらえるチャンスが巡ってきます。
ぜひ、今回紹介した手順を一つずつ試してみてください。 あの「70点」の絶望が、「100点」の感動に変わる瞬間を、あなたにも味わってほしいと思います。
まだ、SWELLを利用していない方へ
今回ご紹介した高速化のノウハウは、WordPressテーマ「SWELL」環境下での検証データに基づいています。
もちろん他のテーマでも応用は可能ですが、機能や設定項目が異なるため、同じように設定しても「スコア100」という結果が出るとは限りません。
私が今回証明したのは、「SWELLなら、デザインを犠牲にすることなく、PageSpeed Insightsで満点を叩き出せる」という事実です。 これが、現時点での私のブログ環境における「最適解」です。
- 今のテーマだと、どうしても速度が上がらない…
- 高速化プラグインの設定で悩みたくない
- 私が達成した『100点満点』の環境を、そのまま再現したい
もしそう感じているなら、この機会にSWELLへの乗り換えを検討してみませんか？ SWELLは元々「国内最速」級のテーマですが、今回の設定を加えれば「鬼に金棒」です。
SWELLについて、乗り換えてよかった点なども、下記記事にて紹介しているので、確認してみてください。
