[bruce511]

>> has to make 40 requests pulling in js files, CSS files fonts

So it's 2023 and I've been concatenation all my css, and all my js, into a single css and js request since like 2005. So a call to the site results in maybe 3 or 4 requests, not 40. But I've noticed most sites don't do this. Perhaps because I was trained when we had 28k modems not 100mb fibre?

Http/2 makes a big deal of multiplexing, but its less convincing when there are only 3 connections already.

I guess I also don't have a million separate image files, or ads etc so that likely helps.

[jaggederest]

Remember back in the old days when people used to concatenate images into imagemaps and specify the coordinates and dimensions? One image file for a whole site.

Same goes back when we could just load a single library from the Google public version (cough-jquery-cough) and then all the on-page JS was just in-tag handlers. Not that it was better but boy howdy was it faster to load.

[hunter2_]

You're probably thinking of CSS sprites, if you mean only displaying a certain portion of the image file at a time. An image map is when you display the whole image file as-is, but have different clickable links at different coordinates/dimensions.

The former is specifically for reducing requests, while the latter is more about UX.

[pcthrowaway]

For what it's worth, I recall the CSS sprite technique being referred to as image mapping too.

Sure, it's different from the <map> element (which is officially an image map, as you say).

But it's effectively mapping out the sections of a large image that you care about and then using CSS to display parts of it

[hunter2_]

Yeah, I vaguely recall some usage like that by the same crowd that also thinks an "anchor" is specifically a fragment link that brings you to a certain element on the same page, when in reality the word applies to all <a> tags. Sort of a casual understanding of HTML among non-devs.

[jaggederest]

I'm actually conflating both, you're right. I'm thinking of sprite-ed CSS, but also the really really old style imagemap where the same image could be clickable in multiple areas for different purposes.

[0xcde4c3db]

I'm sure it's due to lack of standardization on the early web, but the really wild thing to me is that there are both client-side and server-side image maps (both still specified in HTML5). With the former, the various regions of the image are defined within the HTML and more or less act like regular links. With the latter, the client sends the coordinates to the server and gets redirected, so the user has no idea which pixels correspond to which URL.

[greiskul]

Google used css sprites for Google+. They cared a lot about speed, specially for the stream, with even some CSS constructs that were known to be slow were banned from use for rendering posts.

For css sprites, you could submit an image to a folder in the monorepo, and a couple of minutes later an automated system would update the image with all the sprites, and create constants that you could you in your templates/css to use the icons with the coordinates/size of the image.

[sanitycheck]

Not just in the old days, if you ever need to target super slow devices with web tech this sort of optimisation is still needed. I've used Spritesmith (https://www.npmjs.com/package/spritesmith) to good effect, there are probably others too.

[WorldMaker]

It's too bad ad tracking networks ruined shared JS hosting and CDNs for everyone. There's no cache benefit to it any more because browsers stopped sharing caches between sites for privacy reasons.

(As Deno shows, ESM imports make a lot of sense from CDN-like URLs again. It just won't perform well in the browser because there is no shared cache benefit.)

[rbinv]

The original Space Jam (1996) site does this for navigation (and it still works fine): https://www.spacejam.com/1996/cmp/jamcentral/jamcentralframe...

[moring]

I just checked, and no it doesn't. The icons in the navigation are separate .gif files.

edit to add: And this makes a large part of the load time (when not cached). Other than that, the largest part is the SSL handshake and the fact that the server seems to be a bit slow (WRT the fact that it serves static content; 200ms for dynamic stuff would be okay).

Still a lot faster than most of todays websites.

[Krutonium]

In fairness I would be completely not surprised to find out it's on the same hardware as the day it launched, and probably hosts a pile of other static sites besides.

[bleuarff]

About bundling assets I'm not convinced. I've run a year-long test where 50% of our users would download a single JS bundle, and the others would use about a dozen distinct files. All using HTTP/2. I've checked every metric I could think of to see what's best. In the end the not-bundled pages would be a tiny bit quicker to load, but I the few milliseconds of difference was not significant. So I stopped bothering and do not bundle my JS anymore.

[mschuster91]

> But I've noticed most sites don't do this.

Because the trend went from having Webpack produce a 5+MB single JS bundle to splitting based on the exact chunks of code that the current React view needs, particularly to improve the experience of mobile users.

[bruce511]

Obviously I'm not using enough JavaScript :) My typical size is well under a meg - around 300K compressed. that's for all the script for the whole site...

Cheers Bruce

[trinovantes]

We're now supposed to optimize for First Contentful Paint metric which benefits from tiny initial requests (ideally inlined css/js) rather than giant bundled js/css files

[cbzoiav]

You dropped the API calls bit.

As it stands your site has to go through a TCP handshake then send the request and get the start of the response - at minimum that's 2 round trips. It then gets the JS and CSS tags in the head of the HTML and has to request those - let's assume HTTP/2 so that's another single RT of latency (on HTTP it's at least two depending on if you queue requests or send in parallel).

On 215ms RT latency that is an absolute minimum of 645ms before your JS has even started to be parsed. For a large bundle with a load of vendor code at the top in practice were talking several seconds to getting to the code that makes the API calls to get the content needed to render the first page.

And this is before we talk about any Auth, images, opening a websocket or two and people using microservices as an excuse to require a request for nearly every field on the page... (Or worse multiple requests and applying some logic to them...).

There is a fundamental minimum RT bound to a static JS based web app that is a multiple of a server rendered page. If you cache the HTML and JS bundle it can be worth it but you still need to aggregate data sources for the page on a backend and/or host it in multiple regions.

[jefozabuss]

Modules are widely supported now for js which means you could have 100 modules = 100 files instead of 1 bundle of 100 modules = 1 file, obviously this is not "the most ideal" but it allows you to skip a build step. There are also frameworks like Astro that splits your pages into tiny pieces so there are definitely some ways to add a lot of requests