CocoonでPageSpeed Insightsを62点から97点へ改善した実測記録。本当に効果があった高速化だけ紹介します(2026年7月20日更新)

WordPressでブログを始めると、多くの方が一度は「Google PageSpeed Insights」のスコアを気にするのではないでしょうか。もちろん私もその一人です。

Google Search ConsoleやPageSpeed Insightsを確認すると、モバイルのPerformanceスコアは62点という低スコアでした。改善項目にはLCPやCLS、JavaScript、画像最適化などが並び、「どこから手を付ければいいのか分からない」という状態に頭を悩ませます。

そこで、設定を一つずつ変更し、その都度PageSpeed Insightsで測定するという方法で検証を始めました。

闇雲にfunctions.phpをいじったり高速化プラグインを導入するのではなく、「何を変更したのか」、「スコアはどれだけ変わったのか」、「効果はどれくらいあったのか」これらを記録しながら改善を進めた結果、Performanceスコアは62点から97点まで向上しました。

パフォーマンスのスコアが低い
パフォーマンスのスコアが低い

結論

ネット上ではさまざまな対策が紹介されていましたが、私の環境では次の対処法が効果的でした。

優先順位改善内容効果
★★★★★不要プラグインの削除非常に大きい
★★★★★画像のWebP化・軽量化非常に大きい
★★★★☆画像のレイアウト調整(CLS対策)大きい
★★☆☆☆CSS・JavaScriptの縮小化小さい

ネット上でよく紹介されていた設定の中には、軽量化プラグインの導入やfunctions.phpをいじるなどありましたが、私の環境ではほとんど効果が確認できませんでした。

つまり、高速化は「設定を増やすこと」ではなく、「本当に必要なものだけを残すこと」が重要だと感じています。

この記事でわかること

この記事では、次の内容について実体験をもとに解説します。

  • PageSpeed Insightsとは何か
  • Core Web Vitalsが重要と言われる理由
  • Cocoonテーマで実施した改善内容
  • 62点から97点まで改善した実測結果
  • 効果があった改善とほとんど変化がなかった改善方法
  • 高速化とユーザー体験を両立する考え方

単なる設定方法ではなく、「実際に試してどうだったか」という経験を重視しました。

検証環境

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

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

※本記事の結果は筆者環境で測定したものであり、すべての環境で同じ結果になるとは限りません。

CocoonでPageSpeed Insightsを改善した実際の手順

改善前のPerformanceスコアは62点でした。

特に指摘されていた項目は次の3つです。

項目改善前
Performance62
LCP4.1秒
INP改善が必要
CLS0.18

調べてわかったことですが、表示速度だけではなく、レイアウトのズレ、Javascriptの読み込み時間にも難ありでした。

この時点では、ネット上で紹介されていた高速化方法をそのまま試しても、スコアはあがるけれども期待していたほどあがりませんでした。とくに高速化プラグインを入れると逆にスコアが下がるということもありました。

なぜスコアが期待通りにあがらなかったのか、一つずつ設定を変更し、その都度PageSpeed Insightsで測定しようと思いました。

実践 1:画像のWebP化

結局のところ、記事の中で一番表示に時間がかかるのは画像でした。PageSpeed Insightsでは、改善項目として「次世代フォーマットでの画像」や「画像サイズの最適化」と表示されていました。

私はJPEGで画像をアップロードしていたため、LCP(Largest Contentful Paint)の遅延要因となっていました。

そこで始めに取り組んだことは画像の最適化です。

WebP化と容量の調整

プラグインの中にはメディアを一括でWebP化できるものもあります。しかし実際には単にプラグインで一括処理するだけではスコアを大きく変動させられないと思いました。

検証の結果、元の画像が大きい場合、WebP化しても大きいままだということです。

  • 元画像が3000px以上ある
  • JPEGをただWebPに変換しただけ
  • 品質が100%で保存している

このような画像では、WebPになっていてもファイルサイズが大きく、体感として表示速度の改善はできても、スコアはの改善にはつながりませんでした。

