Rozmiar bundle JS

Wpisz rozmiar źródła i jednostkę kb albo mb. 100 KB w kb daje 21 KB gzip. 1,5 MB w mb daje 323 KB. 8 KB w kb daje 1,7 KB. Stałe stosunki, nie webpack.

To stałe stosunki minify 0,7, gzip 0,21 i brotli 0,18, nie webpack i nie prawdziwy kompresor. Bajty przed i po liczy współczynnik kompresji.

Dane

Wybierz KB lub MB — wyniki w kilobajtach.

Wynik

Wprowadź dane i kliknij Oblicz.

Jak to działa?

Rozmiar bundle JS w tym kalkulatorze to stałe stosunki do źródła. 100 KB w jednostce kb daje 21 KB gzip. 1,5 MB w mb daje 323 KB. 8 KB w kb daje 1,7 KB. Minify to 0,7 razy źródło, gzip 0,21, brotli 0,18. Kalkulator nie odpala webpacka i nie kompresuje pliku.

Pole źródła to liczba, pole jednostki to kb albo mb. Megabajt mnoży źródło przez 1024, potem te same stosunki. 21 KB przy 100 KB to 0,21 razy 100, nie pomiar z Network. Brotli w tym kalkulatorze jest zawsze 0,18 razy źródło.

Wybierz kb przy 100 i przy 8. Wybierz mb przy 1,5. Inna jednostka przy tej samej liczbie zmienia gzip. Zostaw źródło puste i kalkulator nie pokaże gzip. To szkic first-load, nie stats z vite build.

Współczynnik kompresji obok bierze bajty przed i po, które sam wpiszesz. Tu nie wpisujesz rozmiaru po. Karta sama mnoży źródło. 21 KB zostaje gzip ze stosunku, nie pomiarem z CDN.

Wpisz 100, zostaw kb, potem Oblicz. Wynik gzip to 21 KB. Przecinek w 1,5 przy mb też działa. 8 KB daje 1,7 KB, bo mały wynik zostaje z jednym miejscem po kropce.

100 KB w kb daje 21 KB. 1,5 MB w mb daje 323 KB. 8 KB w kb daje 1,7 KB. Inne źródło przy tych samych stosunkach daje inny gzip.

Wzór

min = 0,7 × źródło; gzip = 0,21 × źródło; brotli = 0,18 × źródło

Jak korzystać

  1. Wpisz rozmiar źródła 100 i zostaw jednostkę kb.
  2. Kliknij Oblicz. Gzip na stronie to 21 KB.
  3. 1,5 i mb dają 323 KB. 8 i kb dają 1,7 KB.
  4. Minify jest 0,7 razy źródło, brotli 0,18 razy źródło.
  5. To nie webpack. Sąsiednia kalkulator liczy współczynnik z bajtów przed i po.

100 KB w kb daje 21 KB gzip

Gzip = 0,21 × źródło. 100 KB w kb daje 21 KB. To nie webpack.

bundle
Źródło JS na karcie. 100 KB w kb daje 21 KB gzip. 8 KB daje 1,7 KB.
rozmiar
Liczba w kb albo mb. 1,5 MB daje 323 KB gzip po × 1024.
gzip
Stały stosunek 0,21 do źródła. Nie kompresor i nie webpack stats.

Przykłady

Przykład 1

  • 100 KB
  • jednostka kb

21 KB

Jaki gzip przy 100 KB źródła w kb? 21 KB. Stosunek 0,21, nie kompresor.

Przykład 2

  • 1,5 MB
  • jednostka mb

323 KB

Jaki gzip przy 1,5 MB w mb? 323 KB. MB mnoży źródło przez 1024.

Przykład 3

  • 8 KB
  • jednostka kb

1.7 KB

Jaki gzip przy 8 KB w kb? 1,7 KB. Mały wynik z jednym miejscem po kropce.

Powiązane kalkulatory

Współczynnik kompresji

Współczynnik kompresji: rozmiar przed i po.

Użyj kalkulatora →

Rozmiar Base64

Rozmiar Base64: bajty i tryb.

Użyj kalkulatora →

Szacunek rozmiaru JSON

Szacunek rozmiaru JSON: znaki, model i overhead.

Użyj kalkulatora →

