Image CDN i optymalizacja obrazów produktów dla B2B

Problem skali katalogu

Klasyczny problem sklepu Magento ze 100 tys. produktów. 500 tys. oryginalnych obrazów (5 zdjęć per produkt galeria). Każdy obraz w 8 rozmiarach (thumbnail, small, medium, large, zoom, mobile, retina, kategoria). Łącznie 4 mln wariantów obrazów.

Co Magento robi lokalnie. Pierwsze żądanie obrazu w nowym rozmiarze - on-the-fly resize z oryginału przez GD albo ImageMagick. Wynik cache'owany w pub/media/catalog/product/cache/. Cache puchnie do 50-200 GB na serwerze produkcyjnym. Cache czyszczony okresowo (raz na miesiąc, raz na kwartał), generowanie zaczyna się od zera, klient w tym dniu widzi wolniejszy sklep.

Konsekwencje są wymierne. Wolny pierwszy load - first render PDP może czekać 200-500 ms na resize obrazów po stronie serwera, każdy z osobnym overheadem inicjalizacji ImageMagicka. Dysk się wypełnia - cache obrazów to typowo największy folder na serwerze produkcyjnym, czasem przekracza 60% dostępnej przestrzeni. Niepotrzebne computational load - CPU pracuje na image processingu zamiast obsługiwać requesty. CDN cache invalidation skomplikowane - URL zmienia się przy każdym nowym wariancie, edge cache się nie wykorzystuje.

Image CDN rozwiązuje wszystkie cztery problemy razem. Origin storage trzyma tylko oryginały (nawet 4-5 zdjęć per produkt to znacznie mniej miejsca niż 8 wariantów per obraz). CDN robi resize on-demand i cache'uje na edge globalnie. 100% obrazów serwowanych z CDN po pierwszym hicie. Origin server kompletnie uwalnia się od image processingu, CPU dostępny dla innych zadań.

LCP na stronie produktu - obrazy są typowo elementem LCP, więc image CDN bezpośrednio podnosi Core Web Vitals.

imgproxy, Cloudflare Images, ImageKit

Pięć realnych opcji dla sklepu B2B, każda z innym profilem ROI.

imgproxy to open-source demon w Go, ekstremalnie szybki (przetwarzanie obrazu w 5-20 ms). Konfiguracja przez parametry w URL: /resize:fill:800:600:1/quality:80/plain/s3://bucket/image.jpg. Self-hosted, zero kosztu API, płacisz tylko za maszynę (4 vCPU plus 8 GB RAM-u wystarcza dla średniego sklepu). Wspiera WebP, AVIF, JPEG XL. Brak wbudowanego CDN - dla edge cachingu łączysz z Cloudflare albo BunnyCDN przed imgproxy.

Cloudflare Images to managed service. Upload oryginałów do ich storage, transformacje via parametry w URL. Plus: globalna sieć edge (200+ POPs). Koszt 5 USD per 100 tys. zachowanych obrazów plus 1 USD per 100 tys. delivered. WebP i AVIF automatycznie dla wspieranych przeglądarek - zero pracy konfiguracyjnej.

ImageKit to SaaS popularny w polskich firmach z dobrym pricingiem dla średnich sklepów. Origin może być twój S3 albo własny serwer w trybie proxy. Transformacje via parametry URL. Plus smart cropping (face detection, content-aware). Cena 49-499 USD miesięcznie zależnie od bandwidth i liczby transformacji.

Thumbor to open-source w Pythonie, starszy, ale dojrzały. Smart cropping, self-hosted. Wolniejszy niż imgproxy, ale bardziej elastyczny w konfiguracji. Development mniej aktywny niż imgproxy w 2026 roku, więc dla nowych wdrożeń raczej nie polecam.

BunnyCDN Optimizer integruje się z BunnyCDN storage. Transformacje via query params. Cena 9.50 USD per TB transfer plus 0.005 USD per 1000 transformacji. Najtańsza opcja dla mniejszych sklepów - i polskie firmy często wybierają z uwagi na pricing.

Decyzja per profil sklepu:

Sklep	Rekomendacja
Poniżej 30 tys. SKU, mały budżet	BunnyCDN Optimizer
30-100 tys. SKU, średni budżet	ImageKit albo imgproxy plus Cloudflare
Powyżej 100 tys. SKU, własna infra	imgproxy self-hosted plus CDN
Cloud-native (AWS)	imgproxy na ECS plus CloudFront
Maksymalna prostota wdrożenia	Cloudflare Images

CDN dla katalogów - szersze ujęcie tematu CDN.

WebP i AVIF - kiedy implementować

