Bundle JS 2026: Optimizare & Ghid INP

Q: Cum optimizez JavaScript-ul de la Google Tag Manager?

Mută GTM în Partytown (web worker) folosind strategy="worker" din next/script sau echivalentul framework-ului tău. Impactul pe firul principal scade cu 90%+ pentru că script-urile injectate rulează în worker, nu în thread-ul de UI. Alternativ, încarcă GTM cu strategy="lazyOnload" după evenimentul load , cu prețul unei mici latențe în tracking.

Actualizat: 13 iulie 2026

Optimizarea bundle-ului JavaScript în 2026 înseamnă livrarea a mai puțin de 170 KB de JavaScript comprimat pe transferul inițial, folosind code splitting bazat pe rute, tree shaking cu module ES stricte și bundlere moderne precum Vite 6, Turbopack sau Rspack 1.5. În experiența mea, majoritatea site-urilor cu Interaction to Next Paint (INP) peste 200ms nu au o problemă de framework, au o problemă de bundle. Aici arăt fluxul complet: profilarea, tăierea, împărțirea și verificarea rezultatului pe firul principal.

Bugetul realist în 2026 pentru JavaScript pe transferul inițial este ≤170 KB comprimat (aproximativ 500 KB necomprimat) pentru rețelele 4G lente pe care Google testează Core Web Vitals.
Code splitting pe rute reduce JavaScript-ul inițial cu 40–70% în majoritatea SPA-urilor React/Vue fără nicio modificare la logica aplicației.
Tree shaking funcționează doar când toate dependențele exportă module ES pure și sideEffects: false este declarat în package.json.
Bundlerele bazate pe Rust (Turbopack, Rspack, Farm) construiesc de 5–20× mai rapid decât Webpack 5, dar analiza bundle-ului final rămâne responsabilitatea ta.
Long tasks peste 200ms pe firul principal sunt cauza principală a INP-ului slab; mută munca non-UI în Web Workers sau Partytown.
Modulele preload și fetchpriority="high" pot livra JavaScript critic cu 300–800ms mai devreme fără a mări bundle-ul.

Care este bugetul de JavaScript în 2026?

Bugetul pe care îl aplic pe fiecare audit este acesta: 170 KB de JavaScript comprimat (Brotli sau gzip) pe transferul inițial, ceea ce corespunde la aproximativ 500 KB necomprimat după parsing. Cifra vine din modelul RAIL actualizat și din laboratorul Google pentru Core Web Vitals, care simulează un dispozitiv de gamă medie (Moto G Power echivalent) pe o rețea 4G lentă cu latență de 150ms. Pe acel dispozitiv, fiecare 100 KB de JavaScript adaugă aproximativ 200–350ms de parsing și compilare V8 înainte ca prima interacțiune să poată răspunde.

În practică, împart bugetul în trei coșuri distincte pe care le urmăresc separat în CI:

Critic (route entry): sub 80 KB comprimat, framework runtime plus shell-ul rutei curente.
Deferred (după idle): sub 60 KB, analytics, chat, feature flags, personalizare.
On-demand (lazy): fără limită strictă per bucată, dar fiecare chunk sub 30 KB pentru a evita long tasks la mount.

De ce contează atât de mult această structură? Pentru că Interaction to Next Paint (INP) este direct legat de câtă muncă face firul principal după eveniment, iar bundle-urile mari înseamnă mai multă compilare, mai mult hydration și, în cele din urmă, taskuri care depășesc pragul de 200ms. Un site cu 300 KB de JavaScript comprimat pe pagina inițială va avea aproape întotdeauna un INP peste pragul "good" al Google.

Cum profilezi un bundle JavaScript

Înainte de a tăia ceva, arăt clientului trace-ul. Fără un plan bazat pe date, ajungi să scoți o dependență de 12 KB în timp ce ignori una de 180 KB. Fluxul meu de profilare are exact patru pași și îl aplic pe orice stack: Next.js, Nuxt, Remix, Astro, SvelteKit.

