WordPressでブログを始めると、Googleの「Google PageSpeed Insights」に表示されるスコアが気になります。もちろん私もその一人です。

私のサイトでは、以前モバイルのPerformanceスコアが62点でした。

PageSpeed InsightsにはLCP、CLS、INP、JavaScript、画像などさまざまな改善項目が表示されます。しかし、項目を見ても「結局どこから手をつければいいのか」が分かりにくいことがあります。

そこで私は、高速化プラグインを次々に追加したり、function.phpにコードを追加したりするのではなく、設定を一つずつ変更して、その都度PageSpeed Insightsで測定する方法で検証しました。

その結果、私の環境ではPerformanceスコアが62点から97点まで改善することができました。ただし、すべての対策が大きな効果を発揮したわけではありません。

この記事では、私が実際にためした対策について、次の実測結果をもとに整理します。

• 何を変更したのか
• なぜ変更したのか
• どの程度効果があったのか
• 効果が小さかったものは何か
• 変更後に問題は起きなかったか

これらに注視して効果の有無について検証していきます。

※注意：この記事の数値は私のWordPress環境で測定した結果です。すべてのサイトで同じ改善効果が得られることを保証するわけではありません。参考までに。

結論：PageSpeed Insightsは62点から97点になった

最初に今回の検証結果を紹介します。

指標	改善前	改善後
Performance	62	97
LCP	4.1秒	2.0秒
INP	改善が必要	良好
CLS	0.18	0.05

Performanceは35ポイント改善しました。特に効果が大きかったと感じたのは次の対策です。

対策	私の環境での効果
不要なプラグインの整理	かなり大きい
画像のWebP化・軽量化	大きい
Lazy Load	効果あり
Cocoonやレンタルサーバーの高速化設定	小～中くらい
CSS・JavaScriptの縮小化	小さい

重要なことは「高速化のために新しい機能をどんどん追加した」わけではないことです。むしろ今回の検証では、不要な処理や重複している機能を減らしたことが大きな改善につながりました。

この記事でわかること

この記事では、WordPressのテーマのCocoon Childを使用している私のサイトを実際に改善できた仮定を紹介します。

具体的には次の8つの点につき扱います。

1. PageSpeed Insightsで何を確認したのか
2. 改善前のサイトがどのような状態だったのか
3. 画像をどのように軽量化したのか
4. 不要なプラグインをどのように整理したのか
5. Cocoonの高速化設定で何を変更したのか
6. 効果が大きかった対策と小さかった対策
7. 62点から97点になった最終結果
8. 高速化をする際の注意点

単に「この設定をONにしてください」という紹介はできません。ただ実際に試した結果を記録することをこの記事の目的としています。

検証環境

今回の検証を行う環境は次の通りです。

項目	内容
CMS	WordPress
テーマ	Cocoon Child
サーバー	XServer
測定ツール	Google PageSpeed Insights
対象	モバイル
画像形式	WebP
キャッシュ	Cocoon標準機能

PageSpeed Insightsは、Webページのパフォーマンスを測定するためのGoogleが提供するツールです。

ただし、表示されるスコアはサイトの構成や測定条件によって変動します。そのため私は一度の測定結果だけで改善効果があったかどうかを判断しないようにしました。

改善前：Performanceスコア62点

高速化を始める前、何度も言いますが、私のサイトではモバイルのPerformanceスコアは62点でした。当時の主な数値は次の通りでした。

項目	改善前
Performance	62
LCP	4.1秒
CLS	0.18
INP	改善が必要

PageSpeed Insightsを見ると、パフォーマンスが突出して悪いことがわかります。その中でも画像やレンダリング、JavaScriptなど、複数の項目が指摘されていました。

その指摘事項を見て、「指摘された項目を全部直せば速くなる。むしろ低スコアは伸びしろ」と考えていました。しかし、実際には思うようにはいきません。スコアに良いとされる設定を変更してみても、必ずしも大きな変化はありませんでした。

検証方法：一度に全部変更はしない

今回の検証で特に意識した方法は、一度に複数の設定を変更しないということです。一度に複数の変更をしてしまうと何が効果的だったかわからなくなるからです。

1. 画像のWebP化、リサイズ
2. プラグインの削除
3. CSSを縮小
4. JavaScriptを遅延
5. キャッシュを変更

