mod_pagespeedは、Apacheが返すHTML・CSS・JavaScript・画像を配信時に自動で書き換えて軽くするモジュールですが、現在はGoogleのサポートが終了し、引き継いだApacheのプロジェクトも活動を終えています。新しく導入するのはおすすめできず、すでに使っている場合も、Apache標準のモジュールとWordPress側の仕組みへ置き換えていくのが現実的です。この記事では、mod_pagespeedの現状とリスク、使い続ける場合の最小限の安全な設定、そして同じ効果を今のやり方で得る方法を説明します。
mod_pagespeedの現状（2026年10月現在）
mod_pagespeedはGoogleが2010年に公開したオープンソースのモジュールで、Nginx版のngx_pagespeedとあわせて「PageSpeedモジュール」と呼ばれていました。その後、2017年にApache Software FoundationのIncubator（新規プロジェクトの育成の枠組み）へ移されましたが、開発は活発にならず、Incubatorのプロジェクトとしても退役（retired）しています。Google側のサポートもすでに終了しており、安定版のリリースは2010年代後半を最後にほぼ止まっています。
これが意味するのは次のようなことです。
- セキュリティ修正が出ない：HTMLを解析して書き換えるという性質上、扱う入力が多く、脆弱性が見つかっても修正される見込みがありません
- 新しいOSでの動作が保証されない：配布されていたパッケージは古いライブラリを前提にしており、新しいディストリビューションやApacheの更新で動かなくなる可能性があります
- Webの変化に追従していない：HTTP/2・HTTP/3の普及、AVIFなどの新しい画像形式、Core Web Vitalsの指標の変更（2024年にFIDからINPへ）などを前提にした設計になっていません
mod_pagespeedがしていたこと
置き換えを考えるために、主な機能（フィルタ）を整理しておきます。
- CSS・JavaScriptの最適化：
rewrite_css、rewrite_javascriptによるミニファイ、combine_css、combine_javascriptによるファイル結合 - 画像の最適化：
rewrite_imagesによる再圧縮やリサイズ、convert_jpeg_to_webpによるWebP変換、lazyload_imagesによる遅延読み込み - HTMLの整理：
collapse_whitespace、remove_comments - キャッシュの延長：
extend_cacheで、リソースのURLに内容のハッシュを付けて長期間キャッシュさせる - 表示の優先順位付け：
prioritize_critical_cssで、最初の表示に必要なCSSだけをインライン化する
ModPagespeedRewriteLevel CoreFilters（既定）では、比較的安全とされるフィルタの組み合わせが有効になります。
使い続ける場合の最小限の設定
すぐに外せない事情がある場合は、影響範囲を絞り、問題が起きたときに切り分けやすい設定にしておきます。設定を変える前に、現在の設定ファイルのコピーを取っておきます。Debian/Ubuntuでは /etc/apache2/mods-available/pagespeed.conf が設定ファイルです。
<IfModule pagespeed_module>
ModPagespeed on
ModPagespeedRewriteLevel CoreFilters
ModPagespeedFileCachePath "/var/cache/mod_pagespeed/"
ModPagespeedFileCacheSizeKb 102400
# WordPressの管理画面・ログイン・REST APIは書き換えない
ModPagespeedDisallow "*/wp-admin/*"
ModPagespeedDisallow "*/wp-login.php*"
ModPagespeedDisallow "*/wp-json/*"
# HTTPSのリソースはネットワーク経由ではなくディスクから読む
ModPagespeedLoadFromFile "https://example.com/" "/var/www/html/"
<Location /pagespeed_admin>
Require ip 127.0.0.1
SetHandler pagespeed_admin
</Location>
</IfModule>ポイントは次のとおりです。
- 管理画面を除外する：ブロックエディターなどの管理画面のJavaScriptが書き換えられると、ボタンが反応しない、保存できないといった不具合の原因になります
- **
ModPagespeedLoadFromFileを設定する**：mod_pagespeedは最適化対象のCSSや画像を自分で取得しに行きます。HTTPSのサイトではこの取得がうまくいかず、最適化されないまま素通りしていることがよくあります。ディスク上のファイルを直接読ませるとこの問題を避けられ、サーバーへの余計なリクエストも減ります - 管理ページはローカルからのみ：
/pagespeed_adminでは統計やキャッシュの状態を確認できますが、外部に公開してはいけません
動作しているかは、レスポンスヘッダーに X-Mod-Pagespeed が付いているかで確認できます。
curl -sI https://example.com/ | grep -i x-mod-pagespeed表示崩れが起きたら、URLに ?PageSpeed=off を付けて開き、崩れが直ればmod_pagespeedが原因です。そこから ModPagespeedDisableFilters で怪しいフィルタを1つずつ止めて特定します。キャッシュを消したいときは、キャッシュディレクトリに cache.flush というファイルを作成（touch）すると、内容の破棄が行われます。
もう1つ注意したいのが、WordPressのキャッシュプラグインとの二重最適化です。プラグイン側でCSSやJavaScriptの結合・ミニファイを有効にしたままmod_pagespeedも動かすと、すでに加工されたファイルをさらに加工することになり、不具合の切り分けが難しくなります。最適化はどちらか一方に任せます。
代わりの方法：同じ効果を今のやり方で得る
mod_pagespeedの各機能は、現在ではApache標準のモジュールやWordPressのコア機能、プラグイン、CDNで置き換えられます。
| mod_pagespeedの機能 | 現在の主な代替手段 |
|---|---|
| テキストの圧縮 | Apacheの mod_deflate（gzip）、mod_brotli（Brotli） |
extend_cache |
mod_expires と mod_headers によるCache-Controlの設定 |
| CSS・JSのミニファイ・結合 | キャッシュプラグインや最適化プラグインの機能、テーマのビルド工程 |
| 画像の再圧縮・WebP変換 | WordPressの画像変換プラグイン、CDNの画像最適化機能 |
lazyload_images |
WordPressコアの loading="lazy"（5.5以降） |
| HTMLの生成負荷の削減 | ページキャッシュ（キャッシュプラグイン、mod_cache） |
圧縮とブラウザキャッシュはApacheで設定する
テキストの圧縮とキャッシュ期間の設定は、mod_pagespeedよりも単純で、効果も予測しやすい方法です。
<IfModule mod_brotli.c>
<IfModule mod_deflate.c>
AddOutputFilterByType BROTLI_COMPRESS;DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>
</IfModule>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/webp "access plus 6 months"
ExpiresByType image/avif "access plus 6 months"
</IfModule>mod_brotli はApache 2.4.26以降で使えます（sudo a2enmod brotli deflate expires で有効化）。BROTLI_COMPRESS;DEFLATE と2つのフィルタを続けて指定すると、Brotliに対応したブラウザにはBrotliが、それ以外のブラウザにはgzipが使われます。CSSやJavaScriptに長いキャッシュ期間を設定する場合は、更新時にURLが変わる仕組み（WordPressがファイルの末尾に付ける ?ver= など）があることが前提です。
HTTP/2を有効にして「結合」の必要性を減らす
mod_pagespeedがCSSやJavaScriptを結合していたのは、HTTP/1.1では同時に取得できるファイル数が限られていたためです。HTTP/2では1つの接続で多数のファイルを並行して取得できるので、無理に結合する利点は小さくなりました。Apacheでは mod_http2 を有効にし、Protocols h2 http/1.1 を設定します。prefork MPMではHTTP/2の性能が十分に出ないため、event MPMとPHP-FPMの組み合わせに移行するとあわせて効果があります。
画像はアップロード時に最適化する
配信のたびに画像を変換するより、アップロード時やビルド時に最適化しておくほうがサーバーの負荷が少なく、結果も安定します。WordPressは5.8でWebP、6.5でAVIFのアップロードに対応しており、レスポンシブ画像の srcset や、6.3以降はLCP候補の画像への fetchpriority="high" もコアが自動で付けます。既存の画像をまとめて変換するには、画像最適化プラグインかCDNの画像変換機能を使います。
mod_pagespeedから移行する手順
- 現状を計測する：PageSpeed InsightsやLighthouseで、主要なページのLCP・INP・CLSと、TTFBを記録します。mod_pagespeedが実際にどれだけ効いていたかを知るためです
- 代替手段を先に入れる：圧縮・キャッシュ期間・ページキャッシュを設定し、ステージング環境で表示を確認します
- mod_pagespeedを無効にする：
sudo a2dismod pagespeedを実行し、sudo apachectl configtestで構文を確認してからsudo systemctl restart apache2で反映します - 再計測して比較する：数値が悪化したページがあれば、どの機能が効いていたのかを確認して、対応する代替手段を追加します
- 後片付け：問題がなければパッケージを削除し、
/var/cache/mod_pagespeed/のキャッシュと、インストール時に追加されたGoogleのAPTリポジトリ設定が残っていればそれも削除します
多くのWordPressサイトでは、ページキャッシュと圧縮・キャッシュ期間の設定だけで、mod_pagespeed使用時と同等かそれ以上の結果になります。表示速度を左右しているのが重いプラグインや大きな画像であれば、配信時の書き換えではそもそも解決しないため、原因そのものを直すほうが効果的です。
まとめ
- mod_pagespeedはGoogleのサポートが終了し、Apache Incubatorのプロジェクトとしても退役している。新規導入は避ける
- 使い続ける場合は、管理画面・ログイン・REST APIを除外し、
ModPagespeedLoadFromFileを設定し、キャッシュプラグインとの二重最適化を避ける - 圧縮は
mod_deflateとmod_brotli、キャッシュ期間はmod_expires、結合の代わりはHTTP/2、画像はアップロード時の最適化で置き換えられる - 移行は「計測 → 代替手段の導入 → 無効化 → 再計測 → 後片付け」の順で進め、数値で効果を確かめる