Cloudinary for TYPO3

Images are the biggest performance killer on TYPO3 websites, and Cloudinary fixes that automatically

In 90% of the TYPO3 websites that score poorly on Core Web Vitals, images are the problem: too large, wrong format, no responsive variants, no CDN. TYPO3’s built-in image processing (GraphicsMagick/ImageMagick) does generate thumbnails, but it offers no format optimization (WebP/AVIF), no intelligent crop detection and no automatic delivery through a global CDN. Cloudinary as a TYPO3 FAL driver solves all three problems in one step.

Cloudinary stores the original images in its cloud, generates optimized variants on the fly and delivers them from 300+ edge locations worldwide. An image uploaded as a 4 MB JPEG reaches the visitor as a 120 KB AVIF, automatically, without the editor having to do anything.

Typical use cases

Media-heavy corporate websites. An automotive supplier with 3,000 product images, each in 5 variants (thumbnail, list image, detail image, zoom, download), has 15,000 files on its server without Cloudinary. With Cloudinary, only the 3,000 originals are stored, and Cloudinary generates the 15,000 variants on demand. Server storage drops by 80% and load times by 60%. For one client, Largest Contentful Paint (LCP) improved from 4.1 to 1.3 seconds.

International websites with a global audience. When visitors from Brazil, Japan and Germany open the same page, Cloudinary serves the images from the edge server closest to each of them. Without a CDN, loading a 500 KB image from a server in Frankfurt takes 2-3 seconds for a visitor in Tokyo. With Cloudinary, it takes under 200 milliseconds.

Editorial portals with high image volumes. News portals and magazines upload new images every day. Cloudinary takes load off the upload process: images are sent directly to Cloudinary (upload widget or API) and processed there, and only the reference path is stored in TYPO3. That reduces server load and speeds up the editorial workflow.

Technical architecture

Cloudinary is integrated into TYPO3 through a FAL driver (File Abstraction Layer driver). The extension registers itself as a storage driver and replaces the standard file operations: upload, download, delete, list. Editors keep working in the familiar TYPO3 backend, see images in the file list and insert them into content elements as usual.

URL generation is the core of the integration. Instead of a local file URL (/fileadmin/images/product.jpg), the driver generates a Cloudinary URL with transformation parameters: https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/product.jpg. The parameters f_auto (automatic format selection: the best format that the browser supports and that is enabled for the account, such as AVIF, WebP or JPEG XL, otherwise the format of the file extension) and q_auto (automatic quality adjustment) are the default.

Transformations are controlled via URL parameters: width (w_), height (h_), crop mode (c_fill, c_fit, c_thumb), focal point detection (g_auto detects faces and important image regions), overlays and watermarks. Each combination produces its own variant, which Cloudinary generates on the first request and caches afterwards.

Responsive breakpoint generation is particularly valuable: Cloudinary analyzes an image and calculates the optimal breakpoints based on the actual visual change between sizes. Instead of fixed breakpoints at 320, 768 and 1024 pixels, Cloudinary might deliver 347, 691 and 1024, because that is where the visual differences are greatest. This saves bandwidth without any visible loss of quality.

Common problems and solutions

Keeping costs under control at high traffic. Cloudinary bills in credits: transformations, storage and bandwidth all consume credits. The free plan covers roughly 25,000 transformations per month. A TYPO3 website with 500 pages and 3,000 images can exceed that in its first month, while the cache is still empty. The fix: trigger Cloudinary cache invalidation only when images actually change, not on every deploy. Set the fetch format to auto so that Cloudinary generates only the formats that are actually needed.

Image search in the TYPO3 backend is slow. The FAL driver has to query the Cloudinary API for every search. With 10,000+ images, that becomes noticeable. The fix: use the TYPO3 FAL index as the primary search source and synchronize with Cloudinary only when needed. The indexer should run as a nightly scheduler task, not on every backend request.

Existing image URLs change. After migrating from local storage to Cloudinary, every image URL changes. That affects SEO (Google Image Search), external links and cached pages. The fix: generate the Cloudinary URLs and, at the same time, set up 301 redirects from the old paths to the new URLs. TYPO3’s EXT:redirects can automate this.

Migration and version compatibility

The official TYPO3 Cloudinary extension on GitHub supports TYPO3 v11 and v12. Compatibility with v13 is in progress. The extension is maintained by the TYPO3 community, not by Cloudinary itself.

Migrating from local storage to Cloudinary takes four steps: first, create a Cloudinary account and configure the API key; second, upload the existing files in bulk (Cloudinary CLI or API); third, switch the TYPO3 file storage configuration to the Cloudinary driver; fourth, rebuild the FAL index. For 5,000 files, the whole process takes about one working day.

Cloudinary offers a free plan (25 credits per month) that is sufficient for small websites. For corporate websites with 10,000+ images and high traffic, the Plus plan costs around $89 per month. Gosign has delivered Cloudinary integrations for TYPO3 projects with up to 100,000 images and advises on cost optimization and transformation strategies.