Rozmiar bundle JS
Orientacyjny rozmiar bundle JS: źródło → minify / gzip / Brotli. Do intuicji first-load i budżetu wydajności — nie zamiennik webpack stats. Wynik po Oblicz.
Wynik
Wprowadź dane i kliknij Oblicz.
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.) | Odczucie | Typowa akcja |
|---|---|---|
| < ~100 KB | wygodnie | utrzymuj budżet |
| ~100–300 KB | czuć na 3G/CPU | audyt zależności |
| > ~300 KB | bolesny first load | split / 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.
FAQ — bundle JS
Jak czytać szacunek minify/gzip vs realne build stats.
- Czy to dokładny wynik Vite/webpack?
- Nie. Stałe współczynniki orientacyjne. Decyduj na podstawie build stats i Lighthouse.
- Skąd 70% / 21% / 18%?
- Uproszczone typowe proporcje względem źródła JS. Realny gzip zależy od redundancji kodu.
- KB czy KiB?
- MB = ×1024 KB (jak wiele narzędzi frontendowych).
- Najpierw ciąć gzip czy źródło?
- Najpierw mniej JS na first load (split, tree-shake, mniej deps). Kompresja jest drugim krokiem.
- Czy Brotli zawsze wygrywa z gzip?
- Często mniejszy transfer; liczy się wsparcie CDN i koszt CPU kompresji.
- Gzip mały, a strona wolna — dlaczego?
- Parse/execute nadal pracuje na rozpakowanym JS. Patrz na main-thread, nie tylko na KB transferu.
- Jak to się ma do JSON/Base64?
- Koszt payloadu API vs koszt JS aplikacji — audytuj oba, gdy TTI kuleje.
- Co wpisać przy code splitting?
- Rozmiar chunków ładowanych na first paint/route — nie sumę całego projektu.