Probably the coolest trick I've seen is inlining everything into a single HTML file: JS, CSS, images, icons and fonts. One single large request seems to work much better than loads of small ones.
This approach prevents any of those resources from being cached and reused on other pages. Visitors will end up re-downloading all that content if they click on any links on your page.
Mind you, most web developers assume users spend a lot more time on their site than they actually do. Most visitors to your website will not click on any internal links on your page.
Deliberate inlining tends to make you more sensitive to size issues so that that’s also less likely to be an issue. Inlining everything also makes it so that you can at least theoretically do more effective dead code removal on CSS and JavaScript, page-by-page, though I’m not sure if I’ve ever seen that actually being done, though the tools mostly exist; but compared with things like GCC and LLVM, web tooling is atrocious at optimisations.
It's still worth it depending on the page size and average page views per visit. However we're talking about a very small, very fast website. The parse+request time is longer than the 1-6kb of inlined resources.
We're doing this right now with our latest generation web app.
It's 1 big file of 100% hand-rolled html/css/js. The entire file is 1600 lines last I checked. Loads about as fast as you'd expect. I actually found a bug with the gzip threshold in AspNetCore vs chromium (the file is that small), so had to pad the index file with extra content to force gzip. Most of the dynamic UI happens over a websocket using a server-side rendering approach similar to Blazor.
That’s… misleading, at best. Depends on how many resources you have, whether you’re using different domains, and whether you’re using HTTP/1 or something newer. Generally speaking, what you’re saying is only true if you have a lot of decently large resources, loaded from different domains or over HTTP/1.
If everything was coming from the same origin already, then:
• If you’re using HTTP/2 or HTTP/3 your statement is almost entirely false: whether you load in parallel or in serial, it’ll be downloading it at the same speed, except that by not inlining you’ve added at least one round trip for the client to know that it needs to request these other URLs; and now you mostly can’t control priority, whereas with everything inlined you know it’ll load everything in source order, which you can normally tweak to be pretty optimal.
• If you’re using HTTP/1, the use of multiple connections (typically up to 6) only kicks in if you’ve got plenty of stuff to download, but involves at least a couple of round trips to establish the connection, so even if using a single connection reduces the available bandwidth, it’s still normally worth it for many, probably most, sensibly-done sites.