Primul pas este generarea unui raport de bundle cu statistici JSON. Pentru Webpack și Rspack folosesc webpack-bundle-analyzer, pentru Vite folosesc rollup-plugin-visualizer, iar pentru Turbopack folosesc raportul integrat din next build --profile. Comanda tipică arată așa:

// vite.config.ts
import { defineConfig } from 'vite'
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    visualizer({
      filename: 'dist/stats.html',
      template: 'treemap',      // arată dimensiunile relative
      gzipSize: true,           // afiseaza dimensiunea comprimata reala
      brotliSize: true,         // și Brotli, care contează mai mult în 2026
      open: true,
    }),
  ],
  build: {
    rollupOptions: {
      output: {
        // marchează chunk-urile mari pentru inspecție ușoară
        manualChunks: (id) => {
          if (id.includes('node_modules')) {
            if (id.includes('react')) return 'vendor-react'
            if (id.includes('lodash')) return 'vendor-lodash'
          }
        },
      },
    },
  },
})

Al doilea pas este corelarea cu un trace Chrome DevTools Performance. Deschid Performance panel, activez CPU throttling 4× și rețea "Slow 4G", apoi înregistrez de la about:blank până la onLoad. Ce urmăresc este banda "Main": dacă văd un task de compile V8 mai lung de 100ms, notez ce fișier îl declanșează. Panoul "Coverage" din DevTools (Ctrl+Shift+P, apoi "Show Coverage") îmi spune imediat cât din fiecare bundle este cod mort neexecutat pe pagina curentă.

Pasul trei este source-map-explorer pentru a mapa bundle-ul la fișierele sursă originale. Rulez npx source-map-explorer 'dist/assets/*.js' și primesc un treemap cu numele reale ale fișierelor tale, nu ID-uri obfuscate. Aici descopăr, tipic, că 40 KB dintr-un bundle sunt polyfills pentru browsere pe care nu le mai țintești.

Al patrulea pas este Real User Monitoring. Un bundle care arată bine în laborator poate exploda pe un Android median. Folosesc biblioteca web-vitals cu atribuire (versiunea 5+) pentru a captura numele scriptului care a cauzat cel mai lung task pe pagină, apoi corelez cu numele chunk-ului din raportul de bundle.

Code splitting: rute, componente și dependențe

Code splitting este cea mai rentabilă intervenție pentru a reduce bundle-ul JavaScript inițial. Definiția simplă: împarți bundle-ul mare într-o serie de chunk-uri mai mici încărcate la cerere. În 2026, framework-urile moderne o fac aproape automat pentru rute, dar câștigurile mari vin din splitting-uri manuale în trei locuri.

Splitting pe rute (aproape gratuit)

Fiecare framework major suportă splitting pe rute din cutie: Next.js App Router, Nuxt, Remix, Astro Islands, SvelteKit. Verifică că nu ai importuri statice care pun modulele "pe pagina X" în entry-ul global. Un test rapid: caută în entry-ul principal import { PageContact } from. Dacă găsești, ai un import care leagă toată aplicația împreună.

Splitting pe componente grele

Editoarele rich-text, chart libraries, hărți, code editors, video players: toate acestea nu trebuie livrate pe transferul inițial. Onest, am pierdut o dimineață întreagă anul trecut încercând să diagnostichez un INP prost la o aplicație de tip CMS, doar ca să descopăr că editorul Tiptap se încărca sincron pe fiecare pagină, inclusiv landing page-ul. Le împart cu React.lazy sau echivalentul din framework-ul tău:

// React 19 + Suspense: editor rich-text lazy
import { lazy, Suspense } from 'react'

const RichEditor = lazy(() =>
  import(/* webpackChunkName: "rich-editor" */ './RichEditor')
)

export function ArticleForm() {
  return (
    <Suspense fallback={<textarea placeholder="Se încarcă editorul..." />}>
      <RichEditor />
    </Suspense>
  )
}

// Bonus: prefetch la hover ca UX-ul să pară instant
<button
  onMouseEnter={() => import('./RichEditor')}
  onClick={() => setEditing(true)}
>
  Editează
</button>

Splitting pe dependențe uriașe

