Bundle size
Bundle size is the byte weight of the JavaScript (and associated assets) a client must download and parse before an app becomes usable. It is the JS-app-era counterpart to total page-weight: where a static page’s floor is governed by HTML/CSS/SVG, an interactive app’s floor is dominated by its JS bundle plus any runtime libraries it ships. In the measured baseline, JS is 613 KB of the median desktop homepage and the most-requested file type (web-almanac-page-weight-2024) — bundle size is the heavy, growing slice of page weight.
Bundle size matters most at the edge and at startup — CloudFlare workers, serverless functions, CLI/node scripts, CI actions — where download, parse, and cold-start time scale with bytes shipped squint.
Levers on bundle size
- Ship less code you wrote — the hand-authoring approach of landing-page-14kb.
- Ship less runtime — change the compiler/language so the same source emits smaller output. squint does this by compiling to native JS data structures instead of bundling an immutable-collection runtime.
- Tree-shaking / ES modules — emit module-friendly output so bundlers drop unused code (Squint targets ES modules for this reason).
- Enforce a performance-budget — cap the bundle in CI (Lighthouse CI / bundlesize) so size is a gate, not a hope (performance-budgets-101).
These levers govern only first-party JS; much of the median 613 KB is third-party script, a separate problem (third-party-resources).
Relation to Core Web Vitals
Bundle size is a CWV input, not a metric itself: heavy JS inflates LCP and especially INP (parse/execute on the main thread). But per core-web-vitals-seo and the synthesis’s cross-wiki note, bytes are necessary-but-not-sufficient — architecture and delivery shape real-user metrics as much as raw size.