WordPressをCocoonで運営していて、PageSpeed Insightsを確認したら「パソコンは速いのに、モバイルだけ30点台」。こんな数字を見せられると、サイトそのものが壊れているような気分になる。
私も以前、PCでは80点台なのにモバイルでは30点台まで落ちた経験がある。当時はいろいろ設定を変更し、モバイル61点、PC93点まで改善した。
ただし、2026年現在では高速化の考え方がかなり変わっている。
「PageSpeed Insightsを100点にしないとSEOで不利なのか？」
結論からいえば、100点を目指す必要はない。むしろ、点数だけを追いかけてJavaScriptを無理に変更したり、キャッシュ系プラグインを何個も入れたりするほうが危険だ。
現在重要なのは、PageSpeed Insightsの点数そのものより、実際のユーザーが快適にページを表示できているかである。
Cocoonには高速化機能が最初から用意されている。画像、PHP、サーバー、広告、プラグインまで順番に確認すれば、専門的なコードを書かなくても改善できる可能性は高い。
昔の高速化方法をそのまま使う必要はない。ここはかなり重要だ。
PageSpeed Insightsでモバイルだけ遅くなるのは珍しくない
PageSpeed InsightsはGoogleが提供しているWebページの速度測定ツールだ。
公式のPageSpeed Insightsはこちら。
PageSpeed Insightsを開く
URLを入力するだけで、モバイルとデスクトップの状態を確認できる。
ただし、ここで表示される「57点」「82点」「94点」といった数字だけを見て一喜一憂するのはおすすめしない。
モバイルはPCより厳しい条件で測定される
WordPressサイトでは、PCよりモバイルのPageSpeed Insightsスコアが低くなることが多い。
モバイルでは通信環境や端末性能の影響を受けやすく、画像やJavaScriptの読み込みも重く感じやすい。
そのため、
- PC：90点
- モバイル：60点
という結果でも、それだけで異常とはいえない。
私も昔は「PCが速いならモバイルも同じくらいになるはず」と考えていた。しかし、ここを同じ基準で見ると泥沼に入りやすい。
100点という数字は気持ちいい。
しかし、サイト運営では数字を眺めることより、読者が待たされないことのほうが重要だ。
「実際のユーザー」と「テスト結果」は分けて見る
現在のPageSpeed Insightsには、大きく分けて2種類のデータがある。
1つはChrome UX Report、通称CrUXによる実際のユーザーデータ。
もう1つはLighthouseによるテスト環境で測定したデータだ。
Google公式でも、CrUXは実際のユーザー環境を集計したフィールドデータ、Lighthouseは制御された環境で行うラボテストとして説明している。
アクセス数が少ないページでは実ユーザーデータが表示されず、Lighthouseだけ表示される場合もある。
つまり、1回測って50点だったからといって「このサイトは常に50点の速度」という意味ではない。
ここを勘違いすると、設定変更だけが無限に増えていく。
2026年はCore Web Vitalsを優先して確認する
Googleが現在重視している表示体験の指標が「Core Web Vitals」だ。
主に次の3つを見る。
- LCP：主なコンテンツが表示されるまでの速さ
- INP：クリックやタップに対する反応速度
- CLS：表示中にレイアウトがずれる量
Googleが示している「良好」の目安は次のとおりだ。
| 指標 | 良好の目安 |
|---|---|
| LCP | 2.5秒以下 |
| INP | 200ms以下 |
| CLS | 0.1以下 |
これらは実際のユーザーアクセスの75パーセンタイルを基準として評価される。
公式情報はこちら。
Google公式 Core Web Vitalsの解説
PageSpeed Insights100点よりCore Web Vitals良好を狙う
ここはかなり大事だ。
Google自身が、Core Web Vitalsはランキングシステムで利用されていると説明している。一方で、Core Web Vitalsが良好だから検索1位になるわけではない。
GoogleもSEO目的だけで満点を追いかけることが最適とは限らないとしている。
つまり、
PageSpeed Insights100点＝検索上位
ではない。
記事の内容が弱ければ、サイトだけ爆速でも上位表示は難しい。
高速化は重要だ。しかし高速化だけでSEOが完成するほど、Googleも単純ではない。
Cocoonの高速化設定を最初に確認する
Cocoonを使っているなら、いきなり高速化プラグインを探す必要はない。
まずCocoon自身の機能を使う。
Cocoon公式でも高速化設定が案内されている。
Cocoon公式「おすすめのサイト高速化設定」
Cocoon設定から高速化を確認する
WordPress管理画面からCocoonの高速化設定を確認する。
特に確認したいのは、
- ブラウザキャッシュ
- CSSの縮小
- JavaScriptの縮小
などだ。
Cocoon公式でも、テーマ標準の高速化機能を利用する方法が案内されている。
設定したら、一度サイトを表示して崩れていないか確認する。
CSSやJavaScriptの縮小では、使用しているプラグインや独自カスタマイズとの相性によって表示が崩れる場合がある。
全部ONにして終わり、ではない。
高速化設定→サイト確認→PageSpeed Insights確認
この順番で進めるべきだ。
不具合が出たら一気に変更しない
高速化で一番面倒なのは、「何を変更したせいで壊れたのかわからなくなる」ことだ。
CSS縮小、JavaScript縮小、キャッシュプラグイン、画像Lazy Load、CDNを同時に変更する。
そして表示が崩れる。
人間はこういうとき、なぜか全部一度に触りたくなる。後から原因探しという罰ゲームが始まるだけだ。
変更は1つずつ行う。
これだけでもトラブルはかなり減らせる。
モバイル高速化では画像を最優先で軽くする
ブログでは画像がページ容量の大部分を占めることがある。
特に、
- アイキャッチ画像
- 大きな写真
- PNG画像
- 商品画像
- スクリーンショット
が大量にある記事は重くなりやすい。
以前の私の記事でも、画像最適化はかなり重要な対策だった。
これは2026年でも変わらない。
WebPのためにfunctions.phpを書き換える必要はない
昔はWordPressでWebPを扱うため、functions.phpにコードを追加する方法も使われていた。
しかし、現在これをわざわざ行う必要はない。
WordPressは5.8からWebP画像を正式にサポートしている。対応サーバーならJPEGやPNGと同じようにメディアライブラリへアップロードできる。
昔の記事にあるような、
「WebPを使うためfunctions.phpへコードを追加する」
という方法は、現在なら優先する理由がほぼない。
コードを追加すればするほど管理も面倒になる。
使わなくていいコードは使わない。
これでいい。
画像サイズそのものを小さくする
WebPに変換するだけでは不十分な場合もある。
たとえば本文幅が800px程度なのに、4000pxの写真をそのままアップロードする必要はない。
画像を投稿する前に、
- 必要以上に大きな画像を縮小
- JPEG・WebPなど適切な形式を利用
- 圧縮する
- 同じ画像を何枚も読み込ませない
といった基本対策をしたほうが効く。
高性能な画像最適化プラグインも便利だが、元画像が無駄に巨大なら仕事を増やしているだけだ。
まず画像を軽くする。
ここは地味だが強い。
Lazy Load専用プラグインは慎重に使う
昔は画像の遅延読み込みを行うために「a3 Lazy Load」のような専用プラグインを使う方法もあった。
現在は事情が違う。
WordPressは5.5から画像のネイティブLazy Loadに対応しており、5.7からiframeにも対応している。
そのため、Lazy Loadだけを目的にプラグインを追加する必要性は昔よりかなり低い。
最初に表示される画像を遅延させない
注意したいのが、画面上部の画像だ。
記事を開いてすぐ表示される大きな画像がLCPの対象になっている場合、その画像まで遅延読み込みすると逆にLCPが悪化することがある。
WordPressでも、この問題を避けるためLazy Loadの仕組みは改善されてきた。
「画像は全部Lazy Loadにすれば速くなる」
とは限らない。
画面下の画像には有効でも、最初に見せる画像まで遅らせれば本末転倒だ。
PHPは古いバージョンを使わない
以前の記事では「PHP5からPHP7へ変更すると高速化できる」と書いていた。
これは当時なら意味があった。
しかし2026年にPHP7をおすすめする記事を書いたら、さすがに時間が止まりすぎている。
WordPress公式では現在、PHP8.3以上を推奨している。
公式要件はこちら。
WordPress公式 必須要件
PHP更新前にはテーマとプラグインを確認する
PHPは新しくすれば無条件でいい、という話でもない。
古いプラグインや独自コードが残っていると、新しいPHPでエラーが出る可能性がある。
そのため、
- WordPressを更新
- Cocoonを更新
- プラグインを更新
- バックアップ
- PHPを更新
- サイト表示を確認
という順番が安全だ。
古いPHPを使い続ける理由は薄いが、何も確認せず変更する必要もない。
速さと安全性の両方を見るべきだ。
エックスサーバーならサーバー側の高速化も確認する
私が使用してきたエックスサーバーには、サーバー側にも高速化機能が用意されている。
Cocoonだけ変更してもTTFB、つまりサーバーが応答を開始するまでの時間が遅いなら改善には限界がある。
Xアクセラレータを確認する
エックスサーバーには「Xアクセラレータ」がある。
現在のXアクセラレータ Ver.2では、
- 静的ファイルの高速化
- PHPプログラムの高速化
が提供されている。
公式はこちら。
エックスサーバー公式 Xアクセラレータ
エックスサーバーを使っていて表示速度に悩んでいるなら、一度設定を確認する価値は高い。
サーバーキャッシュも利用できる
エックスサーバーにはサーバーキャッシュ機能もある。
サーバー側にキャッシュを作ることで、表示速度や大量アクセス時の処理能力を向上させる仕組みだ。
公式はこちら。
エックスサーバー公式 サーバーキャッシュ設定
ただし、キャッシュを有効にした後はサイト表示を確認する。
更新した記事が反映されない場合などは、キャッシュ削除が必要になることもある。
キャッシュ系プラグインは最後に試す
以前は「WP Fastest Cache」などのキャッシュ系プラグインも利用していた。
効果が出る環境はある。
ただ、2026年現在なら私は最初から入れる方法はすすめない。
Cocoonにも高速化機能があり、レンタルサーバー側にもキャッシュ機能があるからだ。
そこへさらにキャッシュプラグインを追加すると、
- Cocoon
- サーバー
- プラグイン
の3か所で高速化処理が重なる場合がある。
設定が増えるほど原因切り分けも難しくなる。
まずテーマとサーバー。
それでも改善しない場合にプラグインを検討する。
この順番が扱いやすい。
広告・アクセス解析・SNS埋め込みは速度を落としやすい
Cocoon公式でも、AdSense、Analytics、SNSなど外部サービスを読み込むとPageSpeed Insightsの点数が大きく下がる場合があると説明されている。
これはテーマを変更しても完全には避けられない。
AdSenseを使うなら多少の低下は受け入れる
ブログを収益化しているなら広告を全部消して100点を取っても意味がない。
速くなった。
収益は消えた。
これでは何をしているのかわからない。
広告数が多すぎるなら減らすべきだが、収益とのバランスを見る必要がある。
PageSpeed Insightsで警告されたからといって、外部JavaScriptを全部消す必要はない。
不要なプラグインは削除する
長期間WordPressを使っていると、
「これ何のために入れたんだ？」
というプラグインが増えてくる。
私も以前、高速化を行ったタイミングで不要なプラグインやテーマを整理した。
停止しているだけでも管理対象は増える。
現在使っていないものは整理したほうがいい。
ただし、削除前には本当に不要か確認する。
勢いだけで消すと別の意味でサイトが軽くなる。機能まで消える。
PageSpeed Insightsの警告はLCP・INP・CLSに分けて考える
PageSpeed Insightsには大量の改善項目が表示される。
全部を同時に直そうとするとわけがわからなくなる。
問題を3つに分けると見やすい。
LCPが悪い場合
LCPが遅いなら、まずページ上部を見る。
特に、
- アイキャッチ画像が重い
- サーバー応答が遅い
- CSS読み込みが多い
- Webフォントが重い
- 大きな画像を読み込んでいる
といった原因を確認する。
ブログではファーストビューの大きな画像がLCPになることも多い。
まずそこを軽くする。
INPが悪い場合
INPは操作したときの反応速度だ。
悪い場合は、
- JavaScriptが多い
- 広告スクリプトが多い
- 重いプラグイン
- SNSや外部ウィジェット
などを疑う。
記事を表示するだけなら問題なくても、メニューを押した瞬間に固まるサイトは使いにくい。
人間は待たされるのが嫌いだ。特にボタンを押した直後は驚くほど短気になる。
ここは軽視できない。
CLSが悪い場合
ページを読んでいたら突然文章が下へずれる。
かなり不快だ。
CLSが悪い場合は、
- 画像のwidth・height
- 広告表示スペース
- 遅れて表示されるパーツ
- Webフォント
- 埋め込みコンテンツ
などを確認する。
特に広告が後から入り込んで文章を押し下げる場合は注意したい。
昔の高速化方法をそのまま使わない
今回2本の記事を統合するうえで、昔は有効だったものの、現在は積極的におすすめしにくい方法もかなり整理した。
JavaScriptをfunctions.phpで強制的にasync化しない
昔の記事では、レンダリングを妨げるJavaScriptへの対策としてfunctions.phpへコードを追加していた。
しかし、JavaScriptを強制的にasync化すると、読み込み順序が変わって機能が壊れる可能性がある。
仕組みがよくわからないコードをPageSpeed Insightsの数点のためだけにfunctions.phpへ貼る。
これは現在ならおすすめしない。
Cocoonや高速化プラグインなど、管理できる機能から調整したほうが安全だ。
AMP化を高速化の第一候補にしない
以前はAMP化も高速化手段として使っていた。
実際、私も試したことがあるが、表示崩れの影響が大きく停止した。
2026年現在、通常のWordPressサイトを高速化する目的だけでAMPを最優先にする必要はない。
通常ページのCore Web Vitalsを改善するほうが素直だ。
高速化のために別形式のページまで管理するのは、個人ブログでは負担が大きすぎる場合がある。
Cocoonのモバイル高速化はこの順番で進める
私なら現在は次の順番で確認する。
- PageSpeed Insightsでモバイルを測定
- Core Web VitalsのLCP・INP・CLSを確認
- WordPress・Cocoon・プラグインを更新
- バックアップを取る
- Cocoonの高速化設定を確認
- 画像を圧縮しWebPなどを利用
- PHPを推奨バージョンへ更新
- Xアクセラレータやサーバーキャッシュを確認
- 不要なプラグインを整理
- 広告や外部JavaScriptを確認
- 再度PageSpeed Insightsで測定する
いきなりfunctions.phpを書き換える必要はない。
キャッシュプラグインを3つ試す必要もない。
基本的な部分から順番に潰したほうが安全で、原因も見つけやすい。
PageSpeed Insightsが低いだけでSEOが終わるわけではない
表示速度はSEOと無関係ではない。
GoogleはCore Web Vitalsをランキングシステムで利用していると明言している。
しかし、もっと重要な点がある。
速度だけで順位が決まるわけではない。
内容が検索意図に合っているか。
読者が知りたい情報があるか。
スマートフォンでも読みやすいか。
広告が邪魔をしていないか。
サイトが安全か。
こうした要素を含めたページ体験全体を見る必要がある。
PageSpeed Insightsが90点から95点になったから検索順位が急上昇する、という単純な世界ではない。
だったら、その5点を取るために何時間も使うより、記事を改善したほうがいい場合もある。
この判断はかなり重要だ。
まとめ｜Cocoonのモバイル高速化は100点ではなく「読者が快適か」で判断する
CocoonでPageSpeed Insightsのモバイルスコアが低くても、慌てて大量の高速化プラグインを入れる必要はない。
まず確認したいのは、
- Core Web Vitals
- Cocoonの高速化設定
- 画像サイズとWebP
- PHP
- サーバーキャッシュ
- Xアクセラレータ
- 不要なプラグイン
- 広告や外部JavaScript
だ。
以前はPHP7への変更、Lazy Loadプラグイン、functions.phpへのWebP対応コード、AMPなども高速化策として使っていた。
しかしWordPressは進化した。
昔必要だった作業が、今ではWordPress本体やCocoonに標準搭載されているものも多い。
だからこそ、古い高速化記事を見てコードを片っ端から貼るのはおすすめしない。
私自身、モバイル30点台を見て設定を何度も触った経験があるからこそ思う。
PageSpeed Insightsの点数は改善の入口であって、ゴールではない。
GoogleもCore Web Vitalsだけで検索順位が決まるとはしていない。まず読者がスマートフォンで普通に開けて、普通に読めて、操作しても待たされない状態を作る。
そこまで改善できたら、残った数点のためにサイトを壊す必要はない。
速いサイトは大切だ。
だが、「100点のサイト」より「読みたい情報がすぐ読めるサイト」のほうが強い。2026年のWordPress高速化では、この基準で判断するべきだ。
コメント