そこで画像編集ソフトを使い、PC側で編集をしてから記事に張り付けるようにしました。

  • 長辺を500pxに抑える
  • WebP形式で保存
  • 品質を50%まで落としてエクスポート
  • ファイルサイズを15KB未満にする

私は無料と言うことでGIMPを画像編集に使っていますが、最近はAffinityなどもあります。品質を調整することで、見た目はあまり変わらずに数十KBまでサイズを減らすことができます。

ひと手間かかりますが、LCPだけでなく、スマホで見ている人の通信料削減にもつながります。やっておいて損になることはないでしょう。

Lazy Loadを有効化する

画像はページ表示と同時にすべて読み込む必要がありません。Cocoonには標準でLazy Load(遅延読み込み)の機能が入っています。

設定の仕方は、Cocoon設定→高速化→Lazy Loadにチェック、これで有効化ができます。

Lazy Loadを設定することで、画面外の画像はスクロールされるまで読み込まれなくなり、初期表示が軽くなることが期待できます。

画像を多用するレビュー系記事やHowTo系の記事では大きく効果があるのではないでしょうか。

検証をして感じたこと

画像の最適化は、PageSpeed Insightsの点数を上げりためだけの対策ではありません。実際に自分のスマホでページを開いてみて表示が軽くなったと体感でわかるほどの改善でした。

記事を読む側にとっても、画像がすぐ表示されることはストレスの軽減につながります。画像の最適化は得しかないため、最優先で行うべき改善だと思います。

実践 2:不要なプラグインの整理

はじめに画像の最適化を行いました。しかしそれは手軽に始められることができて、これからも習慣づけて画像をWebP化する癖をつけるためでした。

今回の高速化の中で、一番効果があったのはこの「プラグインの整理」です。

WordPressはプラグインが豊富な上、簡単に便利機能を追加できます。一方プラグインを増やしすぎるとJavaScriptやCSSが増え、表示速度やCore Web Vitalsに悪影響を与えかねません。

もちろん「プラグインが多い=遅い」という単純な話ではありません。

しかし、同じ機能を持つプラグインを重複して導入していたり、使っていない機能を放置して読み込んでいるだけの状態にしている場合、無駄な処理が積み重なり、結果として最初の読み込みが重くなります。

特にSite Kit by GoogleやYoast SEOにAll In One SEOのような便利だけど巨大なプラグインは削除するか、機能の重複があるため、どれか一つだけ残すといった方法が効果的です。

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

高速化に取り組む前、私の環境では次のプラグインを導入していました。

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

どれも有名なプラグインですが、内容を精査すると他のプラグインと機能が重複していたり、そもそもCocoonで完結できる機能だったりするものがありました。

Cocoonの標準機能と重複していたもの

Yoast SEO:
Yoast SEOは優れたSEOプラグインですが、CocoonにはSEOに関する基本的な機能が標準で備わっていることがわかりました。

  • title設定
  • メタディスクリプション
  • OGP(Open Graph Protocol)関係
  • 構造化データ
  • パンくずリスト

これらは重複しています。

Site Kit by Google:
Site Kit by Googleはブログに関する様々なデータを可視化できるとても優秀なプラグインです。

  • Google Search Console
  • Google Analytics
  • Google Adsense
  • PageSpeed Insights

特にこの4つを管理画面で確認できることは本当に便利としか言えません。

しかし多機能であるということは、その裏側では多くのスクリプトを読み込んでいる可能性があります。

Search Consoleは気が向いたら公式サイトで確認、Analyticsもブラウザで確認、Adsenseも公式で確認、PageSpeed Insightsも頻繁に見るわけでもないため公式で確認。

Site Kit by Googleは管理画面でAnalyticsなどを表示するため、多数のJavaScriptを読み込みます。私の環境では削除した結果、LCPが大幅に改善されました。

一方で最低限のことはダッシュボードで確認ができるため、ブログの表示速度を上げるという意味ではプラスになったのかもしれません。

XML Sitemap Generator

