Why Your JavaScript Bundle Is Probably Too Big
Here's a number that should make every web developer squirm a little: the median JavaScript payload on mobile websites now exceeds 500 KB compressed. On desktop, it's even worse. And that number keeps climbing year over year — despite faster networks, better tooling, and an industry that won't stop talking about performance.
The thing is, developers aren't being careless. Modern web applications are genuinely complex. Between framework runtime code, UI component libraries, state management, form validation, date formatting, charting, analytics, and the dozen other dependencies a typical project accumulates, bundle sizes balloon quietly. By the time someone notices the Lighthouse score has dropped, the bundle has grown by 200 KB and nobody can point to a single culprit.
But the performance cost is real — and measurable. According to HTTP Archive data from late 2025, reducing JavaScript execution time improves Largest Contentful Paint by up to 30 percent. Each 100 milliseconds added to LCP correlates with a 1 to 3 percent decrease in conversions. Sites that pass all Core Web Vitals thresholds rank 28 percent higher on Google search results pages, and only 56.3 percent of websites currently meet all three thresholds.
JavaScript bundle size is one of the biggest levers you can pull. Honestly, it might be the single biggest.
This guide walks you through every meaningful technique for reducing JavaScript bundle size in 2026 — from fundamentals like code splitting and tree shaking, through modern tooling like Vite 6 and Module Federation 2.0, to advanced patterns like islands architecture and performance budgets in CI. These aren't theoretical suggestions. They're battle-tested approaches backed by data and real-world results.
Measuring Before You Optimize: Bundle Analysis Tools
You can't optimize what you can't measure. Before changing a single line of code, you need to understand exactly what's in your bundle, how big each piece is, and which dependencies are contributing the most weight.
Skipping this step leads to guessing — and guessing leads to wasted effort optimizing the wrong things.
Webpack Bundle Analyzer
If your project uses Webpack, the webpack-bundle-analyzer plugin generates an interactive treemap visualization of your bundle contents. Install it and add it to your Webpack configuration:
npm install --save-dev webpack-bundle-analyzer// webpack.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: 'static',
reportFilename: 'bundle-report.html',
openAnalyzer: false,
}),
],
};Run your production build and open the generated HTML report. The treemap shows every module in your bundle, sized proportionally to its contribution. You'll almost always find surprises — a utility library pulling in far more code than expected, a locale file you never use, or a polyfill for a feature every modern browser already supports.
Rollup Plugin Visualizer for Vite
If you're using Vite (and in 2026, you probably should be), the rollup-plugin-visualizer serves the same purpose:
npm install --save-dev rollup-plugin-visualizer// vite.config.js
import { defineConfig } from 'vite';
import { visualizer } from 'rollup-plugin-visualizer';
export default defineConfig({
plugins: [
visualizer({
filename: 'stats.html',
gzipSize: true,
brotliSize: true,
}),
],
});The gzipSize and brotliSize options are important because they show you the actual transfer size, not just the raw file size. A 300 KB raw JavaScript file might compress to 80 KB with Brotli — and transfer size is what actually affects load time.
Source Map Explorer
For a more granular view, source-map-explorer analyzes your source maps to show exactly which source files contribute to each byte of your bundle. This is especially useful for tracing bloat back to specific application code rather than just identifying heavy dependencies:
npx source-map-explorer dist/assets/index-*.jsSetting a Baseline
Once you've got your analysis tools in place, record your baseline metrics. Document the total bundle size (both raw and compressed), the sizes of your largest chunks, and the weight of your top ten dependencies. You need these numbers to measure the impact of every optimization you apply going forward.
Code Splitting: Load Only What You Need
Code splitting is the single most impactful optimization technique for large JavaScript applications. Instead of shipping one monolithic bundle that contains everything your application could ever need, code splitting breaks your code into smaller chunks that load on demand. Users only download the JavaScript required for the page they're viewing and the features they're actually using.
Route-Based Code Splitting
The most natural splitting boundary is at the route level. Each page in your application becomes its own chunk, loaded when the user navigates to it. In React with React Router, this looks like:
import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';
const Home = lazy(() => import('./pages/Home'));
const ProductList = lazy(() => import('./pages/ProductList'));
const ProductDetail = lazy(() => import('./pages/ProductDetail'));
const Checkout = lazy(() => import('./pages/Checkout'));
const Account = lazy(() => import('./pages/Account'));
function App() {
return (
<Suspense fallback={<PageSkeleton />}>
<Routes>
<Route path="/" element={<Home />} />
<Route path="/products" element={<ProductList />} />
<Route path="/products/:id" element={<ProductDetail />} />
<Route path="/checkout" element={<Checkout />} />
<Route path="/account" element={<Account />} />
</Routes>
</Suspense>
);
}Each lazy() call creates a separate chunk. When the user lands on the homepage, they only download the Home chunk plus the shared framework code. The Checkout code stays on the server until the user actually navigates to checkout. For an e-commerce site with dozens of pages, this can reduce the initial bundle by 60 to 80 percent.
That's a huge win for essentially five lines of code.
Component-Level Code Splitting
Route splitting is the low-hanging fruit, but component-level splitting takes things further. Heavy components that aren't immediately visible — modals, dropdown menus, data tables with complex filtering, rich text editors, chart libraries — should all be split into their own chunks:
import { lazy, Suspense, useState } from 'react';
const RichTextEditor = lazy(() => import('./components/RichTextEditor'));
function CommentForm() {
const [showEditor, setShowEditor] = useState(false);
return (
<div>
{showEditor ? (
<Suspense fallback={<EditorSkeleton />}>
<RichTextEditor />
</Suspense>
) : (
<button onClick={() => setShowEditor(true)}>
Write a detailed comment
</button>
)}
</div>
);
}A rich text editor can easily weigh 150 KB or more. By splitting it, the 95 percent of users who never click "Write a detailed comment" never download that code at all. It's one of those optimizations that feels almost too simple to be effective — but it really works.
Dynamic Imports for Conditional Features
Beyond React components, you can use dynamic import() anywhere in your code to defer loading heavy libraries until they're actually needed:
async function generatePDFReport(data) {
// Only load the PDF library when the user requests a PDF
const { jsPDF } = await import('jspdf');
const doc = new jsPDF();
doc.text(data.title, 10, 10);
// ... build the PDF
doc.save('report.pdf');
}
async function renderChart(container, chartData) {
// Load the charting library on demand
const { Chart } = await import('chart.js/auto');
new Chart(container, {
type: 'bar',
data: chartData,
});
}This pattern is framework-agnostic and works with any bundler that supports dynamic imports — which, in 2026, is all of them.
Tree Shaking: Eliminating Dead Code Automatically
Tree shaking is the process by which your bundler analyzes your import statements and removes any exported code that's never actually used. The term comes from the mental image of shaking a tree and letting the dead leaves fall off. When it works well, it's kind of magical — you import one function from a large utility library and only that function ends up in your bundle.
How Tree Shaking Works
Tree shaking depends on static analysis of ES module import and export statements. This is why it only works with import and export syntax — not with require() and module.exports. CommonJS modules are dynamic by nature, and the bundler can't determine at build time which exports are actually used.
// This CAN be tree-shaken:
import { debounce } from 'lodash-es';
// This CANNOT be tree-shaken:
const { debounce } = require('lodash');The difference is dramatic. Importing debounce from the ES module version of Lodash adds roughly 1 KB to your bundle. Requiring it from the CommonJS version pulls in the entire 70 KB library. Same function, wildly different cost.
Ensuring Tree Shaking Actually Works
Here's the frustrating part: tree shaking can silently fail for several reasons. The most common culprits are side effects in module initialization, barrel files that re-export everything, and libraries that don't ship proper ES module builds.
Side effects are the trickiest issue. If a module executes code at the top level when it's imported — registering a global, modifying a prototype, calling a function — the bundler can't safely remove it, even if you don't use any of its exports. The sideEffects field in package.json tells the bundler which files are safe to eliminate:
{
"name": "my-library",
"sideEffects": false
}Or, if only specific files have side effects:
{
"sideEffects": ["./src/polyfills.js", "*.css"]
}Avoiding Barrel File Bloat
Barrel files — those index.js files that re-export everything from a directory — are a surprisingly common source of bundle bloat. When you import one component from a barrel file, some bundlers and configurations pull in all the other exports too, because the barrel file gets treated as having side effects:
// components/index.js (barrel file)
export { Button } from './Button';
export { Modal } from './Modal';
export { DataTable } from './DataTable';
export { RichTextEditor } from './RichTextEditor';
// In your app — you only want Button, but you might get everything
import { Button } from './components';The fix is simple: import directly from the source file instead of through the barrel:
import { Button } from './components/Button';Some bundlers handle barrel files intelligently, but the safest approach is always to import directly — especially for large component libraries. I've personally seen this single change shave 40+ KB off a production bundle.
Vendor Splitting and Long-Term Caching
Your application code changes frequently. Your dependencies change rarely. If they're all in the same bundle, users have to re-download everything — including unchanged vendor code — every time you deploy. Vendor splitting solves this by separating third-party code into its own chunk with a content-hash filename. When only your application code changes, the vendor chunk stays in the browser cache.
Configuring Vendor Splitting in Webpack
// webpack.config.js
module.exports = {
optimization: {
splitChunks: {
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
chunks: 'all',
priority: 10,
},
// Separate large libraries into their own chunks
react: {
test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
name: 'react-vendor',
chunks: 'all',
priority: 20,
},
charts: {
test: /[\\/]node_modules[\\/](chart\.js|d3)[\\/]/,
name: 'charts-vendor',
chunks: 'all',
priority: 20,
},
},
},
},
};The priority values matter here. The more specific groups (react, charts) have higher priority, so they take precedence over the general vendor group. This gives you fine-grained control over caching — React changes less often than your other dependencies, so it gets its own highly cacheable chunk.
Configuring Vendor Splitting in Vite
Vite uses Rollup under the hood and provides the manualChunks option for custom splitting logic:
// vite.config.js
import { defineConfig } from 'vite';
export default defineConfig({
build: {
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes('node_modules')) {
// Group React ecosystem into one chunk
if (id.includes('react') || id.includes('react-dom')) {
return 'react-vendor';
}
// Group all other vendor code
return 'vendor';
}
},
},
},
},
});Combined with content-hash filenames (which Vite enables by default), this strategy ensures returning users only download the chunks that have actually changed. On sites with frequent deployments, this can reduce the effective transfer size for returning visitors by 70 percent or more.
Modern Bundlers: Why Vite 6 Changes the Game
The JavaScript bundler landscape has shifted dramatically. Webpack dominated for years, but Vite has emerged as the default choice for new projects in 2026 — and for good reason. Vite 6, released in late 2024 and refined through 2025, delivers genuinely faster builds, smaller output, and a better developer experience.
What Makes Vite 6 Faster
Vite's architecture is fundamentally different from Webpack's. In development, Vite serves modules natively using the browser's ES module support, so there's no bundling step at all. When you change a file, Vite only needs to invalidate and re-serve that single module — not rebuild an entire dependency graph. Hot Module Replacement happens in under 50 milliseconds regardless of project size.
For production builds, Vite uses Rollup (battle-tested for generating optimized output) combined with esbuild for dependency pre-bundling. The result is builds that are typically 50 to 70 percent faster than equivalent Webpack configurations, with smaller output sizes to boot. Benchmarks from 2026 show Vite producing an average production bundle of 130 KB versus 150 KB from Webpack for comparable applications.
The Environment API
Vite 6's most significant new feature is the Environment API, which lets you bundle for multiple target environments simultaneously — browser, Node.js SSR, edge workers, and custom runtimes. Previous versions required separate configurations for client and server builds. The Environment API unifies this into a single pipeline, cutting both build time and configuration complexity.
Baseline Browser Targeting
Vite 6 defaults to targeting baseline-widely-available, which corresponds to browsers with broad adoption as of early 2025 (Chrome 107+, Edge 107+, Firefox 104+, Safari 16+). This means Vite doesn't inject unnecessary polyfills or syntax transforms for features these browsers already support natively — resulting in leaner, more modern output.
If your analytics show that legacy browser traffic is negligible, you can target esnext for even smaller bundles.
Looking Ahead: Vite+ and the Rust Toolchain
In October 2025, the Vite team announced Vite+, an extended toolchain built on a Rust-based compiler. Vite+ aims to unify linting, formatting, testing, and building into a single cohesive tool with dramatically faster performance. While still in early preview as of February 2026, it represents the next evolution of JavaScript tooling and is definitely worth keeping an eye on.
Removing Unnecessary Polyfills and Legacy Code
In 2026, modern browsers support ES2020+ features natively — optional chaining, nullish coalescing, Promise.allSettled, dynamic imports, BigInt, the list goes on. Yet many projects still ship polyfills for these features because their build configuration was set up years ago and never updated.
It's surprisingly common. And it's free performance sitting on the table.
Auditing Your Polyfill Usage
Check your browserslist configuration and your bundler's target settings. If you're still targeting Internet Explorer or browsers from 2018, you're probably shipping tens of kilobytes of unnecessary polyfills:
// .browserslistrc — a modern, performance-focused configuration
last 2 Chrome versions
last 2 Firefox versions
last 2 Safari versions
last 2 Edge versions
not deadCompare this to the defaults many projects inherit, which often include browsers with less than 0.5 percent market share. Tightening your browser targets can eliminate 20 to 50 KB of polyfill code.
Differential Serving
If you genuinely need to support older browsers for a subset of your users, differential serving lets you ship modern code to modern browsers and legacy code (with polyfills) only to browsers that need it:
<!-- Modern browsers get the lean ES module bundle -->
<script type="module" src="/js/app.modern.js"></script>
<!-- Legacy browsers get the polyfilled bundle -->
<script nomodule src="/js/app.legacy.js"></script>Modern browsers understand type="module" and ignore the nomodule script. Legacy browsers do the opposite. The 95+ percent of your users on modern browsers get the smaller, faster bundle, and the shrinking minority on older browsers still get a working experience. Everyone wins.
Dependency Auditing: Finding and Replacing Heavy Libraries
Not all npm packages are created equal. Some libraries are well-optimized, tree-shakeable, and modular. Others ship their entire codebase regardless of what you import. A critical part of bundle optimization is auditing your dependencies and replacing the heavy ones with lighter alternatives.
Common Swaps That Save Significant Weight
Here are some of the most impactful dependency replacements, based on real-world bundle analysis:
- Moment.js (330 KB) → date-fns (tree-shakeable, 2-10 KB per function used) or Temporal API (native, zero KB). Moment.js includes every locale by default and can't be tree-shaken. This single replacement often saves 200+ KB. If you haven't made this swap yet, it should probably be your first move.
- Lodash (70 KB full) → lodash-es (tree-shakeable) or native JavaScript. Many Lodash functions have native equivalents in ES2020+.
Array.prototype.flat(),Object.entries(),structuredClone(), and optional chaining replace a significant portion of what Lodash offers. - Axios (13 KB) → native fetch API (zero KB). The Fetch API is supported in all modern browsers and Node.js 18+. Unless you need request interceptors or automatic retry logic, native fetch is sufficient.
- UUID (12 KB) → crypto.randomUUID() (native, zero KB). The
crypto.randomUUID()method is supported in all modern browsers and generates RFC 4122 v4 UUIDs natively.
Using bundlephobia and packagephobia
Before adding any new dependency, check its size on bundlephobia.com. The site shows you the minified size, gzipped size, download time on slow networks, and whether the package supports tree shaking. Make this a standard part of your code review process — every dependency should justify its weight.
Module Federation 2.0 for Micro Frontends
For large-scale applications built by multiple teams, Module Federation 2.0 introduces powerful bundle optimization capabilities that work at the architectural level. The core idea is that independently deployed micro frontends can share dependencies at runtime, eliminating the duplication that would otherwise happen when each micro frontend bundles its own copy of React, a component library, or other shared code.
Shared Dependency Tree Shaking
The most significant bundle optimization in Module Federation 2.0 is tree shaking for shared dependencies. In previous versions, when multiple micro frontends shared a library like Ant Design, the entire library was bundled as a shared package — even if each micro frontend only used a handful of components. Module Federation 2.0 analyzes which exports are actually consumed and only loads those.
The numbers are impressive. For Ant Design, when an application uses only Badge, Button, and List components, the shared bundle drops from 1,404 KB to 344 KB — a 75.5 percent reduction. For large enterprises running dozens of micro frontends, this adds up to megabytes of savings across the system.
Server-Calculated Optimal Sharing
Module Federation 2.0 also introduces a server-calc mode where a server or CI system analyzes dependency usage across all micro frontends and computes a globally optimal sharing strategy. Rather than each micro frontend making local decisions about what to share, the system produces a plan that minimizes total bundle size across the entire platform. A visual analysis dashboard makes it easy to understand and verify the sharing decisions.
Islands Architecture and Partial Hydration
Traditional Single Page Applications hydrate the entire page on the client, even for sections that are completely static. Islands architecture flips this model: the page is mostly server-rendered HTML with isolated "islands" of interactivity that hydrate independently. Only the interactive islands ship JavaScript to the client.
If that sounds too good to be true — it's not.
Astro: Islands Architecture in Practice
Astro is the most mature implementation of islands architecture. By default, Astro components ship zero JavaScript to the client. You opt into client-side JavaScript explicitly using hydration directives:
---
// src/pages/product.astro
import Header from '../components/Header.astro';
import ProductGallery from '../components/ProductGallery.jsx';
import ProductReviews from '../components/ProductReviews.jsx';
import Footer from '../components/Footer.astro';
---
<!-- Header is static HTML — zero JS -->
<Header />
<!-- Gallery needs interactivity immediately -->
<ProductGallery client:load />
<!-- Reviews are below the fold — hydrate when visible -->
<ProductReviews client:visible />
<!-- Footer is static HTML — zero JS -->
<Footer />The client:load directive hydrates the component as soon as the page loads. The client:visible directive defers hydration until the component enters the viewport. The client:idle directive waits until the browser is idle. And components without any client: directive ship no JavaScript at all.
For content-heavy sites — blogs, documentation, marketing pages, e-commerce product pages — islands architecture can reduce client-side JavaScript by 80 to 95 percent compared to a traditional SPA approach. That's not a typo. It really is that dramatic.
Performance Budgets: Preventing Bundle Regression
All the optimization in the world is worthless if the bundle grows back to its original size three months later. (Ask me how I know.) Performance budgets are automated guardrails that prevent regression by failing the build or flagging a warning when bundle size exceeds a defined threshold.
Setting Up Performance Budgets in Webpack
// webpack.config.js
module.exports = {
performance: {
maxAssetSize: 250000, // 250 KB per asset
maxEntrypointSize: 400000, // 400 KB per entry point
hints: 'error', // Fail the build if exceeded
},
};Setting Up Performance Budgets in Vite
Vite doesn't have built-in performance budgets, but you can add them with a custom plugin:
// vite.config.js
function bundleSizeGuard(maxSizeKB) {
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 > maxSizeKB) {
console.warn(
`⚠️ ${fileName} is ${sizeKB.toFixed(1)} KB ` +
`(budget: ${maxSizeKB} KB)`
);
}
}
}
},
};
}
export default defineConfig({
plugins: [bundleSizeGuard(250)],
});CI/CD Integration
The most effective place to enforce performance budgets is in your CI pipeline. Tools like bundlesize and size-limit integrate with GitHub and will comment on pull requests when a change pushes bundle size beyond the allowed threshold:
// package.json
{
"size-limit": [
{
"path": "dist/assets/index-*.js",
"limit": "200 KB",
"gzip": true
},
{
"path": "dist/assets/vendor-*.js",
"limit": "150 KB",
"gzip": true
}
],
"scripts": {
"size": "size-limit",
"size:check": "size-limit --json"
}
}Run npx size-limit in your CI pipeline after every build. If someone adds a heavy dependency or accidentally imports an entire library, the pipeline catches it before the code reaches production. This is the single most important thing you can do to maintain bundle size over time — because without automation, budgets are just good intentions.
Advanced Techniques: Going Further
Prefetching Split Chunks
Code splitting reduces initial load time, but it can introduce latency when the user navigates to a new route. Prefetching eliminates this by loading chunks in the background during idle time:
// Webpack magic comment for prefetching
const ProductDetail = lazy(() =>
import(/* webpackPrefetch: true */ './pages/ProductDetail')
);
// Vite: use the Speculation Rules API for route prefetching
// (covered in depth in our Speculation Rules API article)The webpackPrefetch: true comment tells Webpack to inject a <link rel="prefetch"> tag for the chunk after the main bundle has loaded. The browser downloads it at low priority during idle time, so when the user eventually navigates to that route, the chunk is already cached and ready to go.
Compression: Brotli Over Gzip
After you've minimized your raw bundle size, compression provides the final layer of optimization. Brotli typically achieves 15 to 20 percent better compression than gzip for JavaScript files, and it's supported by all modern browsers over HTTPS.
Pre-compress your assets at build time rather than relying on on-the-fly compression, which adds latency to every request:
npm install --save-dev vite-plugin-compression// vite.config.js
import viteCompression from 'vite-plugin-compression';
export default defineConfig({
plugins: [
viteCompression({ algorithm: 'brotliCompress' }),
],
});Configure your server or CDN to serve the pre-compressed .br files when the browser indicates Brotli support via the Accept-Encoding header.
Externalizing Shared Libraries via CDN
For widely-used libraries like React, consider loading them from a shared CDN rather than bundling them. This approach has trade-offs — you lose the benefit of tree shaking and add a DNS lookup — but if your users visit many sites that use the same CDN-hosted library, the shared cache can eliminate the download entirely. Evaluate this on a case-by-case basis based on your traffic patterns and dependency sizes.
A Practical Bundle Optimization Checklist
So, let's pull it all together. Here's a step-by-step checklist you can follow for any project. The items are sorted by impact — highest-return optimizations first:
- Analyze your current bundle using webpack-bundle-analyzer, rollup-plugin-visualizer, or source-map-explorer. Record baseline sizes.
- Implement route-based code splitting so each page loads only its own code. This alone typically reduces initial bundle size by 50 percent or more.
- Audit your dependencies for heavy libraries. Replace Moment.js, full Lodash imports, and other known offenders with lighter alternatives or native APIs.
- Configure vendor splitting to separate third-party code from application code for better caching.
- Verify tree shaking is working by importing a single function from a large library and checking whether the full library ends up in the bundle.
- Update your browserslist to target only modern browsers. Remove unnecessary polyfills.
- Apply component-level code splitting for heavy, below-the-fold, or interaction-triggered components.
- Enable Brotli compression for all JavaScript and CSS assets.
- Set up performance budgets in your CI pipeline to prevent regression.
- Consider islands architecture (Astro, Fresh) for content-heavy pages that need minimal interactivity.
Don't try to do everything at once. Start with analysis and route splitting, measure the impact, then move to the next item. Each step should show measurable improvement in your Core Web Vitals metrics — particularly LCP (from faster loading) and INP (from less JavaScript parsing and execution on the main thread).
Measuring the Impact on Core Web Vitals
Bundle optimization isn't an end in itself — it's a means to better user experience, which is ultimately measured by Core Web Vitals. After each optimization, verify the impact using both lab and field data.
In the lab, use Lighthouse to measure LCP, Total Blocking Time (a proxy for INP in lab settings), and Time to Interactive. Run Lighthouse with CPU throttling enabled to simulate real-world mobile conditions — the default 4x slowdown is a reasonable approximation of a mid-range Android phone.
In the field, use the web-vitals library or Real User Monitoring tools to track LCP, INP, and CLS from actual users. Field data is the ground truth, because lab data can't capture the full diversity of devices, network conditions, and user behavior that your real audience experiences.
Aim for an initial JavaScript bundle under 200 KB gzipped. That's an aggressive target, but it's achievable with the techniques in this guide — and it positions you well for strong Core Web Vitals scores. Sites that hit this target consistently see LCP under 2.5 seconds and INP under 200 milliseconds at the 75th percentile, well within Google's "good" thresholds.
Wrapping Up
JavaScript bundle optimization isn't glamorous work. It doesn't produce visible features or exciting demos. But honestly? It's some of the highest-leverage work a web developer can do. The data is unambiguous: smaller bundles lead to faster load times, better Core Web Vitals scores, higher search rankings, and more conversions. Sites that pass all Core Web Vitals thresholds rank 28 percent higher and see up to 20 percent more conversions.
The techniques covered here — code splitting, tree shaking, vendor splitting, modern tooling, dependency auditing, and performance budgets — aren't new ideas. What's changed is that the tooling has matured to the point where these optimizations are straightforward to implement. Vite 6 makes code splitting and tree shaking nearly automatic. Module Federation 2.0 solves the shared dependency problem for micro frontends at scale. Islands architecture eliminates the JavaScript overhead for static content entirely.
Start with analysis. Measure your current bundle. Identify the biggest opportunities. Implement the highest-impact optimizations first. Set up performance budgets to prevent regression. And then keep measuring — bundle optimization is an ongoing practice, not a one-time project. But the payoff in performance, user experience, and business outcomes is well worth the effort.