このあたりがLCPのスコアに影響する内容です。これらを一度に行ってしまうと、最終的なスコアが上がったとしても、何が効果を発揮していたのか分かりません。もしかしたら効果が薄いにも関わらず、ページ全体のUXに影響を及ぼしている可能性も否めません。

そこで次のような手順で作業を行いました。

1. 変更前に測定する
   現状をPageSpeed Insightsで測定します。
2. 設定を一つずつ変更する
   画像、プラグイン、Cocoon設定など、できるだけ変更箇所を限定していきます。
3. 変更後のサイトを実際に確認する
   PageSpeed Insightsの数字だけを追うのではなく、大事なのはUXです。
   ・PCでの表示
   ・モバイルでの表示
   ・メニューが機能しているか
   ・画像の表示速度
   ・リンク切れはないか
   ・問い合わせフォームが動作するか
   などなど、これらを確認してWebページとして破綻していないかを確認します。
4. 最終的な測定を行う
   変更するたびにPageSpeed Insightsを実行し、数値が変わるか否かを見てきました。しかし、その時の状況によって数値は変化します。

この方法なら、「点数は上がったけれどサイトの表示がおかしくなった」という問題も発見できます。

実践 1：画像をWebP化して軽量化すそれぞれについて、

最初に取り組んだのが画像の最適化です。私は当初PNGで画像をアップロードしていました。しかし、数MBのファイルをAffinityで中程度のWebP（8割圧縮程度）にエクスポートしました。

結果からいうとWebPにしたところPNGに比べて約3倍〜10倍ほどファイルサイズを削減することに成功しました。

ブログではスクリーンショットや説明画像を多用するため、画像ファイルが大きいとページの転送量にも影響します。これだけでも大きな変化になるのではないかと思いました。

WebP化するだけでは十分ではない

最初はPNGをWebPに変換すれば、それだけで大きく軽量化できると考えていました。

しかし、PNGからWebPに変換しても元画像が大きければ、WebPに変換してもそれなりのサイズになってしまいます。

やはり、画像を上げる前にPC側で加工する必要があります。

• 必要以上に大きな画像は使わない
• 長辺は500px程度まで縮小する
• WebP形式で保存する際の品質調整
• ファイルサイズが1桁から15KBくらいまでに抑える

これくらいのことはしないと、ファイルサイズを抑えることができませんでした。

重要なことは「WebPに変換する」ことだけではなく、「必要な大きさの画像を用意する」ことでした。

Lazy Loadも利用した

画像という点において、私はCocoon Childを使っているため、Lazy Loadも利用しました。

Cocoonには画像の遅延読み込み機能としてLazy Loadという機能が用意されています。公式の高速化案内でも周知されていました。（https://wp-cocoon.com/site-speed-up/）

ページを開いた瞬間に、画面の下にあるすべての画像まで読み込ませる必要はありません。その場合、遅延読み込みによって初期表示時の負荷を減らすことができます。

ただし、Lazy Loadについても「有効にすればかスコアが必ず上がる」というわけではありません。自分のページ構成に合わせて確認することが大事です。

画像最適化で分かったこと

今回の検証で感じたことは、画像最適化はPageSpeed Insightsのためだけに行うものではないということでした。

画像ファイルを小さくすることで表示が速くなり、記事を読む人の体験も良くなるということです。

つまり、PageSpeed Insightsの改善と、実際の閲覧環境の改善を同時に行える対策だと考えています。

実践 2：不要なプラグインを整理する

今回の検証で、特に効果が大きいと感じたのがプラグインの整理でした。

WordPressでは便利なプラグインを簡単に導入することができます。クリック一つで簡単にインストールから有効化まで機能を追加できます。

しかし、それなりの時間をブログに費やしていると、「以前は必要だったけれど、今は使っていない」「色々入っているけれど機能の重複はなかったか」という疑問が出てきます。

この点について一つずつ確認を行いました。

当時インストールしていた主なプラグイン

当時の環境では、次のようなプラグインを常駐させていました。

• Site Kit by Google
• Yoast SEO
• XML Sitemap Generator
• Contact Form 7
• Redirection

プラグインについて考えると「有名なプラグインだからいれてみたけど削除しよう」という安易な判断をしないことです。

それぞれについてこのプラグインは何をしているのかということを確認することが大事です。