Formaty next-gen redukują wagę obrazu znacznie:

Format	Waga dla 1000×1000 quality 80	Wsparcie browser
JPG	180 KB	100%
WebP	70 KB (-60%)	96%+
AVIF	45 KB (-75%)	92%+
JPEG XL	35 KB (-80%)	<5% (na razie)

Strategia implementacji:

Dla browsers wspierających - serwuj najlepszy.

<picture>
  <source srcset="produkt.avif" type="image/avif">
  <source srcset="produkt.webp" type="image/webp">
  <img src="produkt.jpg" alt="Produkt" width="1000" height="1000">
</picture>

Browser wybiera pierwsze obsługiwane.

Lub via CDN - automatic.

<img src="/cdn/produkt.jpg?auto=format" alt="Produkt">

CDN wykrywa Accept header browser i serwuje:

• Chrome 99+ → AVIF
• Safari 17+ → AVIF (czasem WebP)
• Firefox 113+ → AVIF
• Internet Explorer (legacy) → JPG

Czas wdrożenia:

• Bez CDN: 1-2 dni do dodania <picture> tag, generowanie wariantów wszystkich obrazów = tygodnie / miesiące
• Z CDN: zero, format wybierany przez CDN za darmo

Decyzja praktyczna. WebP wdrażam od razu - 96%+ wsparcie browser, oszczędność 60% bez ryzyka. AVIF wdrażam od razu, jeśli używam CDN z auto-format, manualnie nie warto, bo praca z tablicą wariantów per produkt zwala produktywność content teamu. JPEG XL na razie odczekuję - wsparcie poniżej 5%, brak ROI.

Pułapką są stare przeglądarki (IE11, Safari poniżej 14), które nie wspierają WebP ani AVIF. Fallback do JPG albo PNG jest obowiązkowy. Z CDN z auto-format CDN sam się tym zajmuje na podstawie nagłówka Accept z przeglądarki - nie musisz nic robić. Bez CDN trzeba ręcznie kodować <picture> z multiple <source>, co jest pracą, którą nikt nie chce powtarzać.

Responsive images, srcset, sizes

Klient na mobile nie potrzebuje 1600×1200 obrazu - zmarnowany bandwidth, wolniejszy LCP.

srcset i sizes - browser wybiera odpowiedni rozmiar:

<img 
  src="/cdn/produkt.jpg?w=800"
  srcset="
    /cdn/produkt.jpg?w=400 400w,
    /cdn/produkt.jpg?w=800 800w,
    /cdn/produkt.jpg?w=1200 1200w,
    /cdn/produkt.jpg?w=1600 1600w
  "
  sizes="
    (max-width: 600px) 400px,
    (max-width: 1200px) 800px,
    1200px
  "
  alt="Produkt"
  loading="lazy"
>

Logika:

• Mobile (<600px wide) → 400px obraz
• Tablet (<1200px) → 800px obraz
• Desktop (>1200px) → 1200px obraz
• Retina/4K - browser może wziąć 1600px wariant

Korzyść:

• Mobile - obraz 30-50KB zamiast 180KB
• LCP mobile - poprawa 30-50%
• Bandwidth bills - mniejsze

Z CDN:

Zamiast generować 4-5 wariantów per obraz w storage - CDN robi to on-demand.

<img 
  src="/cdn/produkt.jpg?w=800&auto=format"
  srcset="
    /cdn/produkt.jpg?w=400&auto=format 400w,
    /cdn/produkt.jpg?w=800&auto=format 800w,
    /cdn/produkt.jpg?w=1200&auto=format 1200w
  "
  sizes="..."
>

Format URL CDN dla typowych transformacji:

• imgproxy: /sig/rs:fill:800:600:1/q:80/plain/s3://bucket/image.jpg.webp
• Cloudflare Images: /cdn-cgi/image/width=800,quality=80,format=auto/original.jpg
• ImageKit: /tr:w-800,h-600,q-80,f-auto/original.jpg
• BunnyCDN: /original.jpg?w=800&format=webp

Lazy loading obrazów - razem z responsive jest must-have.

Origin storage - S3, Bunny, własny dysk

Origin = miejsce gdzie trzymasz oryginały. CDN to tylko proxy.

Opcje:

AWS S3:

• Standard - storage $0.023/GB/mc + transfer $0.09/GB
• Dla 100k obrazów × 2MB = 200GB = $5/mc storage
• Plus: transfer do CDN wewnątrz AWS = free
• Reliable, integracje wszędzie
• Default choice dla AWS cloud

Bunny Storage:

• $0.01/GB/mc storage + free transfer do Bunny CDN
• Polskie firmy często wybierają - tańsze niż S3
• 200GB = $2/mc
• Mniej mature niż S3, ale całkowicie funkcjonalne

Cloudflare R2:

• $0.015/GB/mc storage + free egress
• "S3-compatible" - same SDK
• 200GB = $3/mc
• Świetnie z Cloudflare ecosystem

Własny dysk (NAS, SAN):

• Free per GB ale koszt sprzętu + backup + management
• Sensowne dla bardzo dużych katalogów (>1TB)
• Lub gdy compliance wymaga on-premise

Decyzja:

• AWS-native sklep → S3
• Polskie firmy z budżetem → Bunny Storage
• Cloudflare-centric stack → R2
• Bardzo duża skala → własny dysk

Backup strategy:

• Origin storage z built-in versioning (S3 versioning, R2 versioning)
• Cross-region replication dla disaster recovery
• Periodic snapshot do oddzielnego storage (Glacier dla cheaper long-term)

Koszty - per request, per GB

Realna kalkulacja dla typowego sklepu B2B - 100k SKU, 500k page views miesięcznie, 5 obrazów per PDP.

Liczby:

• Origin storage: 200 GB
• Transformacje on-demand: 500k page views × 5 obrazów × 3 rozmiary = 7.5M transformacji/mc
• Bandwidth: średni obraz po optymalizacji 50KB × 7.5M = 375 GB/mc

Cloudflare Images:

• Storage: 100k oryginałów × $5/100k = $5/mc
• Delivered: 7.5M / 100k × $1 = $75/mc
• Total: ~$80/mc

imgproxy self-hosted + Cloudflare CDN:

• imgproxy server (4 vCPU, 8GB RAM): $40/mc
• S3 storage: $5/mc
• Cloudflare CDN (Pro plan): $20/mc
• Cloudflare transfer for cached content: free (Pro plan unlimited)
• Total: ~$65/mc

ImageKit:

• Plan Growth (do 100GB transfer): $99/mc
• Dla 375GB - Plan Premier: $499/mc

BunnyCDN Optimizer:

• Storage: $0.01/GB × 200GB = $2/mc
• Bandwidth: $9.5/TB × 0.375TB = $4/mc
• Optimizer: $0.005/1000 × 7.5M = $37.50/mc
• Total: ~$44/mc

Najekonomiczniej dla typowego sklepu B2B: BunnyCDN Optimizer lub imgproxy + Cloudflare.

Najprostsze setup: Cloudflare Images (zero-config, jeśli już używasz Cloudflare).

FAQ

Czy lokalna obróbka obrazów Magento jest do wyrzucenia? Tak, dla większości sklepów >10k SKU. Magento builds obrazów on-the-fly zajmuje przestrzeń, czas CPU, wolniej dostarczany. Image CDN przenosi to na infrastruktur zewnętrzną - wydajniej, taniej i szybciej. Magento custom modułem (np. Aimeos, Mageworx) integrujesz CDN URL'e do template'ów.

Co tańsze - Cloudflare Images czy imgproxy + Bunny? Cloudflare Images: ~$80/mc dla typowego sklepu. imgproxy + Bunny: ~$45/mc. Ale Cloudflare Images wymaga zerowej pracy, imgproxy wymaga 1-2 tygodni wdrożenia. Dla małego sklepu Cloudflare; dla większego - imgproxy ma lepsze TCO.

Jak migrować obrazy bez breakage URL-i? Cyfra Cloudflare Images / ImageKit ma "URL transformation rules" - utrzymują stare URL-e i robią transformacje w tle. Lub: 301 redirects ze starych URL na nowe. Lub: rewrite w Nginx/Cloudflare Workers - stare URL-e przekierowuje na CDN URL z dynamic transformacją.

Czy potrzebuję AVIF skoro mam WebP? Nie krytycznie, ale tak. AVIF jest 25-40% mniejszy niż WebP przy tej samej jakości. Dla mobile users (35-50% B2B traffic) - LCP improvement 100-300ms. Z CDN który robi auto-format - dostajesz za darmo bez extra pracy.

Czy lazy loading wystarcza zamiast image CDN? Nie. Lazy loading defers obrazy below the fold. Above the fold obrazy (LCP element, typowo główne PDP image, banner home page) musisz mieć szybkie - lazy loading tu nie pomoże. Image CDN optymalizuje wszystkie obrazy, lazy + CDN razem dają najlepsze rezultaty.

Co dalej

• Wydajność sklepu B2B: Wydajność e-commerce
• LCP strony produktu: LCP na stronie produktu
• Lazy loading: Lazy loading obrazów