mod_pagespeed vs imgproxy

TL;DR

imgproxy is a focused, self-hosted image processing server. mod_pagespeed is a self-hosted optimization pipeline that includes image work plus critical CSS, JS/CSS minification, and HTML rewriting. If image transformations are all you need, imgproxy is a smaller, sharper tool. If you want the full page-level optimization layer that the original mod_pagespeed provided, mod_pagespeed 2.1 is the closer fit.

At a glance

When to choose imgproxy

• You only need image processing — resizing, format conversion, smart cropping.
• You already have your own caching layer (Varnish, nginx, a CDN) and prefer to wire image processing in as a discrete service.
• You want a stateless URL-based transform API where every parameter is in the URL.
• Your stack isn't HTML-centric — you're serving images to native apps, signed URLs, or storage pipelines.
• You like the operational model of one binary, one Dockerfile, one job.

When to choose mod_pagespeed

• You want one process that handles images, CSS, JS, and HTML — the way mod_pagespeed used to.
• You're on nginx and want optimization wired into the response path, not as a separate service.
• You care about critical CSS extraction and inlining for LCP — that's not in imgproxy's scope.
• You want the cache and the optimizer to share a model of the request (viewport, format support, save-data) rather than wiring that into URLs yourself.
• You're migrating from mod_pagespeed and want the closest functional successor.

How they overlap

Both tools convert source images to modern formats and produce resized variants; on the mod_pagespeed side that is WebP and AVIF. Both run on your servers with no third-party data path. Both are pull-based: the image gets optimized when it's first requested, then served from cache.

The genuine overlap is image format conversion and responsive sizing. For everything outside images, the products don't compete — they solve different problems.

Migrating from imgproxy to mod_pagespeed

Migration is reasonable if imgproxy was a partial solution and you ended up writing scripts to minify CSS, generate critical CSS, or rewrite HTML around it. mod_pagespeed collapses those layers into one process.

If you're collapsing multiple optimization layers into one, mod_pagespeed handles the whole HTML response — images, CSS, JS, critical CSS — from a single worker, with decision-time format selection driven by the client's Accept header.

If you do migrate:

1. Identify the imgproxy URL patterns your templates emit. mod_pagespeed rewrites image URLs at the HTML layer, so template changes may be unnecessary.
2. Decide whether you still want a separate transform endpoint for signed URLs (e.g., user uploads). mod_pagespeed handles HTML-referenced images; user-upload pipelines may still belong in a dedicated service.
3. Point nginx at the mod_pagespeed module and verify the cache directory has write access from both nginx and the worker. The Docker Compose walkthrough covers a working baseline.

Code & config side-by-side

WebP conversion in imgproxy (URL-based):

/insecure/rs:fit:800:600/f:webp/plain/https://example.com/photo.jpg

WebP conversion in mod_pagespeed 2.1. Install the nginx module 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 filter (nginx config; it decides per-request from the client's Accept header):

pagespeed on;
pagespeed EnableFilters convert_jpeg_to_webp;
pagespeed FileCachePath /var/cache/pagespeed;

The difference is where the decision lives. imgproxy requires per-URL parameters in templates or signed URLs. mod_pagespeed makes the decision at HTML-rewrite time based on the client's Accept header.