Cloudinary für TYPO3

Bilder sind der größte Performance-Killer auf TYPO3-Websites, und Cloudinary löst das automatisch

Bei 90% der TYPO3-Websites, die schlecht bei Core Web Vitals abschneiden, sind Bilder das Problem. Zu groß, falsches Format, keine responsiven Varianten, kein CDN. TYPO3s internes Image Processing (GraphicsMagick/ImageMagick) erzeugt zwar Thumbnails, aber keine Format-Optimierung (WebP/AVIF), keine intelligente Crop-Erkennung und keine automatische Auslieferung über ein weltweites CDN. Cloudinary als TYPO3 FAL-Treiber löst alle drei Probleme in einem Schritt.

Cloudinary speichert die Originalbilder in seiner Cloud, erzeugt on-the-fly optimierte Varianten und liefert sie über 300+ Edge-Locations weltweit aus. Ein Bild, das als 4 MB JPEG hochgeladen wurde, kommt beim Besucher als 120 KB AVIF an, automatisch, ohne dass der Redakteur etwas tun muss.

Typische Einsatzszenarien

Medienintensive Unternehmenswebsites. Ein Automobilzulieferer mit 3.000 Produktbildern, davon jedes in 5 Varianten (Thumbnail, Listenbild, Detailbild, Zoom, Download), hat ohne Cloudinary 15.000 Dateien auf dem Server. Mit Cloudinary werden 3.000 Originale gespeichert, die 15.000 Varianten erzeugt Cloudinary bei Bedarf. Der Server-Speicher sinkt um 80%, die Ladezeiten um 60%. Der Largest Contentful Paint (LCP) verbesserte sich bei einem Kunden von 4,1 auf 1,3 Sekunden.

Internationale Websites mit globalem Publikum. Wenn Besucher aus Brasilien, Japan und Deutschland dieselbe Seite aufrufen, liefert Cloudinary die Bilder jeweils vom nächstgelegenen Edge-Server. Ohne CDN dauert das Laden eines 500 KB Bildes von einem Server in Frankfurt für einen Besucher in Tokio 2-3 Sekunden. Mit Cloudinary unter 200 Millisekunden.

Redaktionelle Portale mit hohem Bildvolumen. News-Portale und Magazine laden täglich neue Bilder hoch. Cloudinary entlastet den Upload-Prozess: Bilder werden direkt an Cloudinary gesendet (Upload Widget oder API), verarbeitet und erst der Referenzpfad in TYPO3 gespeichert. Das spart Server-Last und beschleunigt den Redaktions-Workflow.

Technische Architektur

Die Cloudinary-Integration in TYPO3 erfolgt über einen FAL-Treiber (File Abstraction Layer Driver). Die Extension registriert sich als Storage-Treiber und überschreibt die Standard-Dateioperationen: Upload, Download, Löschen, Auflisten. Redakteure arbeiten im gewohnten TYPO3-Backend, sehen Bilder in der Filelist und fügen sie wie gewohnt in Content-Elemente ein.

Die URL-Generierung ist der Kern der Integration. Statt einer lokalen Datei-URL (/fileadmin/images/produkt.jpg) generiert der Treiber eine Cloudinary-URL mit Transformations-Parametern: https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produkt.jpg. Die Parameter f_auto (automatische Formaterkennung: WebP für Chrome, AVIF für Firefox, JPEG für alte Browser) und q_auto (automatische Qualitätsanpassung) sind der Standard.

Transformationen werden über URL-Parameter gesteuert: Breite (w_), Höhe (h_), Crop-Modus (c_fill, c_fit, c_thumb), Fokuspunkt-Erkennung (g_auto erkennt Gesichter und wichtige Bildbereiche), Overlay und Wasserzeichen. Jede Kombination erzeugt eine eigene Variante, die Cloudinary beim ersten Aufruf generiert und anschließend cachet.

Die responsive Breakpoint-Generierung ist besonders wertvoll: Cloudinary analysiert ein Bild und berechnet die optimalen Breakpoints basierend auf der tatsächlichen visuellen Änderung zwischen den Größen. Statt fester Breakpoints bei 320, 768 und 1024 Pixeln liefert Cloudinary beispielsweise 347, 691, 1024, weil dort die visuell größten Unterschiede liegen. Das spart Bandbreite ohne sichtbaren Qualitätsverlust.

Häufige Probleme und Lösungen

Kosten-Kontrolle bei hohem Traffic. Cloudinary rechnet nach Credits ab: Transformationen, Speicher und Bandbreite verbrauchen Credits. Der kostenlose Plan reicht für circa 25.000 Transformationen pro Monat. Eine TYPO3-Website mit 500 Seiten und 3.000 Bildern kann das im ersten Monat überschreiten, wenn der Cache leer ist. Lösung: Cloudinary-Cache-Invalidierung nur bei tatsächlichen Bildänderungen auslösen, nicht bei jedem Deploy. Den Fetch-Format auf auto stellen, damit Cloudinary nur die nötigen Formate generiert.

Bildersuche im TYPO3-Backend ist langsam. Der FAL-Treiber muss bei jeder Suche die Cloudinary-API abfragen. Bei 10.000+ Bildern dauert das spürbar. Lösung: Den TYPO3 FAL-Index als primäre Suchquelle nutzen und nur bei Bedarf gegen Cloudinary synchronisieren. Der Indexer-Scheduler sollte nachts laufen, nicht bei jedem Backend-Zugriff.

Bestehende Bild-URLs ändern sich. Nach der Migration von lokalem Speicher auf Cloudinary ändern sich alle Bild-URLs. Das betrifft SEO (Google Image Search), externe Verlinkungen und gecachte Seiten. Lösung: Cloudinary-URLs generieren und gleichzeitig 301-Redirects von den alten Pfaden auf die neuen URLs einrichten. TYPO3s EXT:redirects kann das automatisiert.

Migration und Versions-Kompatibilität

Die offizielle TYPO3-Cloudinary-Extension auf GitHub unterstützt TYPO3 v11 und v12. Für v13 ist Kompatibilität in Arbeit. Die Extension wird von der TYPO3-Community gepflegt, nicht von Cloudinary selbst.

Die Migration von lokalem Speicher auf Cloudinary erfolgt in vier Schritten: erstens einen Cloudinary-Account anlegen und den API-Key konfigurieren, zweitens die bestehenden Dateien per Bulk-Upload (Cloudinary CLI oder API) hochladen, drittens die TYPO3 File Storage Konfiguration auf den Cloudinary-Treiber umstellen und viertens den FAL-Index neu aufbauen. Bei 5.000 Dateien dauert der gesamte Prozess circa einen Arbeitstag.

Cloudinary bietet einen kostenlosen Plan (25 Credits/Monat), der für kleine Websites ausreicht. Für Unternehmenswebsites mit 10.000+ Bildern und hohem Traffic liegt der Plus-Plan bei circa 89 USD/Monat. Gosign hat Cloudinary-Integrationen für TYPO3-Projekte mit bis zu 100.000 Bildern umgesetzt und berät zu Kosten-Optimierung und Transformations-Strategien.