Moment.js are 68 KB comprimat. Chart.js are 85 KB. Un import "just in case" dintr-un formular te costă acele KB pe toate paginile. Migrează la alternative moderne: date-fns este tree-shakeable la funcție, iar uPlot este sub 40 KB necomprimat cu API asemănător. Când migrarea nu este posibilă, izolează dependența într-un chunk propriu și încarc-o dinamic.

Tree shaking corect: sideEffects și module ES

Tree shaking elimină exporturile neutilizate din modulele finale. Sună simplu, dar în 2026 mai văd frecvent cazuri în care tree shaking-ul nu funcționează pentru că cineva importă din CommonJS, cineva a uitat să declare "sideEffects": false, sau cineva folosește un pattern de re-export care blochează analiza statică. Verificare rapidă în bundle: dacă găsești în bundle-ul final funcții din lodash pe care nu le-ai importat niciodată, tree shaking-ul e stricat.

Cheia este package.json-ul fiecărei dependențe. Bundlerele moderne (Rollup, esbuild, Turbopack, Rspack) tratează un modul ca "pure" doar dacă:

"type": "module" sau are un câmp "exports" cu chei import.
"sideEffects" este setat la false sau la un array cu fișierele care au side effects (de exemplu, CSS-uri globale).
Nu folosește require(), module.exports sau top-level console.log.

Pentru propriul tău cod, adaugă asta în package.json-ul monorepo-ului sau al pachetului tău:

{
  "name": "@myapp/ui",
  "type": "module",
  "sideEffects": [
    "**/*.css",
    "**/*.scss",
    "./src/polyfills.ts"
  ],
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  }
}

Pentru Material UI, Ant Design sau Chakra, folosește importurile pe cale de subcale (de exemplu import Button from '@mui/material/Button' în loc de import { Button } from '@mui/material') sau pluginul de bundle al fiecărei librării. Diferența poate ajunge la 200 KB comprimat pe un dashboard tipic. Sincer, e primul lucru pe care îl verific atunci când preiau un audit pe o aplicație cu Material UI.

Care este cel mai bun bundler în 2026?

În 2026, alegerea de bundler nu mai este ideologică, este pragmatică. Am migrat destule proiecte încât să pot spune ce funcționează în producție. Tabelul de mai jos rezumă alegerile pe care le-aș recomanda în funcție de context.

Bundler	Viteză build (rel. Webpack 5)	HMR	Ecosistem plugin	Cel mai potrivit pentru
Vite 6	~15× mai rapid	<50ms	Excelent (Rollup)	SPA-uri React/Vue/Svelte, biblioteci
Turbopack (Next 15)	~10× mai rapid	<100ms	Legat de Next.js	Aplicații Next.js la scară mare
Rspack 1.5	~20× mai rapid	<100ms	Compatibil Webpack	Migrări din Webpack fără rescriere
esbuild	~30× mai rapid	N/A (fără HMR)	Minimal	Librării, CLI-uri, servere
Rollup 4	Baseline	Prin Vite	Bogat	Publicare biblioteci NPM
Webpack 5	1×	~500ms	Cel mai matur	Aplicații legacy cu plugin-uri custom

Recomandarea mea directă pentru un proiect nou în 2026: Vite 6 pentru orice SPA, Turbopack dacă ești pe Next.js 15+, și Rspack dacă migrezi dintr-un proiect Webpack monorepo mare. Toate trei produc output aproape identic în ceea ce privește dimensiunea finală; diferența este în timp de build și DX. Detaliile complete de configurare le găsești în documentația oficială Vite pentru production build.

Cum reduci impactul scripturilor terțe

Scripturile terțe (Google Tag Manager, chat widgets, A/B testing, personalizare) sunt frecvent cauza numărul unu a INP-ului slab, chiar când bundle-ul propriu este mic. Fiecare din ele adaugă între 30 și 250 KB de JavaScript executat pe firul principal al tău. Le tratez în trei categorii cu strategii diferite.

Scripturi complet delayable (analytics, heatmaps, feedback widgets): le mut în Partytown, care le execută într-un web worker izolat. Impactul pe firul principal ajunge aproape zero. Setup-ul cu Next.js este:

// next.config.js
module.exports = {
  experimental: {
    nextScriptWorkers: true, // activează Partytown
  },
}

// _app.tsx sau layout.tsx
import Script from 'next/script'

<Script
  strategy="worker"          // rulează în Partytown, nu pe main thread
  src="https://www.googletagmanager.com/gtag/js?id=G-XXX"
/>

Scripturi condiționate de consent (marketing pixels, remarketing): le încarc doar după ce utilizatorul acceptă cookie-uri. Cu next/script folosesc strategy="lazyOnload" combinat cu un guard de state.

Scripturi critice pentru UX (chat live pentru suport, checkout SDK): le încarc pe interacțiune. Un buton "Chat cu noi" nu trebuie să importe SDK-ul de la început; îl importă la onClick. Pentru chat, un stub HTML/CSS local imită button-ul și declanșează încărcarea reală doar la click, ceea ce economisește tipic 150 KB pe transferul inițial.

Compresie și livrare: Brotli, Zstd și modulepreload

Chiar cu bundle-ul redus la minimum, livrarea contează. În 2026, Brotli este universal suportat, iar Zstd (Content-Encoding: zstd) a devenit disponibil în Chrome, Edge și Firefox. Comparativ cu gzip, Brotli comprimă JavaScript cu 15–25% mai bine, iar Zstd decomprimă cu 30% mai puțină muncă CPU pe firul principal, util pentru dispozitive slabe.

Configurare Nginx tipică pentru servire dublă (Brotli plus Zstd plus gzip fallback):

# /etc/nginx/nginx.conf
brotli on;
brotli_comp_level 5;      # 4-6 e sweet spot; 11 durează prea mult
brotli_types application/javascript application/json text/css;

zstd on;
zstd_comp_level 6;
zstd_types application/javascript application/json text/css;

gzip on;
gzip_types application/javascript application/json text/css;

# precomprimare on-disk, servește direct fișierele .br și .zst dacă există
brotli_static on;
zstd_static on;
gzip_static on;

Pentru a livra JavaScript-ul critic cu 300–800ms mai devreme, folosesc <link rel="modulepreload"> cu fetchpriority="high". Diferența față de <link rel="preload"> este că modulepreload pre-parsează și pre-compilează modulul, nu doar îl descarcă:

<!-- În <head>, înainte de restul bundle-ului -->
<link rel="modulepreload" href="/assets/app-entry.js" fetchpriority="high">
<link rel="modulepreload" href="/assets/vendor-react.js" fetchpriority="high">

<!-- Chunk-urile mai puțin critice pot merge cu prioritate normală -->
<link rel="modulepreload" href="/assets/route-dashboard.js">

Combinat cu tehnicile din ghidul meu despre optimizarea TTFB sub 200ms, această configurație asigură că JavaScript-ul ajunge la parser înainte ca browser-ul să ceară el însuși modulul.

Cum elimini long tasks-urile de pe firul principal

Un "long task" este orice bucată de muncă JavaScript care ține firul principal ocupat mai mult de 50ms. Cauza cea mai comună în 2026 este hydration React sincron pe componente mari sau parsing JSON de configurație. Există trei tehnici practice pe care le folosesc constant.

Yield to main: în locurile în care ai o buclă mare care procesează date, folosește scheduler.yield() (Chrome 129+) sau await new Promise(r => setTimeout(r, 0)) pentru a permite browser-ului să răspundă la input între iterații:

async function processLargeList(items) {
  const CHUNK = 50
  for (let i = 0; i < items.length; i += CHUNK) {
    const slice = items.slice(i, i + CHUNK)
    slice.forEach(processItem)

    // dă firului principal șansa să răspundă la click/scroll
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield()
    } else {
      await new Promise((r) => setTimeout(r, 0))
    }
  }
}

Web Workers pentru munca CPU-intensivă: parsing markdown, transformări de imagini, criptografie, procesare de fișiere CSV, toate acestea aparțin unui worker. Cu comlink sau partytown, API-ul devine aproape identic cu un import obișnuit.

