mod_pagespeed vs imgix

TL;DR

imgix is a managed real-time image CDN. You point it at your image storage, rewrite image URLs to an imgix domain, and it fetches, transforms, and serves each image from its own edge — resizing, cropping, and converting to WebP or AVIF on the fly via URL parameters. mod_pagespeed is a self-hosted pipeline that runs at the server layer and optimizes the whole page the origin emits — HTML, CSS, and JavaScript as well as images — without any asset leaving your servers. If you want a hosted image-rendering API and don’t mind the dependency and per-usage cost, imgix is a strong fit. If you want one self-hosted optimization layer that covers more than images and is free instead of billing per usage, mod_pagespeed is the architectural alternative.

At a glance

When to choose imgix

• You want a hosted image-rendering API and don’t want to run or scale an image pipeline yourself. imgix handles fetch, transform, and edge delivery as a service.
• Your application generates image transforms on demand — arbitrary crops, sizes, and effects driven by URL parameters — and you want that logic in the URL rather than in a build step.
• Your images already live in cloud storage (S3, Google Cloud Storage, Azure) and you want a pull-based CDN in front of them without changing where they’re stored.
• You want global image delivery from an edge network out of the box, and a usage-based bill is acceptable for your traffic profile.
• Your performance problem is mostly image weight, not render-blocking CSS/JS, so an image-only tool covers the bulk of it.

When to choose mod_pagespeed

• You want one optimization layer for the whole page, not just images. imgix does not touch HTML, CSS, or JavaScript; mod_pagespeed minifies and rewrites those and extracts critical CSS too.
• You don’t want your images to leave your origin. With imgix, source images egress to the service and are served from its edge; with mod_pagespeed, optimization happens at your server and nothing leaves it.
• You prefer no per-request or per-GB bill at all over a usage-based bill that scales with delivery bandwidth, stored images, and transform volume. mod_pagespeed 2.1 is free under the Apache License 2.0, on any number of servers; see pricing for optional support plans.
• You want to avoid a third-party dependency in the request path for image delivery, keeping the optimization layer inside infrastructure you control.
• You care about origin-side image variant generation — WebP and AVIF — and want the format chosen from the request’s Accept header at serve time, on your own server.

How they overlap

The overlap is image optimization. Both convert images to WebP and AVIF, resize and crop them, and choose a modern format based on what the browser supports. For a page whose only performance problem is heavy images, the two cover similar ground — one from a managed edge, one from your own server.

The difference is scope and location. imgix is image-only and runs as a service in front of your storage; mod_pagespeed also handles CSS, JS, and HTML, and runs at your origin. Render- blocking stylesheets and unminified scripts are outside imgix’s remit entirely.

There’s also an axis a remote image CDN doesn’t touch at all: the HTML itself. Because mod_pagespeed rewrites markup at your origin, origin-side HTML rewriting and lighter markup improve what crawlers and AI agents actually see — the document they parse, not just the images on it. imgix never sees that document. See AI readability for where that line of work is headed.

You can also run them together: imgix for image delivery, mod_pagespeed for the rest of the HTML pipeline. They don’t conflict if mod_pagespeed’s image filters are scoped to assets imgix isn’t already serving. Most operators pick one.

Migrating from imgix to mod_pagespeed

Migration is reasonable if your performance work has grown beyond images into CSS/JS/HTML, if you want self-hosted image optimization that keeps images on your own origin rather than egressing them to a service, or if a usage-based bill has become unpredictable and you’d prefer no bill at all.

mod_pagespeed is the better fit when the optimization layer needs to cover the whole page, stay inside infrastructure you control, and cost nothing to run rather than billing per byte delivered.

If you do migrate:

1. Rewrite image URLs from your imgix Source domain back to your own origin paths, so nginx serves and optimizes them in place.
2. Enable mod_pagespeed’s image filters to reproduce the transforms you relied on — format conversion and responsive variants. Per-request crops and effects encoded in imgix URL parameters should be moved into your application’s markup or a build step, since mod_pagespeed optimizes the assets the origin emits rather than synthesizing arbitrary transforms by URL.
3. Add the CSS, JS, and critical-CSS filters that imgix never provided. The server-side critical CSS in nginx post walks through that setup.
4. Decide how to handle edge delivery. mod_pagespeed optimizes at your origin; if you still want global distribution, put a general-purpose CDN in front of nginx — it caches the already-optimized responses.

Code & config side-by-side

Auto-formatting an image in imgix: rewrite the image URL to your imgix Source domain and add the transform parameters — for example https://your-source.imgix.net/photo.jpg?auto=format&w=800. imgix fetches the original from your storage, renders the variant, and serves it from its edge.

Equivalent 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 image filters (nginx config; applies to images on your own origin, with no URL rewriting and no third-party service in the path):

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

Both serve a modern image format negotiated for the browser. The difference is where it happens — imgix’s edge, or your own server — and that mod_pagespeed also minifies CSS/JS and extracts critical CSS in the same pass.