A couple things: - It definitely shouldn't be downloading multiple megabytes of assets, at least not blocking assets. A reasonable primary JS bundle size (incl

A couple things: - It definitely shouldn't be downloading multiple megabytes of assets, at least not blocking assets. A reasonable primary JS bundle size (including the framework and other dependencies) is around 150kb; 30kb would be 20% of that. Images, marketings scripts, etc. are excluded because they don't block rendering/interactivity; the browser generally knows to defer those until after the main experience has loaded. The core bundle, on the other hand, blocks rendering content (if it's all rendered client-side) or at least interactivity (if content is rendered server-side and then hydrated client-side). And on top of just the download time, there's the time it takes the browser to parse and compile the code. So yeah, every few kilobytes matter. - Virtually nobody would have React in their browser cache from a re-usable URL. That was common in the jQuery days, but that's not how things are done today. For better or worse, a modern JS app bundles all of its dependencies statically in a self-sufficient bundle (possibly "chunked" into multiple files, but all domain-local). You could technically do things the old way, but you'd be fighting the tooling and ecosystem at every step. And anyway, your users probably wouldn't benefit from cache hits because no other sites are doing it. There's a hypothetical future where ES modules take off enough that dynamically loading dependencies becomes feasible and popular again, though even then, there are benefits to static bundling (like tree-shaking) that some probably wouldn't want to give up.