Asset Bundling

Why It Matters

Every file a page needs is a separate request with its own round trip, and on a phone with 120 ms of latency three hundred small modules is a visibly slow page even when the total bytes are modest. Bundling collapses that to a handful of requests, and tree shaking often removes a third of the code that was never reached. HTTP/2 softened the penalty for many files by multiplexing them over one connection, so the argument today is less about request count and more about size and compression — a single larger file compresses better than many small ones. The opposite failure is real too: one enormous bundle makes every visitor download the admin screens they will never open. The useful target is a few chunks, split along routes.

How It Works

The bundler is pointed at an entry file and builds a dependency graph from its import statements, pulling in local modules and packages from node_modules alike. It then resolves that graph into output chunks, rewriting import paths, inlining small assets as data URIs and copying larger ones into the output folder. Text is minified, source maps are written alongside for debugging, and each chunk is named with a hash of its contents. The build step ends by rewriting index.html so its script and link elements point at the new hashed filenames. What you upload is that output folder; the source modules never leave your machine.

Real-World Example

Common Mistakes

• ✕Publishing the source folder because it looks like the real project — the browser cannot resolve bare package imports, so the site loads a blank page and a console error
• ✕Bundling everything into one file for simplicity — first-time visitors then wait for code belonging to pages they never open
• ✕Uploading a development build — it keeps debug helpers and skips minification, and is routinely three to five times the size of the production output

Related Terms