Does this plugin cache pages itself?

No. Caching happens server-side: in the optimizer worker itself, or — on the 1.15 line — in a front cache (nginx proxy_cache, Varnish, or a CDN). The plugin only sets cache headers and sends purge requests. WordPress does not send Cache-Control: public on anonymous pages by default; the plugin adds it, with explicit bypasses for logged-in users, WooCommerce cart, checkout and account pages, search, feeds, and 404s.

I run mod_pagespeed / ngx_pagespeed — do I get full-page caching?

Not from the module alone. The module is a streaming rewriter; it does not cache HTML (its in-place cache holds optimized images, CSS, and JavaScript). For full-page caching with the module alone, put an external cache in front (nginx proxy_cache, Varnish, or a CDN) and set ModifyCachingHeaders off so the plugin's headers reach that cache. With the module, the plugin's purge calls evict optimized sub-resources and metadata, not HTML pages.

Does it work without mod_pagespeed installed?

No. mod_pagespeed must be running on your web server for the plugin to do anything — it is a control panel for the server module, not a standalone WordPress caching plugin like WP Rocket. The setup wizard detects your server and points you at the installation docs if none is found.

Which mod_pagespeed versions are supported?

mod_pagespeed 1.15 (v1.15.0+r3 or later) or ModPageSpeed 2.0 (v2.0.0 or later). The plugin auto-detects which one is running and adjusts its behavior accordingly.

WordPress plugin

Full-page caching for WordPress, driven by mod_pagespeed 2.1

WordPress does not send Cache-Control: public on anonymous pages, so your mod_pagespeed server never gets to cache the HTML it serves. WeAmp Cache Control for ModPageSpeed is the control panel that closes that gap: it sets the right cache headers and purges the mod_pagespeed cache the moment your content changes. The caching itself happens server-side, in the module you already run.

How to install Read the caching docs

Free and GPL-2.0. Live in the WordPress.org plugin directory.

What the plugin does

It is a control plane, not a cache. Three responsibilities, all server-aware:

Enables full-page caching

Adds Cache-Control: public, max-age=N to anonymous responses, with automatic bypasses for logged-in users, WooCommerce cart, checkout and account pages, search, feeds, and 404s.

Keeps the cache fresh

Calls the mod_pagespeed purge API on publish, update, delete, comment changes, WooCommerce stock changes, and term or theme-setting changes. Wildcard purges are refused, so a stray value can't flush the whole cache.

Gives you control

Per-post-type TTLs, a cookie bypass list, excluded URL patterns, a first-run setup wizard, and wp pagespeed flush|status|test-connection on the command line.

Works with the module and the optimizer worker — with one real difference

The plugin detects what your server runs and behaves accordingly. How full-page caching lands depends on whether the optimizer worker's cache is in the request path — the difference is real, so here it is exactly.

The optimizer worker

The optimizer worker caches full HTML pages itself. The plugin's headers and purge calls drive the worker's page cache directly — no extra layer required. This is the path that needs no front cache.

The module (mod_pagespeed / ngx_pagespeed)

The module is a streaming rewriter; it does not cache HTML. Full-page caching needs a front cache (nginx proxy_cache, Varnish, or a CDN) plus ModifyCachingHeaders off. The plugin's purge calls there evict optimized sub-resources, not pages.

Install

1. Install mod_pagespeed on your web server first — version 1.15.0+r3 or later; mod_pagespeed 2.1 is the current release. See the install guide.
2. Install it from the WordPress.org plugin directory. In WordPress admin, go to Plugins → Add New, search for WeAmp Cache Control for ModPageSpeed, install and activate. (Prefer to install by hand? Download the zip from the directory and upload it via Plugins → Add New → Upload Plugin.)
3. Open Settings → ModPageSpeed and run the setup wizard: detect the server, enter the admin API URL, test the connection, apply the nginx snippet it hands you, enable caching, and run a test purge.

For the optimizer worker, the admin API must be enabled (--api-port). For correct logged-in behavior on nginx, the wizard provides a copy-paste cookie-bypass map block and verifies it.

WordPress caching with mod_pagespeed: common questions

Does this plugin cache pages itself?: No. Caching happens server-side: in the optimizer worker itself, or — on the 1.15 line — in a front cache (nginx proxy_cache, Varnish, or a CDN). The plugin only sets cache headers and sends purge requests. WordPress does not send Cache-Control: public on anonymous pages by default; the plugin adds it, with explicit bypasses for logged-in users, WooCommerce cart, checkout and account pages, search, feeds, and 404s.
I run mod_pagespeed / ngx_pagespeed — do I get full-page caching?: Not from the module alone. The module is a streaming rewriter; it does not cache HTML (its in-place cache holds optimized images, CSS, and JavaScript). For full-page caching with the module alone, put an external cache in front (nginx proxy_cache, Varnish, or a CDN) and set ModifyCachingHeaders off so the plugin's headers reach that cache. With the module, the plugin's purge calls evict optimized sub-resources and metadata, not HTML pages.
Does it work without mod_pagespeed installed?: No. mod_pagespeed must be running on your web server for the plugin to do anything — it is a control panel for the server module, not a standalone WordPress caching plugin like WP Rocket. The setup wizard detects your server and points you at the installation docs if none is found.
How does it keep the cache fresh?: It calls the mod_pagespeed purge API when content changes: publishing, updating, or deleting a post; comment changes; WooCommerce stock changes; and term or theme-setting changes. Purge values are always absolute URLs, and wildcard purges are refused outright to avoid an accidental full-cache flush.
Which mod_pagespeed versions are supported?: mod_pagespeed 1.15 (v1.15.0+r3 or later) or ModPageSpeed 2.0 (v2.0.0 or later). The plugin auto-detects which one is running and adjusts its behavior accordingly.

Add it to your WordPress site

Install mod_pagespeed on the server, activate the plugin, and run the wizard. Anonymous pages start carrying cache headers and the cache stays fresh as you publish.

How to install See pricing

The plugin is free and GPL-2.0, and mod_pagespeed itself is open source under the Apache License 2.0 — free in development and in production.