Rozmiar tokena JWT

Rozmiar tokena JWT: znaki albo bajty.

Użyj kalkulatora →

PX ↔ REM

Kalkulator PX ↔ REM: px albo rem i root.

Użyj kalkulatora →

HEX ↔ RGB

Kalkulator Kolor HEX ↔ RGB: HEX albo RGB.

Użyj kalkulatora →

Wszystkie kalkulatory IT

Najczęstsze pytania

Jaki gzip przy 100 KB źródła w kb?

21 KB. 0,21 razy 100. Stały stosunek, nie prawdziwy gzip.

Ile przy 1,5 MB w mb?

323 KB. 1,5 × 1024 KB, potem 0,21 razy to źródło.

Ile przy 8 KB w kb?

1,7 KB. 0,21 razy 8. Mały wynik zostaje z jednym miejscem po kropce.

Czy to webpack albo vite build?

Nie. Kalkulator mnoży źródło przez 0,7 / 0,21 / 0,18. Nie czyta stats.

Czy brotli jest mierzony?

Nie. Brotli tu zawsze 0,18 razy źródło. Realny Brotli bywa inny.

Co zmienia jednostka mb?

Źródło razy 1024, potem te same stosunki. 1,5 w mb daje 323 KB gzip.

Czy przecinek w 1,5 działa?

Tak. 1,5 i 1.5 to ten sam wpis przy mb.

Czym to różni się od współczynnika kompresji?

Tam wpisujesz przed i po. Tu 100 KB w kb samo daje 21 KB gzip.

Czy 21 KB to transfer z CDN?

Nie. To 0,21 razy wpisane źródło. Network panel bywa inny.

Źródła wiedzy

Kalkulator liczy bity, bajty albo przepustowość z Twoich liczb. Poniżej definicje bitu i SI (GUM).

Strona zaktualizowana w 2026.

Dlaczego rozmiar bundle JS ma znaczenie

JavaScript trzeba pobrać, sparsować i wykonać, zanim strona stanie się responsywna. Duży initial bundle uderza w TTI szczególnie na mobile (słabszy CPU + sieć).

Kalkulator daje orientacyjne wielkości względem rozmiaru źródła (minify ~70%, gzip ~21%, Brotli ~18%). To nie zastępuje vite build / Lighthouse.

Rozmiar surowy vs transferowany

  • Źródło / minified — artefakt na dysku (Resource size).
  • Gzip / Brotli — typowy transfer HTTP (Transfer size).
  • Kompresja pomaga pobieraniu, ale przeglądarka i tak parsuje rozpakowany JS.

Koszt pobrania vs parse/execute

Nawet przy szybkim Wi‑Fi 300 KB minified JS potrafi zająć main thread na słabym telefonie. „Mały transfer po gzip” nie oznacza „tani w runtime”.

  • Framework + runtime (React/Vue/…) mają stały koszt bazowy.
  • Ciężkie biblioteki (moment, duże UI kity) bolą zarówno w KB, jak i w parse.
  • Mierz realnie: Lighthouse, Performance panel, Web Vitals.

Code splitting i lazy loading

Cel to mniejszy initial JS, niekoniecznie mniejsza suma wszystkich chunków. Lazy routes, dynamic import() i tree-shaking przesuwają koszt na moment użycia.

Ten kalkulator nie modeluje splitu — wpisz rozmiar chunka, który naprawdę leci na first load.

Intuicyjne progi (gzip initial)

Reguła kciuka — dopasuj do swojej aplikacji.

Gzip (orient.)OdczucieTypowa akcja
< ~100 KBwygodnieutrzymuj budżet
~100–300 KBczuć na 3G/CPUaudyt zależności
> ~300 KBbolesny first loadsplit / usuń deps

Współczynniki w wyniku są stałe — ufaj build stats przy decyzjach produkcyjnych.

Przykłady liczbowe (przy założonych współczynnikach)

  • 50 KB źródła → ~35 KB min, ~10.5 KB gzip — lekki chunk.
  • 300 KB źródła → ~210 KB min, ~63 KB gzip — już mobilnie odczuwalne.
  • Vendor już zminifikowany może kompresować się inaczej niż „surowy” app code — sprawdź Network panel.