よくよく調べてみたところ、2026年現在のWordPressではXMLサイトマップ機能が標準搭載されており、Cocoonと組み合わせても十分に運用ができました。

またGoogle Search Consoleへ登録してしまえば、もう専用プラグインを使う必要もありません。そのためXML Sitemap Generatorは役目を終えたと判断して削除しました。

Cocoonでの設定

高速化にあたりCocoonでの設定はとても簡単です。ほぼ全てのものがCocoon設定でチェックボックスにチェックをいれるだけです。

チェックをいれる項目はつぎの5項目です。functions.phpをいじるなど難しいことは何もありません。

  • Google Fonts遅延
  • CSS縮小化
  • JavaScript縮小化
  • Lazy Load

これだけ設定の設定で2~4くらいスコアが変わります。

全てのプラグインを削除すればいいわけではない

かなりのプラグインの削除をすすめてきましたが、全てを削除すればいいというわけではないです。

私の環境ではContact Form 7は軽量な上、サイト運営に欠かせないプラグインであるため削除対象外にしました。また人によってはセキュリティ系やバックアップ系を導入していると思います。これらサイト運営に欠かせないプラグインまで削除してしまうと不都合なことが起きてきます。

高速化が目的ではなく「不要なものを削った結果高速化した」という形が理想的です。

プラグインを削除して思うこと

高速化の記事では「CSSを圧縮しましょう」や「JavaScriptを最適化しましょう」といったテクニカルな内容の記事が紹介されていることが多いです。

しかし、私の環境で最も効果があったのは、そういった細かな設定ではありませんでした。

「重複を削り本当に必要なプラグインだけを残す」

それだけで、不要なスクリプトやスタイルシートの読み込みが減り、サイト全体の高速化が行えました。

便利だと紹介されていたからという理由でプラグインを追加する前に、「本当に必要な機能なのか」「すでに導入しているプラグインと競合していないか」「そもそもWordPressやテーマの機能で代用はできないか」と一度立ち止まることが、高速化への近道なのかもしれません。

実践 3:Cocoonの高速化設定は仕上げの役割

画像の最適化とプラグインの整理が終わった段階でかなり軽くなったと思います。最後にCocoonの高速化設定を見直します。

調べるとネット上では次のようなことが紹介されていました。

  • JavaScriptを遅延読み込みする
  • CSSを縮小化する
  • Google Fontsを遅延読み込みする

このあたりが主要な対策でした。もちろんこれらは意味があり、改善に繋がると思います。

しかし残念なことに私の環境では期待していたほどの大きな改善は見られませんでした。Cocoonを使っている方はCocoonだけで設定ができるため行った方がいいと思います。

Cocoonだけで設定する方法

Cocoonには、高速化に関する設定が標準で用意されています。

設定画面は、Cocoon設定→高速化、です。今回有効にした主な項目は次の通りです。

設定項目設定
CSS縮小化ON
JavaScript縮小化ON
Lazy LoadON
Google Fonts遅延読み込みON

追加プラグインを導入しなくても、ここまで標準機能だけで設定できます。

CSSやJavaScriptを縮小化

このCSSやJavaScriptを縮小化することに意味があるかどうかはよくわかりません。

  • 空白
  • コメント
  • 不要な改行

主にこれらが削除され、転送量を減らすことができます。しかし、よっぽど巨大なJavaScriptやCSSが書かれていない限り効果は限定的なのではないかと思ってしまいます。

もちろんPageSpeed Insightsでも推奨されています。今回の私の環境ではスコアが誤差程度、それこそ再読み込みすると数値が少し変動するくらいの効果でした。

劇的に変化しないとは言え、ボックスにチェックを入れるだけで改善が見込めるならば、有効化しておいて損はないです。

Google Fontsの遅延読み込み

Webで調べていくと多くのブログ管理者さんたちがGoogle Fontsを目の敵のように遅延読み込みさせていることに気が付きました。

調べていくと納得のいく内容が色々あることに気づかされました。そっとLazy Loadさせましょう。これだけでPageSpeed Insightsで指摘を受けていた「レンダリングを妨げるリソース」が解決しました。

