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 elsewhere.
• You need CSS, JS, and HTML optimization in addition to images. Cloudinary doesn't do those.
• You want predictable per-server pricing instead of usage-based billing that scales with traffic.
• 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 in modern formats (WebP, AVIF). 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.

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.1 equivalent (nginx config; the filter 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.