Najczęstszy marketingowy slogan narzędzi do kompresji to „redukcja rozmiaru o 70%” – liczby, których nie da się zweryfikować. W tym artykule nie powołujemy się na żadne branżowe statystyki, przedstawiamy tylko wyniki realnego testu i pełną metodologię porównawczą, którą każdy może samodzielnie odtworzyć.
1. Obiekt testu: nie oryginalne obrazy, ale zdjęcia, które „ktoś już wcześniej skompresował”
Większość testów kompresji wykorzystuje oryginalne zdjęcia prosto z aparatu, co jest warunkiem zbyt idealnym. Ten test celowo odwzorowuje rzeczywisty scenariusz biznesowy: serwis, który pozwala użytkownikom przesyłać zdjęcia, już podczas zapisu wykonuje standardową kompresję – innymi słowy, materiałem testowym nie są nieprzetworzone oryginały, lecz gotowe obrazy, które „przeszły już jedną kompresję”.
Wielkość próbki: 78 folderów, łącznie 4624 obrazy (głównie JPG), struktura katalogów typowa dla archiwizacji „jeden album w jednym folderze”, bez żadnego filtrowania ani czyszczenia.
Całkowity rozmiar tych plików na serwerze w momencie rozpoczęcia testu: 1,41 GB.
Kluczowe pytanie: czy obraz, który został już skompresowany przez jedno narzędzie, może zyskać dodatkowe oszczędności po ponownym użyciu innego narzędzia? Większość użytkowników intuicyjnie zakłada, że „raz skompresowane, drugi raz nie ma sensu”.
2. Grupa kontrolna: ile można zaoszczędzić, pakując do zip?
Przed uruchomieniem ImgZilla ta sama partia plików została spakowana do zip bez żadnych zmian, aby sprawdzić efekt uniwersalnych algorytmów kompresji:
| Rozmiar | W porównaniu z oryginałem | |
|---|---|---|
| Oryginalne pliki po kompresji serwisu | 1,41 GB | — |
| Spakowane do formatu zip | 1,41 GB | -0,2% |
Prawie żadnych zmian. Powód jest prosty: JPEG jest sam w sobie formatem skompresowanym, dane obrazu są już poddane kodowaniu entropijnemu, więc algorytmy ogólnego przeznaczenia (zip używa DEFLATE) nie są w stanie skompresować już skompresowanych danych – niezależnie od tego, czy obraz był wcześniej przetwarzany przez serwis, zip nic tutaj nie zdziała.
3. Test ponownej kompresji narzędziem ImgZilla
Wskazane pliki przeciągnięto do ImgZilla i skompresowano w miejscu. 78 folderów i 4624 obrazy – nazwy plików i struktura katalogów zostały zachowane w całości:
| Rozmiar | W porównaniu z oryginałem | |
|---|---|---|
| Oryginalne pliki po kompresji serwisu | 1,41 GB | — |
| Spakowane do formatu zip | 1,41 GB | -0,2% |
| Po ponownej kompresji przez ImgZilla | 0,75 GB | -46,8% |
Na bazie kompresji wykonanej już przez serwis, ImgZilla zaoszczędził dodatkowo ok. 662 MB, zmniejszając rozmiar niemal o połowę. Wszystkie ścieżki folderów, nazwy plików i hierarchia pozostały w pełni identyczne – to rzeczywiste dane, które można bezpośrednio zweryfikować, a nie marketingowa retoryka.
To ujawnia kluczowy fakt: „kompresja przy przesyłaniu na stronę” to nie to samo co „staranna kompresja z wykorzystaniem parametrów specyficznych dla formatu”. Większość serwisów podczas zapisu wykonuje jednorazową, dość zachowawczą kompresję (zwykle ogranicza się do parametrów jakości lub rozmiaru), która nie wykorzystuje w pełni możliwości kodowania danego formatu. ImgZilla indywidualnie dostraja parametry dla każdego formatu, wykonując na plikach JPEG wizualnie bezstratną rekompresję – na poziomie pikseli zmiany rzeczywiście występują, ale parametry są ustawione tak, że różnice są praktycznie niewidoczne dla oka, dzięki czemu udaje się wycisnąć dodatkowe miejsce z już „skompresowanych” plików.
Należy wyjaśnić mylące pojęcie: „wizualna bezstratność” nie oznacza „bezstratności”. Prawdziwa bezstratność (piksele pozostają w 100% niezmienione) dotyczy tylko formatów PNG (oxipng) i SVG; JPEG, WebP, AVIF, HEIC i GIF są z zasady rekompresją stratną, a jedynie parametry kompresji są utrzymywane w zakresie wizualnej bezstratności. ImgZilla ma wbudowane okno porównawcze – można oglądać obraz przed i po kompresji na podzielonym ekranie oraz powiększyć go do rzeczywistych rozmiarów i porównać piksel po pikselu, co pozwala na samodzielną weryfikację.
4. Analiza szczegółowa: współczynnik kompresji poszczególnych plików, wymiary w pikselach i czas trwania zadania
Wcześniejsze ogólne 46,8% kompresji to wynik zbiorczy dla 4624 obrazów. Po przejściu do poziomu pojedynczych plików można uzyskać więcej szczegółów.
Współczynniki kompresji poszczególnych obrazów nie są jednolite
Dla każdego obrazu obliczono współczynnik kompresji (liczba bajtów po kompresji / liczba bajtów przed kompresją), który waha się od 32,3% do 85,8%:
- Partia o najwyższym współczynniku kompresji: ok. 765 KB zostało skompresowane do 109 KB, czyli 85,8% – tego typu obrazy zwykle miały początkowo niewystarczająco silną kompresję i nadal mają duży potencjał do ponownego kodowania.
- Partia o najniższym współczynniku kompresji: ok. 572 KB skompresowano do 387 KB, czyli 32,3% – te pliki były już wcześniej mocno skompresowane i mają ograniczone możliwości dalszej redukcji.
- Średnia arytmetyczna współczynników kompresji dla 4624 obrazów wynosi 46,44%, co jest bliskie 46,8% obliczonemu na podstawie całkowitego rozmiaru, ale nie identyczne – pierwsza wartość to zwykła średnia współczynników poszczególnych plików, druga to „całkowita oszczędność bajtów ÷ całkowity rozmiar oryginalnych bajtów”. Różnica wskazuje, że pliki o różnych współczynnikach kompresji mają nieproporcjonalny udział w całkowitej objętości – kilka dużych plików ma większy wpływ na wynik ogólny.
Warto zauważyć, że wszystkie współczynniki kompresji obrazów są dodatnie i nie wystąpiła sytuacja „już zminimalizowany, pominięto” – każdy obraz z tej partii „wcześniej skompresowanej przez serwis” mógł zostać jeszcze faktycznie zmniejszony przez ImgZilla.
Wymiary w pikselach: bez zmian
Analizując wymiary w pikselach wszystkich 4624 obrazów, najczęstsze wymiary to 1600×2400 (1756 obrazów) oraz wersja pozioma 2400×1600 (500 obrazów). Zakres wymiarów obejmuje od minimalnych 450×675 (ok. 300 000 pikseli) do maksymalnych 3000×2000 / 2000×3000 (ok. 6 000 000 pikseli).
Kontrola wyrywkowa wymiarów pikseli przed i po kompresji wykazała, że są one identyczne, bez żadnych zmian:
| Plik (przykład) | Rozmiar oryginalny | Rozmiar po kompresji |
|---|---|---|
| Próbka 1 | 1600×1066 | 1600×1066 |
| Próbka 2 | 2000×3000 | 2000×3000 |
| Próbka 3 | 1416×2128 | 1416×2128 |
To druga, często pomijana połowa definicji „kompresji w miejscu”: zmieniają się nie tylko nazwy plików i ścieżki – rozdzielczość również pozostaje bez zmian. ImgZilla nie skaluje ani nie przycina obrazów – cała redukcja rozmiaru wynika wyłącznie z ponownego kodowania, a nie z poświęcania pikseli.
Czas trwania zadania: 4624 obrazy w 51 minut 32 sekundy, średnio 0,669 s na obraz
Środowisko testowe: Mac mini z chipem Apple M1, 8 GB pamięci zunifikowanej, obrazy przechowywane na dysku twardym NAS (mechanicznym) podłączonym przez sieć przewodową 2.5G.
Postęp zadania śledzono na podstawie czasu ostatniego zapisu każdego obrazu (czyli momentu, w którym ImgZilla zakończył kompresję i zapisał plik na dysku): pierwszy zapis o 16:06:09, ostatni o 16:57:41 – całość zajęła 51 minut i 32 sekundy, średnio 0,669 s na obraz.
Dane te są zgodne z projektem produktu – „przetwarzanie szeregowe”, czyli kompresja obraz po obrazie, a nie równoległe zapisywanie w losowej kolejności. W przeliczeniu daje to około 90 obrazów na minutę. Rzeczywista szybkość zależy od rozmiaru plików i wydajności maszyny; podana tutaj wartość to jedynie realny czas dla tej partii obrazów o średniej wielkości ~305 KB w opisanym środowisku – nie jest to uniwersalny benchmark.
5. Dlaczego wybrano kompresję „w miejscu” zamiast zapisywania kopii?
Gdyby w tym teście użyto narzędzia „zapisz jako skompresowaną kopię”, wynik byłby następujący: oryginalne pliki 1,41 GB + skompresowane 0,75 GB, co zajmuje łącznie 2,16 GB. W praktyce zajęłoby to więcej miejsca i wygenerowało wiele plików xxx-min.jpg, które trzeba ręcznie uporządkować i zaktualizować odniesienia w bazie danych lub tabelach produktów.
ImgZilla stosuje nadpisywanie w miejscu: wyniki kompresji są zapisywane bezpośrednio pod oryginalną ścieżką, a wszystkie 4624 nazw plików w 78 folderach pozostają niezmienione – jest to szczególnie istotne dla stron, które zapisały ścieżki obrazów w bazie danych, CDN lub CMS; po kompresji nie trzeba zmieniać żadnych linków. Ceną za to jest modyfikowanie oryginalnych plików, dlatego program domyślnie najpierw przenosi oryginalne obrazy do systemowego kosza, a następnie zapisuje skompresowany wynik. Jeśli chcesz cofnąć zmianę, kliknij prawym przyciskiem myszy w koszu i wybierz „Przywróć”.
6. Analiza korzyści: od rzeczywistych scenariuszy do miesięcznych rachunków
Dla kogo te dane mają praktyczne znaczenie
- Serwisy / deweloperzy działający w obszarze przesyłania obrazów przez użytkowników: przechowywanie obrazów i transfer CDN są zwykle rozliczane za GB – zmniejszenie rozmiaru o połowę oznacza zmniejszenie rachunków o połowę. Co więcej, opłaty za transfer są kosztem generowanym przy każdym wyświetleniu, więc im większy ruch, tym silniejszy efekt. Nawet jeśli standardowa kompresja została wykonana już podczas zapisu, niniejszy test pokazuje, że „uruchomienie dodatkowej, precyzyjnie dostrojonej kompresji” może przynieść nadal znaczące oszczędności.
- Serwery z ograniczoną przestrzenią dyskową / użytkownicy małych dysków: narzędzia do czyszczenia zwykle usuwają pliki cache i duplikaty, ale po kilku miesiącach znów się gromadzą; przestrzeń uwolniona dzięki kompresji to zmniejszenie samych używanych plików, które nie wróci do pierwotnego stanu. Po skompresowaniu tych 78 folderów bezpośrednio zyskaliśmy 662 MB wolnego miejsca, i to na stałe.
- Użytkownicy często przenoszący dane: podczas kopiowania, synchronizacji i kopii zapasowych redukcja rozmiaru o 46,8% przekłada się na proporcjonalnie krótszy czas transferu. Skompresuj raz – oszczędzasz czas przy każdym kolejnym przenoszeniu.
Przeliczenie na rachunek miesięczny: ile właściwie warta jest ta 46,8%?
Redukcja rozmiaru musi ostatecznie znaleźć odzwierciedlenie w rachunku, aby była przekonująca. Poniżej nie powołujemy się na żadne statystyki typu „kompresja zwiększa współczynnik konwersji”, a jedynie mnożymy wynik testu 46,8% przez publiczne cenniki głównych dostawców usług chmurowych dla przechowywania i transferu – czysta arytmetyka.
Oszczędności na przechowywaniu = zaoszczędzony rozmiar (GB) × cena jednostkowa (yuan lub USD / GB / miesiąc)
Oszczędności na transferze wychodzącym = zaoszczędzony rozmiar (GB) × liczba pobrań/odwiedzin w danym miesiącu × cena jednostkowa (yuan lub USD / GB)
Zmniejszenie rozmiaru o połowę w praktyce zmniejsza o połowę obie pozycje rachunku – to matematyka, nie spekulacja.
Koszty przechowywania: im większa biblioteka obrazów, tym większe korzyści
Dostawcy chińscy:
| Oryginalny rozmiar biblioteki | Zaoszczędzona objętość | Alibaba Cloud OSS – standardowa warstwa ¥0,09/GB/mies. |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/mies. |
| 100 GB | 46,8 GB | ¥4,21/mies. |
| 1 TB | 479 GB | ¥43,1/mies. |
Dostawcy zagraniczni:
| Oryginalny rozmiar biblioteki | Zaoszczędzona objętość | AWS S3 Standard $0,023/GB/mies. |
Google Cloud Storage $0,020/GB/mies. (Regional, USA) |
Azure Blob Storage $0,018/GB/mies. (Hot, LRS) |
Cloudflare R2 $0,015/GB/mies. |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/mies. | $0,09/mies. | $0,08/mies. | $0,07/mies. |
| 100 GB | 46,8 GB | $1,08/mies. | $0,94/mies. | $0,84/mies. | $0,70/mies. |
| 1 TB | 479 GB | $11,02/mies. | $9,58/mies. | $8,62/mies. | $7,19/mies. |
Kilku dużych zagranicznych dostawców oferuje bardzo zbliżone ceny przechowywania (różnica w granicach 30%). Nie chodzi o to, kto jest tańszy, lecz o to, że – niezależnie od wyboru – zmniejszenie objętości o połowę przekłada się mniej więcej na połowę tej pozycji rachunku i jest rozliczane co miesiąc. Jednokrotna kompresja sprawia, że od tej pory każdy kolejny miesiąc jest rozliczany według nowego, mniejszego rozmiaru – jest to jednorazowa inwestycja, która przynosi korzyści w długim okresie.
Koszty transferu: największa część rachunku, skalująca się z ruchem
Koszty transferu zasługują na większą uwagę niż koszty przechowywania, ponieważ są iloczynem rozmiaru × liczby pobrań – im częściej obrazy są wyświetlane, tym większe oszczędności z kompresji. Załóżmy, że biblioteka obrazów ma 100 GB i w danym miesiącu generuje 500 GB ruchu wychodzącego przez CDN (co odpowiada około 5-krotnemu pobraniu całej biblioteki):
| Oferta CDN / ruch wychodzący (pierwsza taryfa) | Miesięczny koszt ruchu przed kompresją | Po kompresji (ruch o 46,8% mniejszy) | Oszczędność miesięczna | Oszczędność roczna |
|---|---|---|---|---|
| Alibaba Cloud CDN Chiny (niska taryfa ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront region Azja (ap) ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Ameryka Północna/Europa ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
| Azure Front Door Standard Zone 1 ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
Powyższe wartości to najniższe progi cenowe każdego dostawcy; w rzeczywistości ceny w kolejnych progach są często wyższe (w Alibaba Cloud CDN dla ruchu w Chinach najwyższy próg może sięgać ¥1,31/GB). Im wyższy rachunek, tym większa bezwzględna oszczędność z kompresji. Dodatkowo, obecny plan Azure to Front Door Standard – oprócz ruchu wychodzącego rozliczanego za GB obejmuje on również opłatę bazową w wysokości ok. $35/mies., której kompresja nie zmniejszy; nie została ona uwzględniona w powyższej tabeli oszczędności.
Cloudflare R2 to wyjątek: jego ruch wychodzący wynosi $0 – jeśli przestrzeń jest przechowywana w R2, oszczędności z kompresji pojawiają się niemal wyłącznie w opłatach za przechowywanie; sama część ruchu nie generuje rachunku. To odmienna struktura kosztów niż architektura podwójnego rozliczania „przechowywanie + transfer” (np. Alibaba Cloud OSS+CDN, AWS S3+CloudFront), dlatego przed wyborem dostawcy warto poznać własne pozycje rozliczeniowe.
Powyższe ceny jednostkowe pochodzą z publicznych cenników platform z 2026 roku; rzeczywiste ceny zależą od regionu, rabatów na koncie i progów taryfowych. Sprawdź aktualne ceny na oficjalnych stronach. Liczby pobrań i odwiedzin to przykładowe założenia – zastąp je rzeczywistymi danymi z własnych rachunków.
7. Oszczędność czasu przesyłania i wysyłania
Zmniejszenie rozmiaru o połowę przekłada się na proporcjonalnie krótszy czas transferu – ta zasada nie zależy od rachunków w chmurze, obejmuje zarówno lokalne kopiowanie i tworzenie kopii zapasowych, jak i wysyłanie plików przez użytkownika.
Scenariusz lokalny: USB 3 i sieć gigabitowa
- Zewnętrzny dysk mechaniczny USB 3: typowa prędkość odczytu/zapisu 100–150 MB/s, przyjęto medianę 120 MB/s.
- Zewnętrzny dysk SSD USB 3: prędkość zauważalnie wyższa, zwykle 400–500 MB/s, przyjęto 450 MB/s.
- Sieć przewodowa gigabitowa (1000 Mbps): teoretyczny limit 125 MB/s; po uwzględnieniu narzutu protokołu zmierzona ciągła prędkość wynosi zazwyczaj 100–110 MB/s, przyjęto 105 MB/s.
Powyższe wartości to szacunki oparte na typowych pomiarach; rzeczywista prędkość zależy od nośnika dysku, jakości interfejsu i środowiska sieciowego. Służą wyłącznie do przybliżonych obliczeń.
| Scenariusz | Zaoszczędzony rozmiar | HDD USB 3 @120 MB/s | SSD USB 3 @450 MB/s | Sieć gigabitowa @105 MB/s |
|---|---|---|---|---|
| Ta partia obrazów z testu | 662 MB | ≈5,5 s | ≈1,5 s | ≈6,3 s |
| Biblioteka 10 GB | 4,68 GB | ≈40 s | ≈10 s | ≈45 s |
| Biblioteka 100 GB | 46,8 GB | ≈6,5 min | ≈1,7 min | ≈7,4 min |
| Biblioteka 1 TB | 479 GB | ≈66 min | ≈18 min | ≈76 min |
Pojedyncze 662 MB z niniejszego testu może wydawać się niewielkie – to tylko kilka sekund. Ale analogicznie do kosztów przechowywania, to jednorazowy wysiłek i długoterminowa korzyść: niezależnie od tego, czy kopiujesz dane na dysk zewnętrzny, synchronizujesz z NAS, uruchamiasz Time Machine, przenosisz na nowego Maca czy wysyłasz kolegom – dopóki przenosisz tę partię danych, każdy transfer zajmuje proporcjonalnie mniej czasu. Skompresuj raz, a każda kolejna operacja przesyłania przyniesie oszczędność czasu.
Jeśli kompresja następuje przed wysłaniem przez użytkownika: oszczędność czasu oczekiwania
Wcześniejsze obliczenia dotyczyły korzyści „po przechowywaniu obrazów” – kosztów przechowywania, ruchu CDN i transferu lokalnego. Istnieje jeszcze jeden element wart rozważenia: czas oczekiwania od kliknięcia przez użytkownika przycisku „Wyślij” do zakończenia paska postępu. Ten czas zależy od łącza wysyłania samych użytkowników, a wysyłanie jest zwykle najwolniejszym wąskim gardłem w całym łańcuchu – w zdecydowanej większości konsumenckich łączy szerokopasmowych prędkość wysyłania to zaledwie jedna dziesiąta do jednej piątej prędkości pobierania, a w sieciach mobilnych różnica jest jeszcze wyraźniejsza. Jeśli przed wysłaniem obrazów przez użytkownika strona lub aplikacja skompresuje je narzędziem ImgZilla, zmniejszony rozmiar bezpośrednio przełoży się na krótszy czas oczekiwania użytkownika.
Na podstawie średniego rozmiaru pojedynczego obrazu z testu: oryginalne obrazy po kompresji serwisu mają średnio 299 KB, po ponownej kompresji przez ImgZilla średnio 159 KB, a każdy obraz oszczędza średnio około 140 KB.
| Przepustowość wysyłania (typowe zakresy z publicznych pomiarów szybkości, tylko orientacyjnie) | Pojedynczy obraz 299KB→159KB |
Wgranie 50 zdjęć ≈15,0MB→8,0MB |
Wgranie wszystkich 4624 obrazów z testu 1,41GB→0,75GB |
|---|---|---|---|
| Sieć mobilna (4G/5G, mediana publicznych testów prędkości ok. 10–50 Mbps, przyjęto 30 Mbps) | ok. 0,04 s | ok. 1,9 s | ok. 3 min |
| Typowe domowe łącze szerokopasmowe (pakiety o pobieraniu 100 Mb/s lub 1000 Mb/s z ograniczonym wysyłaniem, ok. 20–30 Mbps, przyjęto 25 Mbps) | ok. 0,04 s | ok. 2,2 s | ok. 3,5 min |
| Symetryczne łącze gigabitowe (wybrani operatorzy / łącza korporacyjne, 1000 Mbps) | ok. 0,001 s | ok. 0,06 s | ok. 5,3 s |
| Odniesienie zagraniczne: średnia prędkość wysyłania stałych łączy w USA (dane Ookla, 2026) | ok. 0,02 s | ok. 1 s | ok. 1,5 min |
Patrząc na pojedynczy obraz, tabela ta może wydawać się bez znaczenia – 0,04 s jest praktycznie nieodczuwalne, co jest uczciwym wynikiem: ta partia testowa sama w sobie nie jest duża (została skompresowana przed zapisem, średnio zaledwie 299 KB na obraz). Są dwa scenariusze, w których wartość jest naprawdę widoczna: przesyłanie całego albumu lub dziesiątek obrazów w jednej operacji oraz większe pliki źródłowe (np. oryginalne JPEG z aparatu lub UGC przesyłane po raz pierwszy bez kompresji po stronie serwisu – takie pliki zwykle mają kilka MB, a nie kilkaset KB). Przy tym samym proporcjonalnym stopniu kompresji bezwzględna oszczędność czasu rośnie proporcjonalnie. W przypadku użytkowników sieci mobilnych i tak stosunkowo wolnego wysyłania skrócenie czasu oczekiwania będzie jeszcze bardziej odczuwalne.
Wartości w tabeli dla sieci mobilnych i domowych łączy szerokopasmowych opierają się na publicznych statystykach pomiarów w Chinach (mediany 4G/5G, typowe proporcje prędkości wysyłania). Rzeczywista prędkość zależy w dużym stopniu od operatora, regionu, urządzenia i przeciążenia sieci; dane te mają charakter jedynie orientacyjny. Dane dotyczące amerykańskich stałych łączy szerokopasmowych pochodzą z raportów Ookla Speedtest.
Chcesz to sprawdzić osobiście? Pobierz ImgZilla bezpośrednio z Mac App Store, przetestuj na kilku obrazach, które zostały już przetworzone przez Twoją stronę, a dopiero potem zdecyduj, czy skompresować kolejne.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Dowiedz się więcej: https://imagetool.app/ImgZilla