Wprowadzenie: Dlaczego rozmiar bundli JavaScript to wciąż Twój największy problem
JavaScript rządzi współczesnym webem — ale jest też jego największym hamulcem. Szczerze mówiąc, dane z HTTP Archive za początek 2026 roku nie pozostawiają żadnych złudzeń: mediana rozmiaru JavaScript na stronach mobilnych przekroczyła 500 KB skompresowanego kodu, co po rozpakowaniu daje często ponad 1,5 MB surowego kodu do sparsowania i wykonania. To bezpośrednio przekłada się na wolniejsze ładowanie stron, gorsze wyniki Core Web Vitals i — co najważniejsze — utratę użytkowników.
W poprzednim artykule omówiliśmy optymalizację trzech kluczowych metryk Core Web Vitals: LCP, INP i CLS. Teraz czas zagłębić się w jedno z najważniejszych źródeł problemów wydajnościowych — bundling JavaScript. Bo nawet najlepiej zoptymalizowany serwer i idealne obrazy nie pomogą, jeśli przeglądarka musi pobrać, sparsować i wykonać megabajty kodu, zanim użytkownik zobaczy cokolwiek użytecznego.
W tym przewodniku pokażę Ci, jak w 2026 roku skutecznie zmniejszyć rozmiar paczek JavaScript, wybrać odpowiedni bundler, wdrożyć zaawansowane techniki code splittingu i tree shakingu, oraz jak wykorzystać najnowsze API przeglądarek do inteligentnego ładowania zasobów. No to zaczynajmy.
Stan ekosystemu bundlerów w 2026: Rust zmienia wszystko
Zanim przejdziemy do technik optymalizacji, warto zrozumieć, czym w ogóle dysponujemy. Rok 2026 to moment, w którym bundlery napisane w Rust definitywnie zdominowały ekosystem. I nie chodzi już tylko o szybkość budowania — nowa generacja narzędzi oferuje lepsze tree shaking, inteligentniejszy code splitting i mniejsze wynikowe paczki.
Vite 8 z Rolldown — nowy król bundlingu
Największą rewolucją jest Vite 8, który w pełni integruje Rolldown — bundler napisany w Rust, zaprojektowany jako następca zarówno esbuild (używanego w dev), jak i Rollup (używanego w produkcji). Wyniki benchmarków są, powiem wprost, imponujące:
- Projekt React z 10 000 komponentów JSX: budowanie skrócone z 14 sekund do mniej niż 4 sekund (poprawa o 70%)
- Excalidraw: czas budowania spadł z 22,9 sekundy do 1,4 sekundy
- Rozmiar wynikowych paczek mniejszy o 10-20% dzięki lepszemu tree shakingowi
Ale szybkość budowania to nie jedyna zaleta. Rolldown wprowadza koncepcję Full Bundle Mode dla serwera deweloperskiego, który eliminuje problem „wodospadu" tysięcy żądań HTTP podczas developmentu. Wstępne wyniki pokazują 3× szybszy start serwera dev, 40% szybsze pełne przeładowania i 10× mniej żądań sieciowych. Naprawdę robi to różnicę w codziennej pracy.
// vite.config.ts — konfiguracja Vite 8 z Rolldown
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
build: {
// Rolldown jest teraz domyślnym bundlerem w Vite 8
rollupOptions: {
output: {
// Zaawansowane chunking z Rolldown
manualChunks: {
'vendor-react': ['react', 'react-dom'],
'vendor-router': ['react-router-dom'],
'vendor-utils': ['lodash-es', 'date-fns'],
},
},
},
// Nowe opcje Rolldown
minify: 'oxc', // Minifikator OXC — szybszy niż Terser
target: 'es2022',
},
});
Rspack — drop-in replacement dla Webpacka
Rspack to bundler napisany w Rust, który oferuje niemal pełną kompatybilność z ekosystemem Webpacka. Jeśli Twój projekt używa Webpacka i migracja do Vite jest zbyt kosztowna (a bywa, uwierz mi), Rspack jest doskonałą alternatywą. Czas budowania spada dramatycznie — z 8 sekund (Webpack) do około 400 milisekund — przy zachowaniu kompatybilności z większością pluginów i loaderów Webpacka.
// rspack.config.js — migracja z Webpacka
const { defineConfig } = require('@rspack/cli');
module.exports = defineConfig({
entry: './src/index.tsx',
output: {
filename: '[name].[contenthash:8].js',
chunkFilename: '[name].[contenthash:8].chunk.js',
clean: true,
},
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
priority: 10,
},
common: {
minChunks: 2,
priority: 5,
reuseExistingChunk: true,
},
},
},
// Rspack obsługuje te same opcje co Webpack
usedExports: true,
sideEffects: true,
},
});
Turbopack — opcja dla ekosystemu Next.js
Turbopack, rozwijany przez Vercel, w 2026 roku osiągnął pełną stabilność w Next.js. Oferuje do 10× szybsze budowanie w trybie deweloperskim i do 700× szybsze Hot Module Replacement (HMR) w porównaniu z Webpackiem. Trzeba jednak uczciwie powiedzieć — w testach Turbopack generuje nieco większe paczki produkcyjne niż Rolldown czy Rollup. Więc jeśli rozmiar bundla jest priorytetem, a nie używasz Next.js, Vite 8 z Rolldown pozostaje lepszym wyborem.
Tree shaking w praktyce: eliminacja martwego kodu
Tree shaking (dosłownie: „potrząsanie drzewem") to technika usuwania nieużywanego kodu z wynikowego bundla. Opiera się na statycznej analizie importów i eksportów w modułach ES6.
Brzmi prosto, prawda? W praktyce jest pełna pułapek, które mogą sprawić, że Twój bundle wciąż będzie zawierał tony niepotrzebnego kodu. Sam kiedyś spędziłem pół dnia szukając, dlaczego po tree shakingu nadal mam 200 KB biblioteki, z której używam jednej funkcji. Okazało się — barrel exports.
Warunek nr 1: moduły ES6 (ESM) wszędzie
Tree shaking działa wyłącznie z modułami ES6 (import/export). Jeśli jakakolwiek biblioteka w Twoim projekcie używa CommonJS (require/module.exports), bundler nie jest w stanie statycznie przeanalizować, które eksporty są faktycznie używane — i musi dołączyć całą bibliotekę.
// ❌ ZŁE — import całej biblioteki (CJS lub barrel export)
import _ from 'lodash';
const result = _.groupBy(data, 'category');
// Rozmiar: ~72 KB (cała biblioteka Lodash)
// ✅ DOBRE — import konkretnej funkcji z wersji ESM
import { groupBy } from 'lodash-es';
const result = groupBy(data, 'category');
// Rozmiar: ~2 KB (tylko funkcja groupBy + zależności)
// ✅ NAJLEPSZE — import bezpośredni z pliku źródłowego
import groupBy from 'lodash-es/groupBy';
const result = groupBy(data, 'category');
// Rozmiar: ~1.5 KB (minimalna ilość kodu)
Kluczowa wskazówka: przed dodaniem jakiejkolwiek nowej biblioteki sprawdź na bundlephobia.com, czy oferuje wersję ESM i czy wspiera tree shaking. W 2026 roku większość popularnych bibliotek już to robi, ale wciąż zdarzają się wyjątki — szczególnie w starszych paczkach z ekosystemu Node.js.
Warunek nr 2: poprawne oznaczanie efektów ubocznych
Efekty uboczne (side effects) to operacje, które moduł wykonuje przy importowaniu — na przykład modyfikacja globalnego obiektu, rejestracja polyfilli czy dodawanie stylów CSS. Bundler nie może usunąć modułu z efektami ubocznymi, nawet jeśli żaden z jego eksportów nie jest używany, bo mógłby złamać działanie aplikacji.
Dlatego pole sideEffects w package.json jest takie ważne. Informuje bundler, które pliki można bezpiecznie usunąć:
// package.json — prawidłowa konfiguracja sideEffects
{
"name": "moja-biblioteka",
"version": "2.0.0",
"module": "dist/esm/index.js",
"sideEffects": [
"*.css",
"*.scss",
"./src/polyfills.js"
]
// Wszystkie inne pliki są bezpieczne do usunięcia przez tree shaking
}
// Jeśli żaden plik nie ma efektów ubocznych:
{
"sideEffects": false
}
Warunek nr 3: unikanie barrel exports
Barrel exports (pliki index.ts, które re-eksportują wszystko z danego katalogu) to jeden z najczęstszych „zabójców" tree shakingu. Problem polega na tym, że importowanie czegokolwiek z barrel file wymusza od bundlera przetworzenie wszystkich re-eksportowanych modułów:
// ❌ ZŁY PATTERN: barrel export w utils/index.ts
export { formatDate } from './date';
export { validateEmail } from './email';
export { parseJSON } from './json';
export { debounce, throttle } from './timing';
export { deepMerge, cloneDeep } from './objects';
// ... 50 kolejnych eksportów
// Importując jedną funkcję, zmuszasz bundler do przetworzenia WSZYSTKICH:
import { formatDate } from '@/utils';
// ✅ LEPSZY PATTERN: import bezpośredni
import { formatDate } from '@/utils/date';
W 2026 roku Rolldown i Rspack radzą sobie z barrel exports znacznie lepiej niż wcześniejsze bundlery, ale wciąż nie eliminują wszystkich niepotrzebnych modułów w każdym przypadku. Bezpośrednie importy to nadal najskuteczniejsza strategia.
Code splitting: ładuj tylko to, czego naprawdę potrzebujesz
Tree shaking eliminuje nieużywany kod, ale code splitting idzie o krok dalej — dzieli Twój bundle na mniejsze kawałki (chunki) i ładuje je dopiero wtedy, gdy są potrzebne. To kluczowa technika redukcji rozmiaru początkowego ładowania.
Route-based code splitting
Najpopularniejsza i najskuteczniejsza forma code splittingu — podział kodu na podstawie tras (routes) aplikacji. Bo pomyśl: użytkownik odwiedzający stronę główną nie musi przecież pobierać kodu panelu administracyjnego.
// React — route-based code splitting z React.lazy()
import { Suspense, lazy } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';
// Dynamiczne importy — każda trasa to osobny chunk
const Home = lazy(() => import('./pages/Home'));
const Products = lazy(() => import('./pages/Products'));
const ProductDetail = lazy(() => import('./pages/ProductDetail'));
const Cart = lazy(() => import('./pages/Cart'));
const Checkout = lazy(() => import('./pages/Checkout'));
const AdminDashboard = lazy(() => import('./pages/admin/Dashboard'));
function App() {
return (
<BrowserRouter>
<Suspense fallback={<PageSkeleton />}>
<Routes>
<Route path="/" element={<Home />} />
<Route path="/products" element={<Products />} />
<Route path="/products/:id" element={<ProductDetail />} />
<Route path="/cart" element={<Cart />} />
<Route path="/checkout" element={<Checkout />} />
<Route path="/admin/*" element={<AdminDashboard />} />
</Routes>
</Suspense>
</BrowserRouter>
);
}
Component-level code splitting
Nie wszystkie ciężkie komponenty są powiązane z trasami. Modalne okna, edytory WYSIWYG, mapy, wykresy — te elementy często ważą setki kilobajtów i powinny być ładowane dopiero gdy użytkownik ich naprawdę potrzebuje:
// Komponent ładowany na żądanie — np. ciężki edytor tekstu
import { lazy, Suspense, useState } from 'react';
const RichTextEditor = lazy(() => import('./components/RichTextEditor'));
function ArticleForm() {
const [showEditor, setShowEditor] = useState(false);
return (
<div>
<h2>Nowy artykuł</h2>
<input type="text" placeholder="Tytuł artykułu" />
{!showEditor ? (
<button onClick={() => setShowEditor(true)}>
Otwórz edytor treści
</button>
) : (
<Suspense fallback={<div>Ładowanie edytora...</div>}>
<RichTextEditor />
</Suspense>
)}
</div>
);
}
Prefetching chunków — antycypacja potrzeb użytkownika
Code splitting ma jedną wadę: kiedy użytkownik faktycznie potrzebuje danego chunka, musi poczekać na jego pobranie. To może być frustrujące. Rozwiązaniem jest prefetching — pobieranie chunków w tle, zanim użytkownik ich potrzebuje:
// Prefetch chunka przy najechaniu myszą na link
function NavLink({ to, children }) {
const handleMouseEnter = () => {
// Webpack/Rspack magic comment
if (to === '/products') {
import(/* webpackPrefetch: true */ './pages/Products');
}
if (to === '/cart') {
import(/* webpackPrefetch: true */ './pages/Cart');
}
};
return (
<Link to={to} onMouseEnter={handleMouseEnter}>
{children}
</Link>
);
}
// Alternatywa z Vite — prefetch za pomocą <link rel="modulepreload">
// Vite automatycznie generuje te tagi dla dynamicznych importów
Analiza bundla: zidentyfikuj winowajców
Zanim zaczniesz optymalizować, musisz wiedzieć, co dokładnie znajduje się w Twoim bundlu. Bez wizualizacji pracujesz na ślepo — a to trochę jak optymalizacja zapytań SQL bez EXPLAIN.
Na szczęście narzędzia dostępne w 2026 roku są naprawdę potężne.
Webpack Bundle Analyzer i jego odpowiedniki
# Webpack / Rspack
npm install --save-dev webpack-bundle-analyzer
npx webpack --profile --json=stats.json
npx webpack-bundle-analyzer stats.json
# Vite — wbudowany plugin
npm install --save-dev rollup-plugin-visualizer
// vite.config.ts — dodanie wizualizera bundla
import { defineConfig } from 'vite';
import { visualizer } from 'rollup-plugin-visualizer';
export default defineConfig({
plugins: [
visualizer({
open: true,
gzipSize: true,
brotliSize: true,
filename: 'bundle-report.html',
}),
],
});
Po wygenerowaniu raportu zwróć szczególną uwagę na:
- Duplikaty bibliotek — różne wersje tej samej biblioteki w bundlu (np. dwie wersje lodash — zdarza się częściej, niż myślisz)
- Niepotrzebne polyfille — jeśli celujesz w nowoczesne przeglądarki, wiele polyfilli jest po prostu zbędnych
- Ciężkie zależności — biblioteki, które dostarczają jedną funkcję, ale ważą 100+ KB
- Nieużywane eksporty — kod, który przetrwał tree shaking z powodu side effects
Budżet wydajnościowy: ustaw limity
Analiza bundla to nie jednorazowa czynność — powinna być częścią procesu CI/CD. Ustaw budżet wydajnościowy, który automatycznie ostrzeże Cię (albo wręcz zablokuje build), gdy rozmiar paczki przekroczy ustalony limit:
// webpack/rspack — konfiguracja budżetu wydajnościowego
module.exports = {
performance: {
maxAssetSize: 250 * 1024, // 250 KB na asset
maxEntrypointSize: 300 * 1024, // 300 KB na entry point
hints: 'error', // 'warning' | 'error' — zatrzyma build przy przekroczeniu
},
};
// Vite — custom plugin do sprawdzania rozmiaru
function bundleSizeGuard(limits) {
return {
name: 'bundle-size-guard',
writeBundle(options, bundle) {
for (const [fileName, chunk] of Object.entries(bundle)) {
if (chunk.type === 'chunk') {
const sizeKB = chunk.code.length / 1024;
if (sizeKB > limits.maxChunkSize) {
console.error(
`⚠️ Chunk "${fileName}" (${sizeKB.toFixed(1)} KB) ` +
`przekracza limit ${limits.maxChunkSize} KB!`
);
process.exit(1);
}
}
}
},
};
}
Strategiczne ładowanie skryptów: async, defer, modulepreload
Optymalizacja samego bundla to połowa sukcesu. Druga połowa to sposób, w jaki ładujesz skrypty w przeglądarce. Niewłaściwe ładowanie może sprawić, że nawet mały skrypt zablokuje renderowanie strony. A to potrafi boleć.
async vs defer vs module — co wybrać?
Oto krótkie porównanie trzech głównych strategii ładowania skryptów:
- <script> (bez atrybutów) — blokuje parsowanie HTML. Nie używaj tego nigdy, chyba że masz naprawdę dobry powód (a prawdopodobnie nie masz).
- <script defer> — pobiera skrypt równolegle z parsowaniem HTML, wykonuje po zakończeniu parsowania, zachowuje kolejność. To powinien być Twój domyślny wybór.
- <script async> — pobiera równolegle, ale wykonuje natychmiast po pobraniu, nie zachowuje kolejności. Dobre dla niezależnych skryptów (analytics, chat).
- <script type="module"> — zachowuje się jak defer, ale z obsługą ESM. W 2026 roku to standardowe podejście dla nowoczesnych aplikacji.
<!-- ❌ NIE RÓB TEGO — skrypt blokujący renderowanie -->
<script src="/js/app.js"></script>
<!-- ✅ Skrypt aplikacji — defer zachowuje kolejność -->
<script src="/js/app.js" defer></script>
<!-- ✅ Moduł ES — domyślnie deferred -->
<script type="module" src="/js/app.mjs"></script>
<!-- ✅ Niezależne skrypty firm trzecich — async -->
<script src="https://analytics.example.com/tracker.js" async></script>
<!-- ✅ Preload modułu — przyspiesza ładowanie zależności -->
<link rel="modulepreload" href="/js/vendor-react.mjs">
<link rel="modulepreload" href="/js/utils.mjs">
Zaawansowane: modulepreload i łańcuch zależności
Ładowanie modułów ES ma jeden problem — przeglądarka odkrywa zależności dopiero po pobraniu i sparsowaniu głównego modułu, co tworzy „wodospad" żądań. <link rel="modulepreload"> rozwiązuje ten problem, informując przeglądarkę z wyprzedzeniem o wszystkich potrzebnych modułach:
<!-- Bez modulepreload — wodospad żądań -->
<!-- 1. Pobierz app.mjs → 2. Odkryj import react → 3. Pobierz react.mjs → ... -->
<!-- Z modulepreload — równoległe pobieranie -->
<link rel="modulepreload" href="/js/vendor-react.mjs">
<link rel="modulepreload" href="/js/vendor-router.mjs">
<link rel="modulepreload" href="/js/utils.mjs">
<script type="module" src="/js/app.mjs"></script>
<!-- Wszystkie moduły pobierane równolegle od początku! -->
Bundlery takie jak Vite 8 automatycznie generują tagi modulepreload dla dynamicznych importów, ale warto sprawdzić, czy ta funkcja jest włączona w Twojej konfiguracji.
Import Maps: kontrola nad resolucją modułów w przeglądarce
Import Maps to technologia, która w 2026 roku jest już wspierana przez wszystkie główne przeglądarki (Chrome, Firefox, Safari, Edge). Pozwala na mapowanie nazw modułów na konkretne URLe, bez potrzeby bundlowania ich razem z kodem aplikacji. I szczerze? To otwiera zupełnie nowe możliwości optymalizacji.
<!-- Import map definiuje mapowanie modułów -->
<script type="importmap">
{
"imports": {
"react": "https://esm.sh/[email protected]",
"react-dom/client": "https://esm.sh/[email protected]/client",
"lodash-es/": "https://esm.sh/[email protected]/",
"@app/": "/js/modules/"
}
}
</script>
<!-- Teraz możesz importować bez bundlowania -->
<script type="module">
import React from 'react';
import { createRoot } from 'react-dom/client';
import { debounce } from 'lodash-es/debounce';
import { formatPrice } from '@app/utils/format.js';
// Kod aplikacji...
</script>
Import Maps i inwalidacja cache
Jedną z największych zalet Import Maps jest rozwiązanie problemu kaskadowej inwalidacji cache. W tradycyjnym bundlingu zmiana jednego modułu wymusza zmianę hashy w plikach wszystkich modułów, które go importują — co oznacza, że użytkownik musi ponownie pobrać znacznie więcej kodu niż się faktycznie zmieniło. Import Maps elegancko eliminują ten problem:
<!-- Wersja 1 -->
<script type="importmap">
{
"imports": {
"@app/utils": "/js/utils.abc123.js",
"@app/components": "/js/components.def456.js"
}
}
</script>
<!-- Po aktualizacji utils — zmienia się TYLKO hash utils -->
<script type="importmap">
{
"imports": {
"@app/utils": "/js/utils.xyz789.js",
"@app/components": "/js/components.def456.js"
}
}
</script>
<!-- Przeglądarka ponownie pobiera TYLKO utils! -->
Speculation Rules API: natychmiastowe nawigacje
To moim zdaniem jedna z najbardziej ekscytujących nowości w świecie wydajności webowej. Speculation Rules API pozwala przeglądarce na spekulatywne prefetchowanie lub nawet pełne prerenderowanie stron, do których użytkownik prawdopodobnie przejdzie. Efekt? Nawigacja, która wydaje się natychmiastowa — bo strona jest już gotowa w tle.
Podstawowa konfiguracja
<!-- Speculation Rules — prefetch i prerender -->
<script type="speculationrules">
{
"prefetch": [
{
"where": {
"href_matches": "/products/*"
},
"eagerness": "moderate"
}
],
"prerender": [
{
"where": {
"href_matches": ["/", "/about", "/contact"]
},
"eagerness": "moderate"
}
]
}
</script>
Poziomy „chętności" (eagerness)
Speculation Rules API oferuje trzy poziomy eagerness, które kontrolują, kiedy przeglądarka rozpocznie spekulatywne ładowanie:
- immediate — prefetch/prerender rozpoczyna się natychmiast po załadowaniu strony. Używaj ostrożnie — zjada przepustowość.
- moderate — prefetch rozpoczyna się, gdy użytkownik najedzie kursorem na link przez 200 ms. Optymalny kompromis między szybkością a zużyciem zasobów.
- conservative — prefetch rozpoczyna się dopiero gdy użytkownik kliknie link (ale przed nawigacją). Najbezpieczniejsza opcja.
Zaawansowane reguły z filtrami
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/api/*" } },
{ "not": { "href_matches": "/admin/*" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate",
"referrer_policy": "no-referrer"
}
]
}
</script>
Ważne zastrzeżenie: na początku 2026 roku Speculation Rules API jest w pełni wspierane tylko w przeglądarkach opartych na Chromium (Chrome, Edge, Opera). Firefox i Safari ignorują te reguły — ale nie powodują żadnych błędów, więc można je bezpiecznie wdrożyć jako progressive enhancement. Zawsze warto mieć to w tylnej kieszeni.
Optymalizacja skryptów firm trzecich
Nie cały JavaScript na Twojej stronie pochodzi z Twojego kodu. Skrypty analityczne, chatboty, widgety social media, narzędzia marketingowe — te skrypty firm trzecich potrafią dodać setki kilobajtów do ładowania strony. I co gorsza — często nie masz nad nimi pełnej kontroli.
Strategia 1: audyt i eliminacja
Pierwszy krok to uczciwa odpowiedź na pytanie: czy naprawdę potrzebujesz tego skryptu? Zdziwiłbyś się, jak często strony ładują narzędzia, których nikt aktywnie nie używa — resztki po kampaniach marketingowych, stare widgety, zduplikowane systemy analityczne.
// Audyt skryptów firm trzecich — performance observer
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.initiatorType === 'script') {
const isThirdParty = !entry.name.includes(location.hostname);
if (isThirdParty) {
console.table({
url: entry.name,
duration: `${entry.duration.toFixed(0)}ms`,
transferSize: `${(entry.transferSize / 1024).toFixed(1)} KB`,
blockingTime: entry.renderBlockingStatus,
});
}
}
}
});
observer.observe({ type: 'resource', buffered: true });
Strategia 2: opóźnione ładowanie (lazy loading skryptów)
Skrypty, które nie są potrzebne do pierwszego renderowania, powinny być ładowane dopiero po interakcji użytkownika lub po pełnym załadowaniu strony. To prosty zabieg, a efekt potrafi być zaskakująco duży:
// Ładowanie czata dopiero po kliknięciu przycisku
function loadChatWidget() {
const script = document.createElement('script');
script.src = 'https://chat-provider.com/widget.js';
script.async = true;
document.body.appendChild(script);
}
document.getElementById('chat-button')
.addEventListener('click', loadChatWidget, { once: true });
// Ładowanie analytics po załadowaniu strony + opóźnienie
function loadAnalytics() {
if ('requestIdleCallback' in window) {
requestIdleCallback(() => {
const script = document.createElement('script');
script.src = 'https://analytics.example.com/tracker.js';
script.async = true;
document.body.appendChild(script);
});
} else {
setTimeout(() => {
const script = document.createElement('script');
script.src = 'https://analytics.example.com/tracker.js';
script.async = true;
document.body.appendChild(script);
}, 3000);
}
}
window.addEventListener('load', loadAnalytics);
Strategia 3: Resource Hints dla domen zewnętrznych
Jeśli musisz załadować skrypt z zewnętrznej domeny, przynajmniej przyspiesz nawiązywanie połączenia za pomocą resource hints:
<!-- dns-prefetch — rozwiązuje DNS z wyprzedzeniem -->
<link rel="dns-prefetch" href="https://analytics.example.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<!-- preconnect — pełne nawiązanie połączenia z wyprzedzeniem -->
<!-- Użyj preconnect TYLKO dla kluczowych domen (max 2-3) -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preconnect" href="https://api.example.com" crossorigin>
<!-- UWAGA: zbyt wiele preconnect może zaszkodzić wydajności! -->
<!-- Dla mniej krytycznych domen użyj dns-prefetch -->
Praktyczny plan optymalizacji: od analizy do wdrożenia
Teoria jest ważna, ale bez konkretnego planu działania niewiele wskórasz. Oto krok po kroku, jak podejść do optymalizacji bundli JavaScript w istniejącym projekcie.
Krok 1: pomiar stanu wyjściowego
Nie optymalizuj w ciemno. Najpierw zmierz.
- Uruchom Lighthouse w Chrome DevTools — zapisz wyniki dla głównych metryk
- Wygeneruj raport Bundle Analyzer — zidentyfikuj największe chunki
- Sprawdź zakładkę Coverage w Chrome DevTools — pokaże, ile procent pobranego JavaScript jest faktycznie wykorzystywane na danej stronie
- Zmierz Total Blocking Time (TBT) — czas, w którym główny wątek jest zablokowany przez JavaScript
Krok 2: quick wins (natychmiastowe rezultaty)
Zacznij od nisko wiszących owoców — zmian, które dają duży efekt przy minimalnym nakładzie pracy:
- Kompresja Brotli — jeśli serwer serwuje gzip zamiast Brotli, zmiana konfiguracji może zmniejszyć transfer o 15-20%
- Usunięcie zduplikowanych bibliotek — sprawdź npm ls lub pnpm ls pod kątem wielu wersji tej samej paczki
- Zamiana ciężkich bibliotek na lżejsze alternatywy — np. moment.js (300 KB) → date-fns (20 KB dla typowego użycia) → Temporal API (0 KB — wbudowane w przeglądarki w 2026 roku!)
- Dodanie defer/async do skryptów firm trzecich
Krok 3: strukturalne zmiany
- Wdrożenie route-based code splitting — jeśli Twoja aplikacja nie dzieli kodu na trasy, to jest absolutny priorytet
- Lazy loading ciężkich komponentów — mapy, wykresy, edytory, kalendarze
- Migracja na ESM — zamień biblioteki CommonJS na ich wersje ESM
- Eliminacja barrel exports — używaj bezpośrednich importów
Krok 4: automatyzacja i monitoring
To krok, który większość zespołów pomija — a nie powinni. Bez automatyzacji wrócisz do punktu wyjścia szybciej niż myślisz.
- Performance budget w CI/CD — automatycznie blokuj merge requesty, które przekraczają limity
- Lighthouse CI — automatyczne testy wydajności przy każdym pull requeście
- Real User Monitoring (RUM) — monitoruj rzeczywiste wyniki użytkowników, nie tylko laboratoryjne testy
# Przykład konfiguracji Lighthouse CI (.lighthouserc.json)
{
"ci": {
"collect": {
"url": ["https://example.com/", "https://example.com/products"],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"total-byte-weight": ["error", { "maxNumericValue": 500000 }],
"mainthread-work-breakdown": ["warn", { "maxNumericValue": 4000 }],
"bootup-time": ["error", { "maxNumericValue": 3000 }]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}
Zaawansowane techniki: Web Workers i wasm
Nie cały JavaScript musi działać na głównym wątku. Ciężkie obliczenia — przetwarzanie danych, parsowanie, transformacje — można przenieść do Web Workerów, odciążając główny wątek i poprawiając INP (Interaction to Next Paint):
// main.js — delegowanie ciężkich obliczeń do Workera
const worker = new Worker(
new URL('./heavy-computation.worker.js', import.meta.url),
{ type: 'module' }
);
// Wysłanie danych do przetworzenia
worker.postMessage({ type: 'PROCESS_DATA', data: largeDataset });
// Odbiór wyników
worker.addEventListener('message', (event) => {
const { type, result } = event.data;
if (type === 'RESULT') {
updateUI(result); // Aktualizuj UI z wynikami
}
});
// heavy-computation.worker.js
self.addEventListener('message', async (event) => {
const { type, data } = event.data;
if (type === 'PROCESS_DATA') {
// Ciężkie obliczenia — nie blokują głównego wątku
const result = data
.filter(item => item.isActive)
.map(item => ({
...item,
score: calculateComplexScore(item),
rank: determineRank(item),
}))
.sort((a, b) => b.score - a.score);
self.postMessage({ type: 'RESULT', result });
}
});
W 2026 roku Vite 8 i Rspack mają wbudowane wsparcie dla bundlowania Web Workerów z pełnym tree shakingiem i code splittingiem. Nie musisz konfigurować oddzielnych pipeline'ów — import Workera działa tak samo jak import zwykłego modułu. Wygodne, prawda?
Checklist optymalizacji bundli JavaScript
Na zakończenie — kompletna lista kontrolna, którą możesz (i powinieneś) wykorzystać przy każdym projekcie:
- Bundler: Czy używasz nowoczesnego bundlera (Vite 8, Rspack)? Czy masz włączony tryb produkcyjny?
- Tree shaking: Czy wszystkie biblioteki używają ESM? Czy
sideEffectsw package.json jest poprawnie skonfigurowane? - Code splitting: Czy trasy są ładowane dynamicznie? Czy ciężkie komponenty używają lazy loading?
- Kompresja: Czy serwer używa Brotli (nie gzip)? Czy pliki statyczne są pre-kompresowane?
- Ładowanie skryptów: Czy skrypty używają defer lub async? Czy moduły ES mają modulepreload?
- Skrypty firm trzecich: Czy każdy skrypt jest naprawdę potrzebny? Czy te mniej krytyczne są ładowane z opóźnieniem?
- Resource hints: Czy używasz preconnect/dns-prefetch dla kluczowych domen zewnętrznych?
- Budżet wydajnościowy: Czy masz ustawione limity rozmiaru bundla w CI/CD?
- Monitoring: Czy monitorujesz rzeczywistą wydajność za pomocą RUM?
- Target: Czy celujesz w nowoczesne przeglądarki (es2022+) zamiast generować polyfille dla starych?
Podsumowanie
Optymalizacja bundli JavaScript w 2026 roku to nie żadna magia — to systematyczny proces analizy, eliminacji zbędnego kodu i inteligentnego ładowania tego, co pozostaje. Nowa generacja bundlerów (Vite 8 z Rolldown, Rspack) radykalnie przyspiesza budowanie i generuje mniejsze paczki, ale narzędzia to tylko połowa równania. Kluczowe jest zrozumienie, dlaczego Twój bundle jest duży i podjęcie konkretnych kroków, żeby to zmienić.
Zacznij od pomiaru. Wygeneruj raport Bundle Analyzer, sprawdź Coverage w DevTools, uruchom Lighthouse. Potem wprowadź quick wins: kompresja Brotli, zamiana ciężkich bibliotek, dodanie defer. Na koniec zajmij się zmianami strukturalnymi: code splitting, eliminacja barrel exports, lazy loading.
A kiedy już to wszystko zrobisz — ustaw budżet wydajnościowy w CI/CD, żeby nigdy więcej nie wrócić do punktu wyjścia. Każdy kilobajt JavaScript, który usuniesz, to szybsza strona, lepsze Core Web Vitals i — ostatecznie — więcej zadowolonych użytkowników. A to w końcu o to chodzi.