mod_pagespeed vs Cloudinary

TL;DR

Cloudinary is a managed media platform — images and video are uploaded to Cloudinary, transformed via URL-driven APIs, and delivered through its CDN. mod_pagespeed is a self-hosted optimization layer that includes images but also handles CSS, JS, and HTML. If image and video transformations are the bottleneck and you don't want to run that infrastructure, Cloudinary is the obvious fit. If you want optimization to stay on your origin and cover more than just media, mod_pagespeed is the alternative.

At a glance

When to choose Cloudinary

• Media is the bottleneck. If you have a large library of images and video and the operational problem is transcoding, streaming, and worldwide delivery, that's the case Cloudinary is built for.
• You want video transcoding and adaptive-bitrate streaming. mod_pagespeed doesn't handle video at all.
• You want a digital asset management UI for non-engineers to upload, tag, and find media.
• You don't want to run image processing infrastructure and you're comfortable with usage-based pricing.
• Your stack is heterogeneous and you want a vendor-managed API that works from any language.

When to choose mod_pagespeed

• You want optimization to stay on your origin. Cloudinary's value is its cloud — if you don't want your media there, that's a reason to look at self-hosted image optimization instead.
• You need CSS, JS, and HTML optimization in addition to images. Cloudinary doesn't do those.
• You want no per-request or per-GB bill at all instead of usage-based billing that scales with traffic. mod_pagespeed 2.1 is free under the Apache License 2.0, regardless of servers or request volume; see pricing for optional support plans.
• You're optimizing existing HTML responses, not building a media-asset workflow from scratch. mod_pagespeed rewrites image URLs in the page; Cloudinary expects the page to reference Cloudinary URLs.
• You don't process video, or you handle video separately (e.g., a video platform like Mux or Bunny Stream).

How they overlap

Both produce optimized images and serve different variants to different clients, cutting image bytes on the wire; on the mod_pagespeed side that is WebP and AVIF.

The overlap is image format conversion and responsive sizing. For CSS, JS, HTML, video, and asset management, the products are in different categories.

One axis a remote media CDN doesn’t touch is the HTML document itself. Because mod_pagespeed runs at your origin, origin-side HTML rewriting and lighter markup improve what crawlers and AI agents actually see — the page they parse, not just the media embedded in it. Cloudinary serves transformed assets, but the surrounding markup never passes through it. See AI readability for where that line of work is headed.

You can also use them together: Cloudinary for user-uploaded media and video; mod_pagespeed for the rest of the page (critical CSS, JS minification, optimization of any non-Cloudinary images). That composition is common when video is in scope.

Migrating from Cloudinary to mod_pagespeed

Migration is reasonable if your image use is straightforward (resize, reformat, lazy load) and the Cloudinary bill is growing faster than the value. It's not reasonable if you depend on video transcoding, the DAM, or Cloudinary-specific features like AI tagging.

Partial migration is more common than full migration: keep Cloudinary for video and user uploads; let mod_pagespeed handle the HTML-referenced static images on the origin.

If you do migrate (or partially migrate):

1. Audit your templates for hard-coded Cloudinary URLs. mod_pagespeed rewrites origin image URLs at HTML-rewrite time — many template patterns can be simplified.
2. Identify which image assets are genuinely Cloudinary-managed (uploads, transforms) versus statically hosted but routed through Cloudinary for optimization. The latter can move to the origin. The Docker Compose walkthrough sets up a working origin-side baseline.
3. Decide where video lives. mod_pagespeed does not process video; if Cloudinary was your video pipeline, keep it or move to a dedicated video service.

Code & config side-by-side

Cloudinary image delivery (URL-based, format auto-selected by f_auto):

https://res.cloudinary.com/<cloud>/image/upload/f_auto,q_auto,w_800/photo.jpg

mod_pagespeed 2.1 equivalent. 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 rewrites origin image references and serves the best format per request):

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

Both arrive at "the browser gets WebP when it supports it." The difference is the asset's home address: Cloudinary's CDN versus your origin (optionally with a generic CDN in front). AVIF output is available on the mod_pagespeed side too.