ModPageSpeed vs imgproxy

TL;DR

imgproxy is a focused, self-hosted image processing server. ModPageSpeed 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 mod_pagespeed used to provide, ModPageSpeed 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 ModPageSpeed

• 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 — WebP across 1.15 and 2.0, AVIF from the 2.0 worker. 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 ModPageSpeed

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. ModPageSpeed collapses those layers into one process.

If you're collapsing multiple optimization layers into one, ModPageSpeed 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. ModPageSpeed 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). ModPageSpeed handles HTML-referenced images; user-upload pipelines may still belong in a dedicated service.
3. Point nginx at the ModPageSpeed interceptor 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 1.15. Install the nginx module on Debian 11/12/13, Ubuntu 22.04/24.04 (amd64 + arm64), or AlmaLinux 9 (amd64):

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. ModPageSpeed makes the decision at HTML-rewrite time based on the client's Accept header.