ではなぜGoogle Fontsを遅延読み込みさせる必要があるのか見ていきたいと思います。

  1. ページの表示(レンダリング)をブロックする
    ブラウザはページを開いた際、Google Fontsのデータをダウンロードし終わるまで、文字の描写をブロックしてしまいます。そのため、フォントの読み込みに時間がかかると空白の時間ができます。これはCore Web VitalsのLCPに悪影響を与えます。
  2. 日本語フォントはデータ容量が重すぎるのも問題です。記号を合わせてもアルファベットとくらべるととんでもない量の差があります。英語フォントが数百程度だとすると日本語フォントはひらがな、カタカナ、数千の漢字など桁違いに重いです。
  3. ユーザー体験の悪化
    1のレンダリングのブロックによる文字の表示が一瞬送れること、標準のシステムフォントからGoogle Fontsが適用されると画面が揺れる現象がおきます。単純に迷惑である他、誤クリックの原因ということでSEO的にマイナス評価を受けます。

意味がないわけではありませんが1秒で離脱する人を防ぐことができるのならば、Google Fontsは使わない方がメリットが大きいと思います。

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

高速化の記事では「高速化設定は全部ONにしましょう」という意見が多いです。確かにそのケースが多く、その通りです。

しかしなぜ設計者側は最初から高速化をONにせず、高速化というメニューを作っているのか、ここに問題があります。

私の環境、いわゆる「おま環」という問題があります。

  • プラグインとの相性
  • JavaScriptの動作
  • 表示崩れ

色々縮小化や遅延読み込みをすることでこれらの不具合が出る可能性があります。

おすすめしたいことは「一つ設定を変更したら動作確認、問題がなければ別のを確認」という慎重な方法が良いと思います。

一度「さっきまで普通だったのに高速化したら変になった。変になったけれど何がわるいのかわからない」という状態になったことがあったため、「何が原因で表示がおかしくなったのか」が分かるようにした方がいいです。

高速化は「引き算」の考え方

今回の検証を通して感じたのは、functions.phpなど細かいところに追記したり高速化のプラグインを追加することではなく、「不要なものを徹底的に減らす」ことでした。

あたらしい高速化プラグインを追加するより、次の3つを守る方がずっと効果があります。

  • 本当に必要なプラグインだけを残す
  • 画像はWebP形式かつ品質を落とす
  • テーマの標準機能を活用する

このような基本的な改善の方が、結果として大きな効果につながりました。

Cocoonでの高速化設定は最後の仕上げのような位置づけです。最初に設定したくなりますが、画像やプラグインの整理が終わったのち、レイアウトが崩れないように確認しながら微調整します。

結局それがPageSpeed Insightsのスコアをさらに伸ばすことに繋がります。

改善結果:62点から97点へ改善できた理由

ここまで紹介した内容を一つずつ実施した結果、PageSpeed InsightsのPerformanceスコアは大きく改善されました。

もちろん一つの設定だけで97点になったわけではありません。

PageSpeed Insightsの赤い文字を読みながら思考探誤の結果、画像の最適化、不要プラグインの整理、Cocoonの高速化設定などの結果です。

問題点は人それぞれ違うと思うため、「これだけやれば97点」という記事にすることはできません。「ここだけは必ずやることで点数は上がる」というものです。

改善前と後との比較です。

項目改善前改善後
Performance6297
LCP4.1秒2.0秒
INP改善が必要良好
CLS0.180.05

※測定はPageSpeed Insights(モバイル)で実施しています。

パフォーマンスのスコアが低い
パフォーマンスのスコアが低い
パフォーマンススコアの改善
パフォーマンススコアの改善

Performanceスコアは35ポイント改善

今回最も分かりやすかったのは、Performanceスコアです。62点から97点と35ポイントの改善につながりました。

もちろん、PageSpeed Insightsは測定する時間帯やサーバーの負荷によって、大小の差はでます。

LCPは約半分まで短縮できました

LCP(Largest Contentful Paint)は、4.1秒から2.0秒となりました。

  • 画像のWebP化
  • 画像の軽量化
  • Lazy Load
  • 不要なプラグインの削除

