Cloudinary dla TYPO3

Obrazy to największy zabójca wydajności na stronach TYPO3, a Cloudinary rozwiązuje to automatycznie

W 90% witryn TYPO3, które osiągają słabe wyniki Core Web Vitals, problemem są obrazy. Za duże, zły format, brak wariantów responsywnych, brak CDN. Wewnętrzne przetwarzanie obrazów TYPO3 (GraphicsMagick/ImageMagick) tworzy wprawdzie miniatury, ale nie optymalizuje formatów (WebP/AVIF), nie rozpoznaje inteligentnie kadrowania i nie dostarcza automatycznie przez globalne CDN. Cloudinary jako sterownik TYPO3 FAL rozwiązuje wszystkie trzy problemy w jednym kroku.

Cloudinary przechowuje oryginalne obrazy w swojej chmurze, generuje zoptymalizowane warianty on-the-fly i dostarcza je przez ponad 300 lokalizacji Edge na całym świecie. Obraz przesłany jako 4 MB JPEG dociera do odwiedzającego jako 120 KB AVIF - automatycznie, bez konieczności działania ze strony redaktora.

Typowe scenariusze zastosowania

Korporacyjne strony z dużą ilością mediów. Dostawca motoryzacyjny z 3000 zdjęć produktów, każde w 5 wariantach (miniatura, obraz listy, obraz szczegółowy, zoom, pobieranie), ma bez Cloudinary 15 000 plików na serwerze. Z Cloudinary przechowywanych jest 3000 oryginałów, 15 000 wariantów Cloudinary generuje na żądanie. Przestrzeń na serwerze spada o 80%, czasy ładowania o 60%. Largest Contentful Paint (LCP) u jednego klienta poprawił się z 4,1 do 1,3 sekundy.

Międzynarodowe strony z globalną publicznością. Gdy odwiedzający z Brazylii, Japonii i Niemiec wywołują tę samą stronę, Cloudinary dostarcza obrazy z najbliższego serwera Edge. Bez CDN ładowanie obrazu 500 KB z serwera we Frankfurcie dla odwiedzającego w Tokio trwa 2-3 sekundy. Z Cloudinary poniżej 200 milisekund.

Portale redakcyjne z dużym wolumenem obrazów. Portale informacyjne i magazyny codziennie przesyłają nowe obrazy. Cloudinary odciąża proces przesyłania: obrazy są wysyłane bezpośrednio do Cloudinary (Upload Widget lub API), przetwarzane, a w TYPO3 zapisywana jest tylko ścieżka referencyjna. Oszczędza to obciążenie serwera i przyspiesza przepływ pracy redakcyjnej.

Architektura techniczna

Integracja Cloudinary z TYPO3 odbywa się przez sterownik FAL (File Abstraction Layer Driver). Rozszerzenie rejestruje się jako sterownik Storage i nadpisuje standardowe operacje plikowe: przesyłanie, pobieranie, usuwanie, listowanie. Redaktorzy pracują w znanym backendzie TYPO3, widzą obrazy w Filelist i dodają je jak zwykle do elementów treści.

Generowanie URL to rdzeń integracji. Zamiast lokalnego URL pliku (/fileadmin/images/produkt.jpg) sterownik generuje URL Cloudinary z parametrami transformacji: https://res.cloudinary.com/[cloud-name]/image/upload/f_auto,q_auto,w_800/produkt.jpg. Parametry f_auto (automatyczne rozpoznawanie formatu: WebP dla Chrome, AVIF dla Firefox, JPEG dla starszych przeglądarek) i q_auto (automatyczne dostosowanie jakości) są standardem.

Transformacje są sterowane przez parametry URL: szerokość (w_), wysokość (h_), tryb kadrowania (c_fill, c_fit, c_thumb), rozpoznawanie punktu fokusowego (g_auto rozpoznaje twarze i ważne obszary obrazu), overlay i znaki wodne. Każda kombinacja generuje osobny wariant, który Cloudinary tworzy przy pierwszym wywołaniu i następnie cachuje.

Generowanie responsywnych breakpointów jest szczególnie wartościowe: Cloudinary analizuje obraz i oblicza optymalne breakpointy na podstawie faktycznej zmiany wizualnej między rozmiarami. Zamiast stałych breakpointów przy 320, 768 i 1024 pikselach Cloudinary dostarcza np. 347, 691, 1024 - bo tam leżą największe różnice wizualne. Oszczędza to przepustowość bez widocznej utraty jakości.

Częste problemy i rozwiązania

Kontrola kosztów przy dużym ruchu. Cloudinary rozlicza się w kredytach: transformacje, przechowywanie i przepustowość zużywają kredyty. Darmowy plan wystarcza na około 25 000 transformacji miesięcznie. Witryna TYPO3 z 500 stronami i 3000 obrazami może to przekroczyć w pierwszym miesiącu, gdy cache jest pusty. Rozwiązanie: inwalidacja cache Cloudinary tylko przy rzeczywistych zmianach obrazów, nie przy każdym deployu. Ustawienie formatu pobierania na auto, aby Cloudinary generowało tylko potrzebne formaty.

Wyszukiwanie obrazów w backendzie TYPO3 jest wolne. Sterownik FAL musi przy każdym wyszukiwaniu odpytywać API Cloudinary. Przy 10 000+ obrazach to jest odczuwalne. Rozwiązanie: indeks FAL TYPO3 jako główne źródło wyszukiwania i synchronizacja z Cloudinary tylko w razie potrzeby. Scheduler indeksera powinien działać w nocy, nie przy każdym dostępie do backendu.

Istniejące adresy URL obrazów się zmieniają. Po migracji z lokalnego przechowywania na Cloudinary zmieniają się wszystkie adresy URL obrazów. Dotyczy to SEO (Google Image Search), linkowania zewnętrznego i stron w cache. Rozwiązanie: generowanie adresów URL Cloudinary i jednoczesne ustawienie przekierowań 301 ze starych ścieżek na nowe adresy URL. EXT:redirects TYPO3 może to zautomatyzować.

Migracja i kompatybilność wersji

Oficjalne rozszerzenie TYPO3-Cloudinary na GitHubie obsługuje TYPO3 v11 i v12. Dla v13 trwają prace nad kompatybilnością. Rozszerzenie jest utrzymywane przez społeczność TYPO3, nie przez Cloudinary.

Migracja z lokalnego przechowywania na Cloudinary odbywa się w czterech krokach: po pierwsze utworzenie konta Cloudinary i konfiguracja klucza API, po drugie przesłanie istniejących plików przez Bulk-Upload (Cloudinary CLI lub API), po trzecie przełączenie konfiguracji File Storage TYPO3 na sterownik Cloudinary i po czwarte odbudowa indeksu FAL. Przy 5000 plików cały proces trwa około jednego dnia roboczego.

Cloudinary oferuje darmowy plan (25 kredytów/miesiąc), który wystarcza dla małych stron. Dla witryn korporacyjnych z 10 000+ obrazami i dużym ruchem plan Plus kosztuje około 89 USD/miesiąc. Gosign wdrożył integracje Cloudinary dla projektów TYPO3 z maksymalnie 100 000 obrazami i doradza w kwestii optymalizacji kosztów i strategii transformacji.