mod_pagespeed vs NitroPack

TL;DR

NitroPack is a managed SaaS that plugs into WordPress (and other PHP stacks) and offloads optimization to its cloud. mod_pagespeed runs on your server and does the same kind of work without sending content to a third party. NitroPack is faster to set up and takes the operational ownership off your hands. mod_pagespeed is for teams that want the optimization layer and the data path on their own servers.

At a glance

When to choose NitroPack

• You run WordPress (or WooCommerce) and want optimization with no server-side operations work. Plugin install, account signup, done.
• You don't have a sysadmin or DevOps engineer and don't want to acquire one for this problem.
• You're willing to pay a monthly subscription tiered by traffic to avoid running anything yourself.
• You want a vendor support line you can call when something breaks at 2 AM.
• The dashboard, reporting, and managed CDN are part of the value, not just the optimization.

When to choose mod_pagespeed

• You don't run WordPress, or you run more stacks than just WordPress. NitroPack's strongest support is on WordPress; the mod_pagespeed 2.1 in-process module runs on any nginx, Apache, or IIS host. The IIS package ships from the 1.15 packaging channel.
• You want no bill that tracks pageviews at all. NitroPack's tiers meter monthly traffic; mod_pagespeed 2.1 is free under the Apache License 2.0 at any volume, on any number of servers.
• You don't want your HTML routed through a third-party processor — for compliance, latency, or principle.
• You have the operational capacity to run a Docker image or nginx module and would rather own that surface than pay for a hosted equivalent.
• You want software licensed under the Apache License 2.0 rather than a proprietary service.

How they overlap

The list of optimizations both products perform is broadly similar: image compression and format conversion, lazy loading, CSS/JS minification, critical CSS, HTML caching, and the rest of the filter set. Both target Core Web Vitals — mod_pagespeed through LCP, render-blocking, and image work; INP and most CLS are application-side and outside its scope.

Where they differ is the deployment model and the cost model. NitroPack does the work in its cloud and meters each site by monthly traffic tier; mod_pagespeed does the work on your servers and is free to run, with no traffic meter.

Migrating from NitroPack to mod_pagespeed

Migration is reasonable if your traffic outgrew NitroPack's pageview tiers, if your stack diversified beyond WordPress, or if compliance constraints rule out third-party content processing.

mod_pagespeed is the right move when you want optimization to live on your origin and keep content out of a vendor's data center — compliance, multi-tenant hosting, or no per-request or per-GB bill at all: the software is free.

If you do migrate:

1. Stand up mod_pagespeed on a staging origin and verify the filters you depended on (critical CSS, image variants) produce comparable Lighthouse numbers. The Docker Compose walkthrough is a 60-second baseline.
2. Disable NitroPack's plugin before enabling mod_pagespeed's filters so the two don't double-process HTML.
3. If you relied on NitroPack's CDN, decide whether to put a generic CDN (Cloudflare, Fastly, BunnyCDN) in front of mod_pagespeed or run origin-only.
4. Recreate any per-page optimization exclusions in mod_pagespeed's filter configuration.

Code & config side-by-side

Enabling NitroPack: install the WordPress plugin, sign up, paste the site ID. Optimization happens in NitroPack's cloud — no server-side config.

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 filters (nginx config, one-time):

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

The same response is generated, but the work happens inside your nginx process instead of inside someone else's data center. The trade is operational ownership against vendor lock-in and traffic-tier cost scaling.