これらが大きく関わっていると思います。個人的にはプラグインの削除が効いたかなと思います。

また、画像の多いブログでしたら、画像のWebP化は改善効果は大きいと思います。

数字ではわからない改善

PageSpeed Insightsの点数が上がったことは嬉しい結果です。しかし、それ以上に実感できたことは「ブログが軽くなった」という体感です。

画像が速く表示され、文字がすぐに表示され、UX改善つまりユーザー体験そのものが改善されたことではないでしょうか。

注意:スコア改善の落とし穴

PageSpeed Insightsは点数ゲームではありません。
高いことでデメリットはありませんが、それでユーザー体験がないがしろにされてしまうのは話が違います。

無理にスコアを上げようとした場合、次のような副作用が出ることがあります。

  • 広告を削りすぎて収益が落ちる
  • 必要な機能まで削除してユーザー体験が悪化する
  • 過度な最適化でサイトが不安定になる

重要なことは、ユーザー体験を改善した結果スコアが改善されることです。ユーザー体験が落ちてしまえば、ブログとしての価値まで損なわれてしまいます。

見に来てくれた方に必要な情報を残しながら改善すること、数値の高さよりもこちらの方が優先されるべきだと思います。

よくある質問(FAQ)

Q
PageSpeed InsightsはSEOに影響しますか?
A

PageSpeed Insightsのスコアが検索順位を決めるわけではありません。重要なことはCore Web Vitalsです。Googleがユーザー体験を評価する指標の一つです。

Q
Cocoonだけで90点以上は狙えますか?
A

情況にもよりますが、可能です。プラグインの整理や画像の最適化、注意を受けたことの改善を行うことで90点以上は狙えます。ただし、サーバーや使っているプラグイン、広告の量によって結果は大きく変わります。

Q
高速化プラグインは必要でしたか?
A

導入しませんでした。正直なところ、導入しても大きな変化が見られませんでした。WordPressやCocoonの標準機能を活用して、それでも高速化をしたいのならば追加を検討しても良いと思います。

まとめ

PageSpeed Insightsの改善というと、どうしても「100点」に近づけたいという目的になりがちです。

しかし、今回実際に検証して分かったのは、本当に大切なのはスコアではなく、読者が快適に記事を読める環境を作ることがスコア改善につながったことでした。

画像を軽くすること、不要なプラグインを整理すること、標準機能を正しく活用すること。

どれも派手なテクニックではありませんが、一つずつ積み重ねることで、私の環境ではPerformanceスコアを62点から97点まで改善できました。

この記事で紹介した方法が、そのまま皆さんの環境でも同じ結果になるとは限りません。サーバーやテーマ、利用しているプラグインの構成が違えば、効果も変わります。

リファレンス

Google PageSpeed Insights:
https://pagespeed.web.dev/

Google Developers「Core Web Vitals」:
https://web.dev/articles/vitals?hl=ja

Google Search Central「Core Web Vitals」:
https://developers.google.com/search/docs/appearance/core-web-vitals

Cocoon公式サイト:
https://wp-cocoon.com/

更新履歴

  • 2026年7月21日
  • 2025年4月20日
P
P

【この記事を書いた人】

黒瓜 勉(Lonely Lab運営):

PC-9821時代からのインターネット老人。英文学博士課程前期で培った英文一次ソースの解読を武器に、PC-98からWindows 3.1、そして現代のRaspberry Piまで、世代を超えた実機検証を行っている。

「今あるものを、もっと長く楽しむ」をテーマに、技術の流行り廃りに左右されない公式仕様に基づいた堅牢な環境構築を追求。実機検証による第一に安全性、第二に可能性、第三に再現性を担保した技術情報を発信中。

※ 本記事は実機環境で検証した内容をもとに執筆しています。動作環境やソフトウェアのバージョンが異なる場合は結果が変わる可能性があります。

詳しいプロフィール・運営方針はこちら
https://lonely1.jp/helloworld/

コメント