4 ms·

If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading o

by Joeri 4y ago

If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones. Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries. As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint. I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.

galaxyLogic 4y ago
> there’s no real difference between downloading one big file and 100 little ones. Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response. It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.
- WorldMaker 4y ago
  HTTP 1.0 when every request/response pair was a separate TCP connection certainly was a huge deal for one big file versus 100 little ones. HTTP 1.1 shifted the dynamic a bit, when properly configured. HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.) There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).

by Joeri 4y ago

galaxyLogic 4y ago

> there’s no real difference between downloading one big file and 100 little ones. Are you sure? Each separate download needs its own negotiation with the server. Each download needs its own request and response. So you would have 100 requests and 100 responses versus 1 request and 1 response. It's the same difference as driving 100 cars vs. driving a train with 100 connected train-cars over a narrow bridge etc.

WorldMaker 4y ago
HTTP 1.0 when every request/response pair was a separate TCP connection certainly was a huge deal for one big file versus 100 little ones. HTTP 1.1 shifted the dynamic a bit, when properly configured. HTTP 2+ shift the dynamic a lot. When everything is a single reusable shared connection it's a lot more "100 connected train-cars". At that point it's more a matter of request/response header overhead. (And even there HTTP 2+ have interesting mitigations such as Brotli compression and common header dictionaries.) There's still some difference between one big file and 100 little ones in HTTP 2+, but things are much more complex and a lot of it does start to look like a "wash" (do whatever makes you happy to start, then performance test your specific scenarios once you've got a complete application).