Site Kit by Googleについて見なおす

Site Kit by Googleは、Google Search Console、Analytics、Adsense、PageSpeed Insightsなどの情報をWordPressの管理画面から確認できてとても便利なプラグインです。

私自身も「これは外せない最重要プラグインだろう」と思い、使ってきました。

しかし、よく考えると、これらのサービスはブラウザからそれぞれの公式サイトを開けば確認できます。「ブログを閲覧するユーザーに必要なプラグインなのか」という疑念が生まれました。

管理画面を便利にする機能と、公開ページを軽くすることは別問題です。そこで私はSite Kitを外すことを選びました。結果としては不便さと引き換えに表示パフォーマンスは改善されました。

ただし、これはSite Kitを使っているサイトはすべて削除するべきという意味ではありません。サイトによって、また管理者によって必要性は変わってきます。

SEOプラグインとCocoonの機能について確認した

つぎはSEO関係の機能です。

私はWordPressのテーマにCocoon Childを使っています。Cocoonはとても優秀なテーマで、標準機能としてSEOに関係する基本的な設定が用意されています。

そのため色々SEOプラグインを導入している場合、どの内容が競合しやすいのかを調べることにしました。

• タイトル
• メタ情報
• OGP
• 構造化データ
• パンくずリスト

これらに関しては各SEOプラグインにおいて重複していないか確認する必要がありません。

「SEOプラグインは不要」と安直に考えてはいけません。

ブログに必要な機能を提供しているのであれば、使い続ける理由となります。

私の場合は、とくに複雑なブログ運営をしているわけでもないため、Cocoon側の機能と重複していた場合、Cocoonを優先して整理しました。競合を無くしたことで不要な処理を減らせたと判断しました。

XML Sitemap Generatorについて見直した

XMLサイトマップについても確認しました。これはブログを開始したときから使っているプラグインでした。sitemap.xmlは書いたことがなかったため、とても便利に思えました。

しかし、調べてみたところWordPressには標準のXMLサイトマップ機能がありました。WordPressの公式資料では、標準のサイトマップ機能がWordPressコアに組み込まれた経緯が説明されていました。（https://make.wordpress.org/core/2020/01/27/feature-plugin-xml-sitemaps/）

私の環境では標準機能で運用できると判断し、Sitemap作成専用プラグインを削除しました。

やはり「プラグインを削除すること」を目的とするのではなく「競合していた場合どちらを残すか考えること」が大切です。

すべてのプラグインを削除したわけではない

高速化をはじめていくと、「プラグインは少なければ少ないほど速い」と考えてしまいます。確かにプラグインが100個入っているブログと0個のブログでは明確な差が出ると思います。

しかし、これは単純に考えすぎているとおもいます。例えば私の場合、問い合わせフォームはサイト運営に必要でした。

そのためContact Form 7など、必要な機能まで高速化のために削除することはしませんでした。

Cocoonの公式FAQでも、不要なプラグインの停止は高速化策として紹介されています。しかしAdsenseやAnalyticsなどサイト運営に必要な機能まで外すのは本末転倒になる場合があるとFAQ内で説明されていました。（https://wp-cocoon.com/frequently-asked-questions/）

プラグインの数を減らすことではなく、不要なものを確認して減らすこと、これがプラグイン関係では大事なことでした。

実践 3：Cocoonの高速化設定について見なおす

画像とプラグインの整理が終わったところで、私がテーマに選んでいるCocoon Child本体の高速化設定を確認しました。

Cocoonには「Cocoon設定→高速化」という項目がメニューにあります。

公式サイトでも、ブラウザキャッシュ、CSS縮小化、JavaScript縮小化などの高速化機能が案内されています。

色々ためしてみましたが、効果が確認できたものは次の項目でした。

設定	結果
CSS縮小化	やや有効
JavaScript縮小化	有効
Lazy Load	有効
Google Fonts遅延読み込み	有効

Cocoonが元から軽いテーマであったこともあり、これくらいがちょうどよいです。

CSS縮小化は劇的な改善ではなかった

CSSの部分を見てみると、個人Webサイトを作っていた15年前に比べてかなりの量が書き込まれていました。もちろん空白や改行も多かったです。

そこでCSS縮小化をして、CSSに含まれる不要な空白や改行などを減らし、データ量を抑えられるのではないかと考えました。

