mod_pagespeed vs Cloudflare APO

TL;DR

Cloudflare APO caches your WordPress HTML at Cloudflare's edge and serves it from there. mod_pagespeed runs on your origin server and optimizes the response itself — images, CSS, JS, and HTML. APO is faster to enable if you're on WordPress and already on Cloudflare. mod_pagespeed is the option when you want the optimization to live on your infrastructure and work across platforms.

At a glance

When to choose Cloudflare APO

• You're already on Cloudflare and your site is WordPress. The setup is essentially "install the plugin, flip the switch."
• You want a managed solution with no origin tuning. APO is configured in the Cloudflare dashboard, not on your server.
• Your origin is geographically distant from most visitors and the dominant performance problem is TTFB. Edge HTML caching addresses that directly.
• You don't want to maintain a build pipeline or an nginx module — you'd rather pay Cloudflare to do it.
• You don't need critical CSS extraction or origin-side image variant generation.

When to choose mod_pagespeed

• You're not on WordPress. APO is WordPress-only; mod_pagespeed works on any stack that runs nginx, Apache, or IIS.
• You don't want to route your traffic through Cloudflare. APO requires it as a hard dependency.
• You want the optimization to follow the site, not the CDN — if you migrate CDNs, the optimization stays.
• You care about critical CSS for LCP. That's an origin-side rewrite; an edge cache doesn't extract it.
• You scale horizontally at the origin. mod_pagespeed 2.1 is free under the Apache License 2.0 on however many servers you run behind it; the server count never enters the bill.
• You need to keep content on your infrastructure for compliance or data-residency reasons.

How they overlap

Both improve Core Web Vitals and ship fewer bytes. Each also composes with the other tools in its ecosystem — APO with Cloudflare Polish, mod_pagespeed with whatever CDN sits in front of it.

The genuine overlap is HTML minification and basic asset handling. Where they diverge is where the optimization runs (edge vs origin) and what's in scope (HTML cache vs the full origin pipeline).

You can also run them together: mod_pagespeed at the origin, Cloudflare in front for global caching. The optimization happens once at the origin and benefits from edge distribution.

Migrating from Cloudflare APO to mod_pagespeed

Migration is reasonable if you've outgrown WordPress, moved off Cloudflare, or need optimization beyond what APO does — critical CSS, origin-side AVIF encoding, or a single pipeline that follows the site across CDN changes.

If you do migrate:

1. Keep APO enabled while you stand up mod_pagespeed on the origin. Verify origin-side optimization works in a staging environment.
2. Disable APO before going live so the two tools don't fight over HTML rewriting. (Cloudflare retired its separate Auto Minify feature in August 2024.)
3. Leave Cloudflare in front as a plain CDN if you want global distribution — mod_pagespeed's cache hits compose cleanly with it.

Code & config side-by-side

Enabling APO: install the Cloudflare for WordPress plugin, then toggle APO in the Cloudflare dashboard. No server-side configuration.

Installing mod_pagespeed 2.1 for nginx on Debian 11/12/13, Ubuntu 22.04/24.04 (amd64 + arm64), or AlmaLinux 9 (x86_64 + aarch64):

curl -fsSL https://packages.modpagespeed.com/install.sh | sudo sh
sudo apt install nginx-module-pagespeed   # or: sudo dnf install nginx-module-pagespeed

Then enable the equivalent of APO (nginx config):

pagespeed on;
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters convert_jpeg_to_webp,rewrite_css,rewrite_javascript,prioritize_critical_css;
pagespeed FileCachePath /var/cache/pagespeed;

CoreFilters is the audited default set. The specific filters above show that critical-CSS extraction is in scope on the origin side — which it isn't in APO.