18/05/2026
22 min czas czytania
Jeśli trafiłeś tu przez Google z pytaniem "jaki format zdjęć na stronę" lub "jakie rozszerzenie zdjęć do sklepu internetowego" - masz odpowiedź poniżej. Resztę artykułu możesz przeczytać żeby zrozumieć dlaczego.
Zdjęcia produktów i fotografie: WebP (jakość 82-85%) lub AVIF (jakość 75-80%) z fallbackiem JPEG.
Logotypy i ikony z przezroczystością: SVG jeśli wektorowe, WebP z kanałem alpha jeśli rastrowe.
Grafiki banery hero: WebP lub AVIF.
PNG: nigdzie. W żadnym z powyższych przypadków.
To tyle. Poniżej wyjaśnienie, liczby i kod.
Spis treści
Sprawdziłem top wyniki Google na frazy "jaki format zdjęć na stronę" i "jakie rozszerzenie zdjęć sklep". Obraz jest przygnębiający.
Artykuły z 2024 i 2025 roku wciąż rekomendują JPEG do większości zastosowań i PNG dla przezroczystości. Jeden z nich zaznacza, że WebP "nie jest powszechnie obsługiwany przez wszystkie przeglądarki" - ta informacja była przestarzała już w 2022 roku. Inny wciąż wymienia PNG jako "jeden z najlepszych formatów dla sklepów". Poradniki WooCommerce zalecają wgrywanie plików JPG lub PNG.
Nikt nie wspomina o AVIF. Nikt nie pokazuje kodu do blokowania PNG w CMS. Nikt nie omawia nginx ani Cloudflare Polish. Nikt nie mówi wprost: PNG nie ma miejsca na nowoczesnej stronie internetowej.
To nie jest kwestia gustu ani preferencji. To kwestia danych:
Jeśli szukasz nowoczesnej odpowiedzi na pytanie o format zdjęć w 2026 roku - czytaj dalej.
PNG, czyli Portable Network Graphics, to format obrazu rastrowego stworzony w 1995 roku. Powstał jako odpowiedź na problemy licencyjne formatu GIF, który w tamtym czasie należał do firmy Unisys. Świat potrzebował otwartego formatu obsługującego przezroczystość. PNG był odpowiedzią.
Specyfikacja PNG stała się oficjalnym standardem ISO w 2004 roku. Od tamtej pory format nie zmienił się w żadnym istotnym aspekcie technicznym. PNG w 2026 roku to dokładnie ten sam PNG co w 2004 roku. Przez 22 lata kompresja, architektura i możliwości formatu pozostały zamrożone w czasie.
Tymczasem internet zmienił się nie do poznania.
W połowie lat 90. PNG rozwiązywał realne problemy.
Lossless compression. PNG nie traci żadnych danych. Każdy piksel zapisany w pliku jest identyczny z pikselami na ekranie. Dla grafik, logotypów i zrzutów ekranu z tekstem to było coś, czego JPEG nie oferował.
Obsługa przezroczystości. Kanał alpha w PNG pozwalał na umieszczanie grafik na dowolnym tle bez białego prostokąta dookoła. GIF obsługiwał tylko binarną przezroczystość (piksel albo jest przezroczysty, albo nie). PNG dał programistom pełnię kontroli.
Otwarta specyfikacja bez opłat licencyjnych. W erze wojen przeglądarek i niepewności prawnej to miało ogromne znaczenie.
W 1996 roku PNG miał sens. W 2026 roku ma problem.
Trzy rzeczy zmieniły obraz sytuacji całkowicie.
Po pierwsze: prędkość łącza przestała być bottleneckiem. Stała się nim rozmiar pliku na urządzeniu mobilnym.
W 2010 roku większość ruchu internetowego generowały komputery stacjonarne na łączach szerokopasmowych. Dziś ponad 60% ruchu pochodzi z urządzeń mobilnych. Telefon komórkowy na sieci 4G z ograniczonym pakietem danych jest wrażliwy na rozmiar każdego zasobu. PNG z fotografią produktu ważący 800 KB to realny koszt dla użytkownika i realny problem dla konwersji.
Po drugie: Google zaczęło liczyć czas ładowania jako czynnik rankingowy.
Core Web Vitals, PageSpeed Insights, Largest Contentful Paint. Każda nieoptymalna grafika to punkty odjęte od widoczności w Google. PNG jest jednym z najłatwiejszych do wykrycia problemów w raporcie PageSpeed. Google wprost sugeruje zastąpienie PNG nowoczesnymi formatami.
Po trzecie: pojawiły się formaty, które robią wszystko co PNG, tylko lepiej.
WebP w 2010 roku. AVIF w 2019 roku. Oba formaty obsługują przezroczystość. Oba oferują kompresję bezstratną. Oba działają we wszystkich nowoczesnych przeglądarkach. I oba produkują pliki radykalnie mniejsze niż PNG przy identycznej lub wyższej jakości wizualnej.
PNG nie ma już żadnej technicznej przewagi nad nowoczesnymi formatami w kontekście stron internetowych i sklepów.
Liczby mówią same za siebie. Oto co wiemy na podstawie testów przeprowadzonych na reprezentatywnych próbach obrazów.
| Format | Redukcja rozmiaru vs PNG | Przezroczystość | Wsparcie przeglądarek |
|---|---|---|---|
| PNG | 0% (punkt odniesienia) | Tak | 100% |
| JPEG | -40 do -60% | Nie | 100% |
| WebP (lossy) | -50 do -70% | Tak | ~97% |
| WebP (lossless) | -26% | Tak | ~97% |
| AVIF (lossy) | -65 do -80% | Tak | ~94% |
| AVIF (lossless) | -40 do -50% | Tak | ~94% |
Bezstratna kompresja WebP produkuje pliki o 26% mniejsze niż PNG przy identycznych pikselach. To samo zdjęcie, zero utraty jakości, ponad jedna czwarta mniej danych do pobrania. AVIF w trybie lossless osiąga 40-50% redukcji względem PNG.
W trybie stratnym różnice są jeszcze bardziej dramatyczne. Zdjęcie produktu, które jako PNG waży 1,2 MB, jako WebP przy jakości 85% będzie ważyć 300-400 KB. To samo zdjęcie w AVIF przy podobnej jakości percepcyjnej - 200-250 KB.
Na stronie sklepu z 40 produktami różnica między PNG a WebP to różnica między 48 MB danych a 12 MB danych. Na sieci 4G z ograniczonym pakietem to różnica między stroną, która ładuje się 3 sekundy a stroną, która ładuje się 12 sekund.
Lossless WebP to 26% oszczędności rozmiaru względem PNG przy zerowej utracie jakości. AVIF osiąga do 50% oszczędności względem JPEG i wyraźnie wyprzedza WebP pod względem jakości przy tym samym rozmiarze pliku. Przy identycznej ocenie podobieństwa do oryginału plik AVIF wychodzi o 11,76% mniejszy niż WebP.
Strona serwująca 10 GB obrazów JPEG miesięcznie zredukowałaby to do 5 GB z AVIF lub 7 GB z WebP. To realna oszczędność kosztów CDN i realne przyspieszenie dla użytkownika.
Google mierzy wydajność stron trzema wskaźnikami w ramach Core Web Vitals:
LCP (Largest Contentful Paint) - czas, w którym załaduje się największy element wizualny na stronie (często jest nim zdjęcie produktu lub hero image).
INP (Interaction to Next Paint) - responsywność strony na interakcje użytkownika.
CLS (Cumulative Layout Shift) - stabilność układu strony.
PNG uderza najbardziej w LCP. Jeśli największy element strony to zdjęcie PNG o rozmiarze 900 KB, LCP będzie słaby. Przeglądarki muszą pobrać cały plik zanim mogą go wyrenderować. Większy plik = wolniejszy LCP = gorszy wynik Core Web Vitals = niższy ranking w Google.
PageSpeed Insights wprost wskazuje PNG jako problem i sugeruje zastąpienie go formatami nowej generacji. Audyt "Serve images in next-gen formats" to jeden z najczęściej pojawiających się zaleceń w raportach PageSpeed dla polskich stron i sklepów.
Pracowaliśmy ze sklepem oświetleniowym, który miał katalog 200 produktów. Każde zdjęcie produktu było wgrane jako PNG przez klienta. Średni rozmiar pliku: 780 KB. Całkowity rozmiar katalogu zdjęć: 156 MB.
Po konwersji do WebP przy jakości 85%: średni rozmiar pliku 195 KB. Całkowity rozmiar: 39 MB. Czas ładowania strony kategorii spadł o 2,1 sekundy. LCP poprawił się z 4,8s do 2,3s. Wynik PageSpeed wzrósł z 47 do 81.
Żadna zmiana w kodzie. Tylko format obrazów.
Przez kilkanaście lat pracy z klientami zidentyfikowałem kilka stałych wzorców. Klienci wgrywają PNG nie dlatego, że podjęli świadomą decyzję. Robią to z przyzwyczajenia lub z powodu narzędzi, których używają.
Domyślny format zrzutu ekranu na Windows to PNG. Na macOS też. Klient robi screenshot produktu, banner, screena z prezentacji, i wgrywa go bez żadnej konwersji. Wynik: PNG ze zrzutem ekranu w rozdzielczości Retina ważący 3-4 MB.
Nikt go nie poinformował, że to problem. Nikt nie zablokował uploadu.
Canva domyślnie eksportuje do PNG. PowerPoint domyślnie eksportuje slajdy jako PNG. Photoshop "Zapisz dla internetu" przez dekady miał PNG jako opcję. Figma eksportuje assety jako PNG jeśli developer nie przestawi ustawień.
Całe ekosystemy narzędzi, z których korzystają niedeceloperzy, wskazują na PNG jako domyślny wybór.
Część klientów świadomie wybiera PNG, bo "jest bez kompresji, więc lepsza jakość". To błędne rozumowanie. WebP w trybie lossless daje identyczną jakość piksel-do-piksela przy 26% mniejszym pliku. WebP lossy przy jakości 85-90% jest nieodróżnialny wizualnie od PNG na ekranie monitora, a waży 3-4 razy mniej.
Percepcja "PNG = lepsza jakość" to mit z lat 90., który przeżył swoje uzasadnienie o 15 lat.
W większości domyślnych instalacji WordPress, WooCommerce czy innych CMS-ów nie ma żadnego mechanizmu, który odrzuci PNG lub ostrzeże użytkownika. Każdy format wpada do media library. Kto nie wdroży reguły blokowania PNG, ten będzie miał PNG w nieskończoność.
Uczciwy artykuł musi przyznać: są przypadki, gdy PNG ma sens w 2026 roku. Jest ich jednak bardzo mało.
Logotypy z przezroczystością w bardzo specyficznych kontekstach. Jeśli wysyłasz logo do drukarni, partnerów lub do systemów, które nie obsługują WebP (starsze oprogramowanie, systemy ERP, niektóre narzędzia do e-mail marketingu) - PNG jest bezpieczniejszy. Dla strony internetowej: WebP z kanałem alpha robi to samo lepiej.
Obraz jako plik źródłowy do dalszej edycji. PNG jako format archiwizacji oryginałów przed konwersją. Zachowaj PNG na dysku lokalnym. Na stronę idzie WebP lub AVIF.
Grafiki eksportowane do środowisk bez kontroli nad formatem. Niektóre integracje zewnętrzne wymagają PNG lub JPEG. Systemy porównywania cen, feed Google Shopping w niektórych konfiguracjach, starsze API marketplace. Sprawdź wymagania integracji zanim zmienisz format.
Screenshoty do dokumentacji technicznej lub artykułów. Zrzuty ekranu z tekstem, kodem, interfejsami UI. PNG zachowuje ostrość krawędzi tekstu lepiej niż lossy WebP przy agresywnej kompresji. Przy jakości WebP 90+ różnica jest niewidoczna, ale przy niższej jakości tekst może być lekko rozmyty.
To wyczerpuje listę uzasadnionych przypadków użycia PNG na stronach internetowych i w sklepach. W każdym innym scenariuszu WebP lub AVIF jest lepszym wyborem.
WebP stworzył Google w 2010 roku. Przez pierwszą dekadę walczył o wsparcie w Safari, co blokowało jego powszechne użycie. Od iOS 14 i macOS 11 (Big Sur) Safari obsługuje WebP w pełni. Dziś wsparcie sięga 97% przeglądarek.
WebP obsługuje zarówno kompresję lossy jak i lossless. Obsługuje kanał alpha (przezroczystość). Obsługuje animacje, co czyni go bezpośrednim zamiennikiem GIF. Format bazuje na kodeku VP8 stworzonym przez Google dla wideo.
Dla zdjęć produktów w sklepach: WebP lossy przy jakości 80-85% to złoty standard. Mały plik, wysoka jakość percepcyjna, wsparcie w każdej nowoczesnej przeglądarce.
Konwersja do WebP jest prosta i darmowa:
convert input.png -quality 85 output.webpAVIF (AV1 Image File Format) to format oparty na kodeku wideo AV1, opublikowany przez Alliance for Open Media w 2019 roku. To ta sama organizacja, która stoi za VP9 i AV1 w kontekście wideo.
AVIF to aktualnie najbardziej efektywny format obrazu dostępny dla stron internetowych.
Kompresja AVIF jest lepiej zoptymalizowana dla treści fotograficznych. Przy tej samej jakości percepcyjnej AVIF produkuje pliki o 20-30% mniejsze niż WebP. W testach na dużych zbiorach obrazów przy identycznym wyniku podobieństwa do oryginału plik AVIF wychodzi średnio o 11,76% mniejszy niż WebP.
AVIF obsługuje HDR i szeroki gamut kolorów. To istotne dla fotografii produktowej wysokiej klasy, szczególnie lamp i oświetlenia, gdzie wierność odwzorowania kolorów przekłada się bezpośrednio na decyzje zakupowe.
AVIF lossless osiąga 40-50% redukcji rozmiaru względem PNG przy identycznych pikselach. WebP lossless daje 26%. Różnica jest wyraźna.
Kodowanie AVIF jest wolniejsze niż WebP. Dla dużych katalogów (tysiące produktów) batch konwersja do AVIF trwa dłużej. Na typowym sprzęcie kodowanie 1000 obrazów JPEG do AVIF zajmuje kilka razy więcej czasu niż do WebP. To nie jest problem dla gotowych katalogów - robisz raz, wynik trzyma się latami. Ale w systemach z dynamicznym generowaniem miniatur (on-the-fly resize) AVIF może wymagać mocniejszego serwera lub zewnętrznego serwisu CDN z transformacją obrazów.
AVIF działa w Chrome od wersji 85 (sierpień 2020), Firefox od wersji 93, Edge od 121, Safari od iOS 16 (wrzesień 2022). Wsparcie na poziomie ~94% przeglądarek. Dla bezpieczeństwa warto używać tagu <picture> z fallbackiem na WebP.
Nie musisz wybierać jednego formatu. W 2026 roku optymalny stack to AVIF z fallbackiem na WebP:
html
<picture> <source srcset="produkt.avif" type="image/avif"> <source srcset="produkt.webp" type="image/webp"> <img src="produkt.jpg" alt="Nazwa produktu" loading="lazy"> </picture>Przeglądarka sama wybierze najlepszy format jaki obsługuje. Chrome i Firefox pobiorą AVIF. Starszy iOS Safari pobierze WebP. Bardzo stara przeglądarka dostanie JPEG jako ostatni fallback.
Nowy projekt od zera: wdrożysz AVIF + WebP fallback. Jeden raz poprawnie, długoterminowo optymalnie.
Istniejący sklep z dużym katalogiem PNG: zacznij od konwersji do WebP. To prościej zautomatyzować, wyniki są natychmiastowe, nie ma ryzyk ze wsparciem przeglądarek. AVIF możesz dodać w kolejnym kroku.
Sklep WooCommerce z typowym katalogiem: ShortPixel lub Imagify obsługują automatyczną konwersję i serwowanie WebP/AVIF bez zmian w szablonie. Instalujesz wtyczkę, konfigurujesz jakość, uruchamiasz batch konwersję.
Serwery z CDN (Cloudflare): Cloudflare Polish z włączoną opcją WebP automatycznie konwertuje i serwuje obrazy w optymalnym formacie bez żadnych zmian w kodzie. Działa na poziomie sieci, oryginalny plik zostaje nienaruszony.
Sekcja <picture> w HTML jest rozwiązaniem frontendowym: wymaga zmiany szablonu lub kodu widoku. Istnieje elegantsze podejście, które działa transparentnie dla całego serwisu bez dotykania HTML. Chodzi o negocjację formatu na poziomie serwera, opartą na nagłówku HTTP Accept.
Przeglądarka przy każdym żądaniu obrazu wysyła nagłówek Accept: image/avif,image/webp,*/*. Serwer może go odczytać i zdecydować, który plik zwrócić, zanim cokolwiek dotrze do PHP czy aplikacji.
Najprostsza opcja dla każdego, kto ma Cloudflare przed serwerem. Wchodzisz w dashboard: Speed > Optimization > Polish, włączasz opcję Lossy lub Lossless, zaznaczasz WebP.
Cloudflare automatycznie serwuje WebP przeglądarkom które go obsługują. Oryginalne pliki na serwerze zostają niezmienione. Zero zmian w kodzie, zero zmian w HTML, zero konfiguracji serwera.
Ograniczenie: Cloudflare Polish obsługuje WebP, nie AVIF. Dla AVIF potrzebujesz rozwiązania poniżej lub zewnętrznego serwisu transformacji obrazów (Cloudflare Images, Imgix, Cloudinary).
Wymaga pre-wygenerowanych plików .webp i .avif obok oryginałów (np. przez batch konwersję przy deployu). nginx sam wybiera właściwy format na podstawie nagłówka Accept:
nginx
map $http_accept $img_suffix { default ""; "~*image/avif" ".avif"; "~*image/webp" ".webp"; } server { location ~* \.(jpe?g|png)$ { add_header Vary Accept; try_files $uri$img_suffix $uri =404; } }Jak to działa: przeglądarka żąda produkt.png. nginx sprawdza Accept. Jeśli przeglądarka obsługuje AVIF - serwuje produkt.png.avif. Jeśli tylko WebP - serwuje produkt.png.webp. Jeśli żaden - serwuje oryginał.
Vary: Accept jest kluczowy - informuje CDN i cache proxy, że odpowiedź różni się w zależności od nagłówka Accept. Bez tego CDN może zakeszować WebP i serwować go przeglądarce bez wsparcia WebP.
apache
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.avif [T=image/avif,L]
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,L]
Header append Vary Accept| Sytuacja | Rekomendacja |
|---|---|
| Shared hosting bez dostępu do nginx | Wtyczka WP (ShortPixel/Imagify) |
| VPS z nginx | nginx Vary: Accept + batch konwersja |
| Cloudflare jako CDN | Cloudflare Polish dla WebP |
| Potrzebujesz AVIF + WebP | nginx lub zewnętrzny serwis (Cloudinary, Imgix) |
| Laravel/Symfony custom | Konwersja w kontrolerze, serwowanie przez Storage |
Rozwiązanie infrastrukturalne ma jedną zasadniczą przewagę nad <picture> w HTML: działa dla całego serwisu od razu, bez edytowania setek szablonów. W projektach z dziesiątkami widoków i komponentów to oszczędność godzin pracy.
Najskuteczniejsze rozwiązanie to nie tłumaczenie klientom dlaczego PNG jest złe, tylko techniczne zablokowanie uploadu PNG i automatyczna konwersja.
Opcja 1: Wtyczka z automatyczną konwersją. ShortPixel Adaptive Images, Imagify lub EWWW Image Optimizer automatycznie konwertują każdy wgrany obraz do WebP lub AVIF. Klient wgrywa PNG, wtyczka konwertuje na serwer, serwuje WebP. Klient niczego nie wie, strona jest szybka.
Opcja 2: Blokada uploadu PNG na poziomie funkcji.
php
// functions.php add_filter('upload_mimes', function($mimes) { unset($mimes['png']); // usuwa PNG z dozwolonych typów return $mimes; });Po dodaniu tej funkcji WordPress odrzuci każdy plik PNG przy próbie uploadu. Użytkownik zobaczy komunikat o niedozwolonym typie pliku.
Opcja 3: Walidacja z komunikatem pomocowym.
php
add_filter('wp_handle_upload_prefilter', function($file) { if ($file['type'] === 'image/png') { $file['error'] = 'Format PNG nie jest dozwolony. Przekonwertuj zdjęcie do WebP przed uploadem. Użyj darmowego narzędzia: squoosh.app'; } return $file; });Zamiast suchego odrzucenia - zrozumiały komunikat z konkretnym rozwiązaniem.
W Sulu możesz ograniczyć dozwolone typy plików na poziomie konfiguracji media. W config/packages/sulu_media.yaml:
yaml
sulu_media: allowed_file_types: ['image/jpeg', 'image/webp', 'image/avif', 'image/svg+xml']Sulu 3 wspiera natywną konwersję obrazów przez Imagine. Z odpowiednią konfiguracją każdy wgrany obraz może być automatycznie przetwarzany do WebP przy generowaniu miniatur.
W aplikacjach Laravel walidacja przy uploadsie:
php
$request->validate([ 'image' => 'required|mimes:webp,avif,jpeg,jpg|max:5120', ]);Lub z automatyczną konwersją przy użyciu pakietu Intervention Image:
php
use Intervention\Image\ImageManager; use Intervention\Image\Drivers\Gd\Driver; $manager = new ImageManager(new Driver()); $image = $manager->read($request->file('image')); $image->toWebp(quality: 85)->save(storage_path('app/public/products/' . $filename . '.webp'));Klient wgrywa JPEG lub PNG, system konwertuje do WebP, zapisuje WebP, wyświetla WebP. Zero konfiguracji po stronie klienta.
W panelu Filament z FileUpload:
php
FileUpload::make('image') ->image() ->acceptedFileTypes(['image/webp', 'image/avif', 'image/jpeg']) ->helperText('Akceptowane formaty: WebP, AVIF, JPEG. Konwersja z PNG: squoosh.app')Masz katalog 500 zdjęć PNG. Co zrobić?
bash
npm install -g @squoosh/cli
# Konwersja katalogu PNG do WebP jakość 85 squoosh-cli --webp '{"quality":85}' *.png
# Konwersja do AVIF jakość 80 squoosh-cli --avif '{"quality":80}' *.pngProste, darmowe, działa lokalnie bez wysyłania danych na zewnętrzne serwery.
bash
# Instalacja na macOS brew install webp
# Konwersja pojedynczego pliku cwebp -q 85 foto.png -o foto.webp
# Batch konwersja wszystkich PNG w katalogu for file in *.png; do cwebp -q 85 "$file" -o "${file%.png}.webp" done
bash
# Konwersja do WebP convert foto.png -quality 85 foto.webp
# Konwersja do AVIF convert foto.png -quality 75 foto.avif
# Batch z resize do 2000px szerokości mogrify -format webp -resize 2000x2000\> -quality 85 *.pngDla klientów, którzy sami zarządzają contentem, polecam:
Dobre ćwiczenie: dodaj link do squoosh.app w komunikacie o błędzie przy próbie wgrania PNG. Klient zobaczy jasny przekaz: "tutaj możesz szybko to naprawić".
Przejdź punkt po punkcie. Każde "nie" to zadanie do wykonania.
Analiza obecnego stanu:
Konfiguracja serwera i CMS:
Content-Type: image/webp dla plików WebP?<picture> z odpowiednimi fallbackami dla krytycznych obrazów?Workflow klientów i redaktorów:
Monitoring:
Czy WebP jest bezpieczny dla SEO?
Tak. Google indeksuje obrazy WebP bez żadnych problemów. Obraz w WebP może pojawić się w Google Images. Format pliku nie wpływa negatywnie na indeksowanie. Wpływa natomiast pozytywnie, przez przyspieszenie strony i poprawę Core Web Vitals.
Co z klientami na starych przeglądarkach?
Użycie tagu <picture> z fallbackiem na JPEG rozwiązuje problem. WebP obsługuje 97% przeglądarek. AVIF obsługuje 94%. Dla tych 3-6% starszych przeglądarek automatycznie serwujesz JPEG jako fallback. Użytkownik nie widzi różnicy.
Czy WordPress automatycznie konwertuje do WebP?
WordPress od wersji 5.8 potrafi generować wersje WebP dla wgranych obrazów, ale funkcja nie jest domyślnie włączona i zależy od konfiguracji serwera (dostępność biblioteki GD lub Imagick). W praktyce dla produkcyjnych sklepów używaj dedykowanej wtyczki do optymalizacji obrazów (ShortPixel, Imagify, EWWW).
Co zrobić ze starymi PNG, które już są w serwisie?
Batch konwersja przez wtyczkę (ShortPixel ma opcję "bulk optimize" dla całej media library) lub przez CLI lokalnie. Nie usuwaj oryginałów PNG od razu. Zrób konwersję, sprawdź przez kilka dni czy wszystko wygląda poprawnie, potem możesz posprzątać.
Czy AVIF działa w e-mail marketingu?
Nie. Klienty poczty e-mail (Outlook, Apple Mail, Gmail) mają bardzo ograniczone wsparcie dla nowoczesnych formatów. W e-mailach używaj JPEG lub PNG. Nowoczesne formaty są przeznaczone dla stron internetowych i aplikacji webowych.
Czy mogę wgrać SVG zamiast PNG dla logotypów?
Tak, i to jest jeszcze lepsza opcja dla logotypów i ikon. SVG to format wektorowy - plik jest mały, jakość jest perfekcyjna w każdej rozdzielczości, skaluje się bez utraty ostrości. Dla logotypu, ikon nawigacji i prostych grafik wektorowych SVG jest lepszy niż PNG i lepszy niż WebP. Pamiętaj tylko o sanityzacji SVG przed wgraniem (ochrona przed XSS przez złośliwy kod w pliku SVG).
Klient upiera się przy PNG. Co robić?
Dwa podejścia. Pierwsze: wdrożyć automatyczną konwersję po stronie serwera - klient wgrywa co chce, serwer serwuje WebP, problem niewidoczny. Drugie: wytłumaczyć na liczbach. "Twoje zdjęcia PNG ważą 800 KB. WebP waży 200 KB. Twoja strona ładuje się 3x wolniej niż konkurencja. Google obniżył jej pozycję. Chcesz to naprawić?"
PNG powstał w 1995 roku. Internet w 2026 roku to inne miejsce niż w 1995 roku.
Przez ostatnie 15 lat branża wypracowała dwa formaty, które robią wszystko co PNG, tylko lepiej: WebP i AVIF. Oba obsługują przezroczystość. Oba mają tryb bezstratny. Oba działają we wszystkich nowoczesnych przeglądarkach. I oba produkują pliki radykalnie mniejsze, co bezpośrednio przekłada się na szybkość strony, Core Web Vitals i pozycje w Google.
Klienci wgrywają PNG nie ze złej woli. Robią to bo tak domyślnie działają ich narzędzia. To po stronie CMS-u i systemu trzeba ustawić odpowiednie reguły: blokadę uploadu PNG lub automatyczną konwersję. Klient powinien nie wiedzieć, że taki problem istnieje, bo infrastruktura powinna go rozwiązywać zanim dotrze do strony.
W MITS każdy nowy projekt wdrażamy już z domyślną obsługą WebP. W sklepach WooCommerce konfigurujemy automatyczną konwersję na poziomie wtyczki lub serwera. W projektach na Laravel i Sulu konwersja jest wbudowana w logikę uploadu. Dla istniejących klientów przeprowadzamy audyt mediów i batch konwersję, która zazwyczaj daje natychmiastowy wzrost PageSpeed o 20-40 punktów.
Jeśli Twoja strona lub sklep ma dziesiątki albo setki PNG w bibliotece mediów, masz do odebrania konkretne punkty PageSpeed i konkretne sekundy czasu ładowania. A to przekłada się na konwersje.
Masz pytania?