ただし、私の環境下ではこれだけで大幅にスコアが上がることはありませんでした。

微々たる効果でしたが、Cocoonの設定画面からチェックボックスにチェックを入れるだけで簡単に有効化でき、サイトに影響がなかったため利用すると判断しました。

「効果が小さいから意味がない」と短絡的に考えてはいけません。

大きな改善を狙う対策と、ほんの数ポイントを整える対策は最終的に同じこと、つまりサイト全外のスコア上昇につながると考えています。

JavaScript縮小化については慎重に確認した

JavaScriptは悩みました。JavaScriptを縮小化することで確実に転送量を減らすことができることはわかります。しかし、ほかのプラグインやスクリプト関係との相性が未知数でした。

Cocoon公式FAQでも、CSSやJavaScriptの縮小化によってほかのプラグイン等と競合し、表示崩れが発生する場合があるため、問題が出た場合はプラグインを個別に無効化して確認する必要があると案内されています。（https://wp-cocoon.com/frequently-asked-questions/）

JavaScriptを縮小化してスコアを上げても、表示が崩れるようでは意味がありません。

そのため、高速化設定は全部ONにして終わり、ではなく、ONにして動作確認をすることが大事です。

Google Fontsの遅延読み込み

Google Fontsについても、Cocoonの高速化設定から確認できます。

フォントはページの表示に関係する外部からのリソースの一つなので、読み込み方によっては表示速度に影響します。

私の環境では遅延読み込みを有効にしました。

ただし、「Google Fontsを使っているサイトは必ず遅い」と単純に言い切れるものではありません。何度も自分のPageSpeed Insightsの結果を確認して必要か否かを判断してください。

高速化設定は全部ONが正解とは限らない

今回の検証で重要だと感じたのはこの部分です。高速化設定は便利ですが、設定を有効にした結果、記事を見に来てくれた人に不利益があってはなりません。

• CSSが正しく働かない
• JavaScriptが動かない
• 画像が表示されない
• プラグインが動かない
• レイアウトが崩れる

これでは本末転倒です。

Cocoon公式でも、高速化設定による競合が発生した場合には、一つずつ設定を無効化して原因を切り分ける方法がFAQ内で推奨されています。（https://wp-cocoon.com/frequently-asked-questions/）

色々な場面で言えることですが、「一つ何かを変更したら、その場で確認する。不具合があれば戻す」という考えは必要です。

これは高速化に限らず、WordPressの設定変更では結構重要な方法なのではないかと思います。

効果が大きかった対策と小さかった対策

今回の検証結果を整理しました。思ったような結果になりましたが、不便さとスコア上昇は比例関係にあるのだなと実感しました。

対策	効果	優先度
不要なプラグイン整理	大	高
画像の軽量化	大	高
WebP化	中～大	一番
Lazy Load	中	中
CSS縮小化	小	低～中
JavaScript縮小化	小	低～中
その他の細かな調整	環境依存	状況による

つまり細かな設定を追い込む前に、大きなデータや不要な処理を減らす方が重要だったということが浮き彫りになりました。

改善結果：Performance 62点から97点へ

ここまでの対策を行った結果私の環境ではPerformanceスコアが62点だったものが97点まで改善しました。

項目	改善前	改善後
Performance	62	97
LCP	4.1秒	2.0秒
INP	改善が必要	良好
CLS	0.18	0.05

Performanceは35ポイントの改善

Performanceの改善の幅は大きいと思いました。しかしPageSpeed Insightsのスコアは測定するたびに多少の変動があります。

そのため「35ポイント改善した」という数字よりも、複数の変更を行った結果として、記事を見てくれる人に対してページの表示が軽くなったという方が大切だと思います。

LCPは4.1秒から2.0秒へ

LCPは4.1秒から2.0秒になりました。約半分になったと言えます。この改善には次の4つが関わっています。

• 画像の軽量化
• WebP化
• Lazy Load
• プラグイン整理

ただし、どの対策がLCPを何秒改善したのかを厳密に調べることはできませんでした。先ほど述べたようにPageSpeed Insightsはその時その時で多少の数値の変動があるからです。よって個別の対策についてどのような効果があったかについては避けます。

今回の記事ではなんども同じ趣旨が出てきましたが「測定して分かったことと、そこから考えたことを分ける」という考え方が必要だと思います。