Selective hydration și React Server Components: în Next.js 15 și Remix, marchează componentele care nu au interactivitate ca server, ele nu vor avea JavaScript trimis clientului deloc. O pagină de produs cu 30 KB de logică poate ajunge la 5 KB doar prin identificarea corectă a graniței client/server. Documentația oficială React pentru Server Components explică fluxul de decizie.

Verificarea rezultatelor cu Lighthouse și WebPageTest

Optimizarea fără verificare este optimizare imaginară. După fiecare rundă de tăiere, rulez trei verificări în această ordine.

Lighthouse CI în pipeline, cu assertions pe bugetul de bundle:

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['https://staging.example.com/'],
      numberOfRuns: 5,
    },
    assert: {
      assertions: {
        'total-byte-weight': ['error', { maxNumericValue: 1_600_000 }],
        'unused-javascript': ['warn', { maxNumericValue: 40_000 }],
        'bootup-time': ['error', { maxNumericValue: 2000 }],
        'mainthread-work-breakdown': ['warn', { maxNumericValue: 3000 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'interaction-to-next-paint': ['error', { maxNumericValue: 200 }],
      },
    },
  },
}

WebPageTest cu profil "Mobile: Moto G Power, 4G Slow" pentru cifre repetabile și un waterfall detaliat. Ce urmăresc este "JavaScript Execution Time" din tab-ul Details. Dacă depășește 1500ms pe emulare mobilă, mai am muncă de făcut.

Real User Monitoring cu web-vitals versiunea 5 și atribuire. Un exemplu tipic de raport la care ajung după optimizare arată așa: LCP p75 sub 2.0s, INP p75 sub 150ms, CLS p75 sub 0.05, cu bundle inițial de 145 KB Brotli. Verificările sunt aceleași metrici despre care am scris în ghidurile mele pentru optimizarea LCP sub 2.5s. Bundle-ul JavaScript este pârghia care le influențează pe toate simultan.

Întrebări frecvente

Ce dimensiune ar trebui să aibă un bundle JavaScript în 2026?

Bugetul practic pentru transferul inițial este de 170 KB comprimat cu Brotli, adică aproximativ 500 KB necomprimat. Peste această limită, Interaction to Next Paint și Largest Contentful Paint se degradează măsurabil pe dispozitive Android median pe rețele 4G lente, dispozitivele pe care Google testează Core Web Vitals.

Care este diferența dintre code splitting și tree shaking?

Code splitting împarte codul în mai multe fișiere încărcate la momente diferite (rută, componentă, cerere utilizator). Tree shaking elimină codul neutilizat din interiorul fiecărui fișier. Ambele reduc dimensiunea totală transferată, dar rezolvă probleme diferite: code splitting reduce ce ajunge la client acum, tree shaking reduce ce ajunge la client vreodată.

De ce nu funcționează tree shaking pentru dependența mea?

Cele mai comune cauze sunt: dependența publică cod CommonJS (fără "type": "module"), lipsește "sideEffects": false în package.json, importuri de tip barrel (import { X } from 'pkg' în loc de import X from 'pkg/x'), sau bundlerul rulează în mod dezvoltare fără minificare. Verifică cu bundle analyzer ce funcții exacte ajung în output.

Cum optimizez JavaScript-ul de la Google Tag Manager?

Mută GTM în Partytown (web worker) folosind strategy="worker" din next/script sau echivalentul framework-ului tău. Impactul pe firul principal scade cu 90%+ pentru că script-urile injectate rulează în worker, nu în thread-ul de UI. Alternativ, încarcă GTM cu strategy="lazyOnload" după evenimentul load, cu prețul unei mici latențe în tracking.

Merită să folosesc Turbopack în producție?

Da, dacă ești pe Next.js 15+ și folosești App Router, Turbopack este stabil pentru next build și oferă build-uri de 10× mai rapide decât Webpack 5. Verifică totuși că plugin-urile Webpack pe care le folosești au echivalent. MDX cu plugin-uri custom și loader-e binare pot cere migrări.