ModPageSpeed 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. ModPageSpeed 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, ModPageSpeed 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. ModPageSpeed 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 ModPageSpeed

• 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 predictable per-site pricing instead of usage-based billing that scales with traffic. A Business license is $948/year for the site, regardless of servers or request volume.
• You're optimizing existing HTML responses, not building a media-asset workflow from scratch. ModPageSpeed 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 — WebP across 1.15 and 2.0, AVIF from the 2.0 worker. Both can deliver different variants to different clients. Both reduce image bytes on the wire.

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 ModPageSpeed 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; ModPageSpeed 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 ModPageSpeed

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 ModPageSpeed 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. ModPageSpeed 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. ModPageSpeed 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 1.15 equivalent. 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 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 on the ModPageSpeed side is produced by the 2.0 worker when running the 2.0 pipeline.