Bundle size optimization is the practice of reducing the total amount of JavaScript and CSS a website ships to the browser. Smaller bundles download faster, parse faster, and execute faster, which improves Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint. The result is quicker pages, better rankings, and higher conversions. You shrink bundles by removing unused code, splitting what remains, and replacing heavy dependencies.
What Bundle Size Means
A bundle is the packaged output of a site’s source code, the combined JavaScript and CSS the browser downloads to make a page work. As projects grow, bundles accumulate weight from added features, third-party libraries, polyfills, and code that no page actually uses. Every kilobyte has a cost paid twice: once to download over the network and again to parse and execute on the main thread, which is the more expensive half on mid-range mobile devices.
Bundle size is not just about file size on disk. The compressed transfer size determines download time, but the uncompressed size determines how long the browser spends parsing and compiling. A 200 KB compressed bundle can expand to 800 KB of code the CPU must process, which is why JavaScript-heavy sites feel sluggish even on fast connections.
Why Bundle Size Affects Rankings and Conversions
Large bundles delay interactivity. While the browser parses and executes JavaScript, the main thread is blocked, which inflates Interaction to Next Paint and can delay the Largest Contentful Paint element if rendering waits on hydration. Both metrics feed Google’s Core Web Vitals assessment, and poor scores suppress rankings on the mobile results that drive most traffic. Our guide on Interaction to Next Paint explains how main-thread work translates into the responsiveness Google measures.
The conversion cost is direct and well documented. Heavier bundles mean slower pages, and slower pages mean fewer completed signups, purchases, and lead forms. On mobile, where processing power varies widely, an oversized bundle punishes the exact audience that is hardest to convert. Trimming bundle weight is one of the most reliable ways to lift both rankings and revenue, and it pairs naturally with the broader tactics in our website speed optimization guide.
The Mobile Penalty
A bundle that loads acceptably on a developer’s laptop can stall on a budget Android phone. JavaScript parsing scales with CPU speed, so the same code costs several times more on low-end hardware. Optimizing for the median device, not the developer’s machine, is what separates a fast site from one that only feels fast in the office.
How to Diagnose Bundle Size Problems
- Lighthouse: Look for “Reduce unused JavaScript,” “Reduce unused CSS,” “Minify JavaScript,” and “Avoid enormous network payloads.” Each estimates the savings available.
- PageSpeed Insights: Confirms total transfer size and flags oversized payloads against field data from real visitors.
- Bundle analyzer: A visual analyzer produces a treemap of every module in your bundle, ranked by size. This is the fastest way to spot a single dependency eating a quarter of your payload.
- Coverage tab: Chrome DevTools shows the percentage of each file’s code that runs on load. High unused percentages mark code that should be split out or removed.
What Good Looks Like
For a marketing or content site, aim to keep initial JavaScript under roughly 150 to 200 KB compressed. Application-heavy interfaces will run higher, but any single dependency contributing more than 50 KB deserves scrutiny. Use these numbers as targets, then verify the real impact in field data rather than chasing a lab score.
Concrete Fixes for Bundle Size
1. Tree-Shake Unused Code
Tree shaking removes exports you never import. It only works when you import granularly, so import named functions rather than entire modules. Replacing a wildcard import with specific named imports can drop tens of kilobytes from a single library.
2. Replace Heavy Dependencies
Audit your largest dependencies and ask whether each earns its weight. A full date library imported for one formatting call, a charting suite used for a single graph, or a utility library where native JavaScript would do are all common offenders. Swap them for lighter alternatives or native APIs.
3. Split the Bundle
Code splitting keeps the initial bundle small by loading code on demand. Split by route so each page ships only its own code, and lazy-load heavy components like editors and media players until they are needed. This complements bundle reduction by changing when code loads, not just how much exists. Our guide to lazy loading covers the same principle applied to media.
4. Minify and Compress
Minify JavaScript and CSS to strip whitespace, comments, and dead code, then serve everything with Brotli compression. Minification and compression together routinely cut transfer size by sixty percent or more with no functional change.
5. Defer Third-Party Scripts
Third-party scripts often outweigh your own code. Tag managers, chat widgets, and tracking pixels should load after the page is interactive, and unused vendors should be removed entirely. Every third-party script is a dependency you do not fully control, so prune aggressively.
Bundle Optimization Checklist
- Run a bundle analyzer and identify the top five heaviest modules
- Tree-shake by importing named functions, not whole libraries
- Replace any dependency over 50 KB with a lighter alternative where possible
- Split by route and lazy-load heavy components
- Minify and serve with Brotli compression
- Audit and defer or remove third-party scripts
- Re-test in PageSpeed Insights and compare field data
How Modern Stacks Handle Bundle Size
Next.js
Next.js does a lot of this automatically. It tree-shakes by default, splits bundles per route, minifies production builds, and supports dynamic imports for component-level splitting. Server components push rendering to the server so less JavaScript ships to the browser at all, and the built-in bundle analyzer makes it easy to spot regressions before they reach production.
Framer
Framer manages bundle size at the platform level so you never configure a build pipeline. The platform splits code per page, minifies and compresses output, optimizes images and fonts, and serves everything from a global CDN. Because you build visually on a maintained engine rather than assembling dependencies yourself, the runaway bundle growth that plagues hand-built React and WordPress sites simply does not accumulate. This is one of the core reasons we build exclusively on the platform: clients get lean, fast sites without an ongoing performance budget to police.
| Optimization | WordPress / hand-built React | Framer |
|---|---|---|
| Tree shaking | Depends on build config | Handled by platform |
| Code splitting | Manual or plugin | Automatic per page |
| Minify and compress | Manual setup | Built in |
| Third-party bloat | Common via plugins | Minimal by design |
A Practical Workflow for Shrinking a Bundle
Most teams come to bundle optimization with a build that has grown heavy over years of added features. Attacking it in the right order produces the biggest wins fastest and keeps the work from feeling endless. Here is the sequence we follow.
Start with a baseline and a map. Record current transfer size and Core Web Vitals from PageSpeed Insights, then run a bundle analyzer to generate a treemap of every module by size. The treemap almost always reveals a few surprises, a heavy library imported for one helper function, a duplicate dependency pulled in twice at different versions, or a polyfill bundle nobody in your audience needs.
Attack the largest single contributors first. One oversized dependency often outweighs a dozen small optimizations, so replacing or removing it delivers more than hours of micro-tuning. Ask of each heavy module whether the feature it provides justifies its weight, and whether a lighter alternative or a native browser API would do the same job.
Next, fix your imports. Switch wildcard and whole-library imports to named imports so tree shaking can drop the unused exports. This is a low-risk change that frequently removes tens of kilobytes from a single library without altering behavior at all.
Then split what remains. Once the bundle is as lean as it can be, code splitting changes when the rest loads. Split by route so each page ships only its own code, and lazy-load heavy components until they are needed. This is the bridge between reducing total code and reducing the code on the critical path. The same on-demand principle applied to media is covered in our image optimization guide.
Finally, audit third parties and re-measure. Third-party scripts often rival your own code in weight and sit outside your direct control, so remove unused vendors and defer the rest. Then re-test against your baseline and confirm the field data improved, since a smaller lab payload only matters if real visitors on real devices feel the difference.
Bundle size is one of the few performance levers that affects download time, parse time, and interactivity all at once, which makes it worth ongoing attention. If you would rather build on a platform that keeps bundles lean automatically, see our recent projects or start a conversation through our contact page.
Frequently Asked Questions
What is a good bundle size for a website?
For a marketing or content site, aim to keep initial JavaScript under roughly 150 to 200 KB compressed. Application-heavy interfaces will be larger, but any single dependency contributing more than 50 KB to the bundle deserves a close look. Treat these as targets and confirm the real impact in field data rather than optimizing for a lab number alone.
Does bundle size affect SEO?
Yes, indirectly but meaningfully. Large bundles slow down rendering and interactivity, which worsens Core Web Vitals like Largest Contentful Paint and Interaction to Next Paint. Since those metrics are ranking signals and a slow mobile experience suppresses visibility, reducing bundle size improves both performance and search rankings.
How does Framer keep bundle size small?
Framer handles tree shaking, per-page code splitting, minification, compression, and asset optimization at the platform level, and serves everything from a global CDN. Because you build on a maintained engine instead of assembling dependencies yourself, the bundle bloat common to hand-built and plugin-heavy sites does not accumulate.