断定型の高速化について書かれているWebページもありますし、正しいと思います。しかしそれ以上にその対策をして読者はどのような体験ができるのかが大切だと考えました。

数値だけでは分からない変化もあった

PageSpeed Insightsのスコアが上がったことは嬉しい結果でした。しかし、それ以上に重要だったのは、実際にサイトを開いたときの感覚です。

画像の表示が軽くなり、ページの初期表示も以前より快適になりました。

PageSpeed Insightsはサイトを診断するための便利なツールですが、最終的にページを見るのは人間です。

そのため、スコアが高ければ正解ではなく、読者が快適にページを利用でき、その結果としてスコアも改善するという考え方が重要だと感じています。順番が逆だったということでした。

なぜ今回は改善できたのか

今回の検証を振り返って、一番大きかったのは「高速化のために何かを追加する」という発想をやめたことでした。

最初は、「高速化プラグインを入れた方がいいのではないか」、「functions.phpを変更した方がいいのではないか」と考えていました。

しかし、実際には、比較的シンプルな対策が大きな結果をもたらしました。

• 大きすぎる画像を減らす
• 不要なプラグインを整理する
• 重複している機能を整理する
• Cocoonに用意されている機能を利用する

つまり今回の経験では、高速化は「足し算」より「引き算」から始めるということに行き着きました。

PageSpeed Insightsの点数だけを追いかけない

これはとても重要なことです。スコアを上げようと色々やっていましたが、点数を上げるだけで肝心の記事については全く考えることができませんでした。

PageSpeed Insightsで100点を取ることだけを目標にすると、読者の体験にとって必要な機能まで削除してします可能性があります。

• 問い合わせフォームを削除する
• 必要な公告を全て削除する
• 便利な機能を削除する
• デザインを極端に簡素化する

おそらくスコアは上がるでしょう。しかしスコアが上がっても、ブログとして使いにくくなれば意味がありません。

高速の目的は、PageSpeed Insightsの点数を上げることではなく、読者が快適に利用できるサイトに作り直すことです。

注意：今回の97点をそのまま再現できるとは限らない

この記事で紹介した62点から97点という結果は、私の環境で得られた実測値です。

様々な要因や環境によっては全く異なる結果になることも簡単に想像できます。

• サーバー
• WordPressのバージョン
• Cocoonのバージョン
• プラグイン
• 画像
• 広告
• 外部サービス
• 記事構成

考えだしたらきりがありません。

「この設定をすれば必ず97点になる」ではなく「自分のサイトを測定し、原因を確認すること。一つずつ変更して再測定の繰り返し」が大事です。

よくある質問（FAQ）

まとめ

まとめ：高速化は「減らしてから整える」

今回、私のサイトではPageSpeed InsightsのPerformanceスコアを62点から97点まで改善できました。

特に効果が大きかったのは、次の7つだと思っています。

1. 画像を適切なサイズに縮小する
2. WebPなどを利用して画像を軽量化する
3. 不要なプラグインを整理する
4. 重複している機能があればどちらかを減らす
5. Cocoonの標準高速化機能を利用する
6. 設定変更後に必ずサイトを確認する
7. PageSpeed Insightsで再測定する

今回の検証で一番印象に残ったのは、高速化のために何かを追加するより、不要なものを減らす方が効果的だったことです。

そして、すべての設定を一度に変更するのではなく、一つずつ変更して結果を確認することで、「何が自分のサイトに効いたのか」も見えるようになりました。

62点から97点になったことは嬉しい結果です。しかし、この記事で伝えたいのは「97点を取る方法」ではありません。「自分のサイトを測定し、原因を確認し、対策し、もう一度測定する」。

この繰り返しこそが、WordPressの高速化では一番確実な方法だと、今回の検証を通して感じました。

リファレンス

• Google PageSpeed Insights
• Google Search Central：Core Web Vitals
• web.dev：Web Vitals
• Cocoon公式：おすすめのサイト高速化設定
• Cocoon公式：よくある質問と答え
• WordPress公式：XML Sitemaps

更新履歴

• 2026年9月22日：サイト見直しに伴いタイトルを簡素化
• 2026年8月25日：記事構成を全面的に見直し、Windows 11 64bit環境での手順と公式仕様を整理
• 2026年7月20日：記事を更新
• 2025年4月20日：初公開