4 ms·

Size isn't even the worst of it. It's number of requests. You need to go through a TCP handshake for every connection you open. You can reuse the connection bu

Size isn't even the worst of it. It's number of requests. You need to go through a TCP handshake for every connection you open. You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. Browsers also have a cap on parallel connections so when you get enough requests it queues either way. HTTP/2 reduces the problem with multiplexing but it still doesn't go away. If your app has to make 40 requests pulling in js files, CSS files fonts, API calls etc. to show something useful that will be visibly slow the moment a user is out of region. If it's a single server rendered piece of html it's a single request. Then for real fun be in an enterprise environment with Kerberos Auth adding a load more round trips to the server. For even more fun add in a mobile browsing solution that only has ingress in a far region when the site is hosted locally!

bruce511 3y ago
>> 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.
- jefozabuss 3y ago
  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
- jaggederest 3y ago
  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_ 3y ago
    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.
    - jaggederest 3y ago
      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.
    - pcthrowaway 3y ago
      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_ 3y ago
        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.
    - 0xcde4c3db 3y ago
      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.
  - 3y ago
- mschuster91 3y ago
  > 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 3y ago
    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
- bleuarff 3y ago
  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.
- trinovantes 3y ago
  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 3y ago
  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.
bob1029 3y ago
> It's number of requests. Absolutely. This is the prime hallmark of shitty, slow web. If you fight your battles here everything else will fall into place. I've started building our B2B web apps where the server returns 1 final, static HTML document in response to every resource. There are no separate js/css resource URLs at all in our products anymore. Anything we need is interpolated into the final HTML document script or style tag by the server. If you back up for a few minutes and really think about what kind of power you get with server-side rendering relative to # of requests... It's a gigantic deal. Composing complex client views shouldn't happen on the client. It should happen on the server where all of the answers already live. Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage? In terms of latency, the game theory for me is simple: Either do it in exactly one request, or it doesn't matter how many requests it takes. That said... caching effects are really important for many applications, and separating sources out can save you a lot of $$$ at scale. So, you will need to balance the UX and economic effects of some of these choices.
- XiS 3y ago
  Ever watched how many requests are fired off when opening the Telegram Web emoji window in any browser cache? Open it for yourself with developer tools open and cry.
- 411111111111111 3y ago
  For the record: a PWA can also be served by a single request, it's called hydration. My issue with these kinds of discussions is that they're inevitably using outright false arguments. You can make a well performing website through SSR and a backend templating language, yes. However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language. You can make a pwa with any of the usual frameworks and it's going to perform wonderfully... The bad performance begins when people start to write terrible code or just keep adding dependencies to cyberstalk their users. But doing the same in the backend puts you into the same position wrt poor performance, so it's just not an argument for or against SPAs. It's totally fine if you decide to write your website with a SSR stack however, and it could very well be the better choice for you, depending on how your skillset is aligned with the technology.
Dalewyn 3y ago
>If your app has to make 40 requests pulling in js files, CSS files fonts, API calls etc. to show something useful that will be visibly slow To put this in a way the common man can appreciate, imagine you're at a restaurant and you ordered some clam chowder and your waiter brings it to you. If the waiter brings you the chowder complete in one bowl, you get the chowder then and there. That is HN and most websites from ye olde Web 1.0 days. Waiter: "Your clam chowder, sir." You: "Thanks!" If the waiter brings you the chowder piece by piece, spoon by spoon on the other hand... Waiter: "Your bowl, sir." You: "I thought I ordered clam chowder?" Waiter: "Your clam, sir." You: "Uhh--" Waiter: "Another clam, sir." You: "What are yo--" Waiter: "Some soup, sir." You: "..." Waiter: "An onion, sir." Waiter: "Another clam, sir." Waiter: "A potato, sir." Waiter: "Another onion, sir." Waiter: "Some more soup, sir." <An eternity later...> Waiter: "And your spoon, sir." You: "What the fuck."
- parasti 3y ago
  If the waiter prioritized the spoon request, you could start eating a lot sooner.
  - hutzlibu 3y ago
    Oh, then we could write a new framework, for optimizing the load order, so people can at least enjoy some banner, while they wait for the real meal.
  - steveBK123 3y ago
    as the content within the bowl move around as it continues to load
- constantly 3y ago
  “RE:RE:RE:RE:RE:RE:RE:CHECK THIS OUT ABOUT MODERN WEB DEV LOL!”
rcme 3y ago
HTTP/2 supports request multiplexing so you don’t need multiple connections or queuing to fetch multiple resources. The bigger issue is that a lot of requests are dependent on previous requests so all the latency adds up. E.g. when you fetch Reddit, it only downloads the JavaScript and then fetches the post content. The move away from server rendering of webpages has really made things slower.
- cbzoiav 3y ago
  Multiplexing isn't a golden bullet. You still hit limits. The initial TCP window is usually around 4KB so you have the handshake SYN RT (+ another two for TLS) followed by at most 4KB of request data. Cookies, auth headers etc. can make that a relatively low number of requests before you need to wait for the next RT. You also have the TCP window on the responses and again headers for large numbers of requests eat into that. And then as you say dependencies - load the HTML to load the CSS and JS to Auth the user to make the API calls (sometimes with their own dependency chains)...
michaelmior 3y ago
> You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. This is partially true. HTTP/2 is capable of issuing multiple requests on a single connection and retrieving multiple responses in a single packet (assuming it fits of course). So while you probably won't get the same benefit as you would with multiple parallel connections, the overhead is likely to be much less than just a simple multiple of the latency. This is especially true if you have a large number of small assets.
- cbzoiav 3y ago
  From my comment. > HTTP/2 reduces the problem with multiplexing but it still doesn't go away Even multiplexed you hit initial TCP window limits + all the response header overhead. And many cases you have dependencies - need the first HTML content to issue the JS request to issue the Auth request to issue the API call to issue the dependent API call...

bruce511 3y ago

>> 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.

jefozabuss 3y ago
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
jaggederest 3y ago
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_ 3y ago
  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.
  - jaggederest 3y ago
    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.
  - pcthrowaway 3y ago
    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_ 3y ago
      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.
  - 0xcde4c3db 3y ago
    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.
- 3y ago
mschuster91 3y ago
> 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 3y ago
  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
bleuarff 3y ago
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.
trinovantes 3y ago
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 3y ago
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.

bob1029 3y ago

> It's number of requests. Absolutely. This is the prime hallmark of shitty, slow web. If you fight your battles here everything else will fall into place. I've started building our B2B web apps where the server returns 1 final, static HTML document in response to every resource. There are no separate js/css resource URLs at all in our products anymore. Anything we need is interpolated into the final HTML document script or style tag by the server. If you back up for a few minutes and really think about what kind of power you get with server-side rendering relative to # of requests... It's a gigantic deal. Composing complex client views shouldn't happen on the client. It should happen on the server where all of the answers already live. Why make the client go read a bunch of information piles to re-assemble Humpty Dumpty every goddamn time they want to view the homepage? In terms of latency, the game theory for me is simple: Either do it in exactly one request, or it doesn't matter how many requests it takes. That said... caching effects are really important for many applications, and separating sources out can save you a lot of $$$ at scale. So, you will need to balance the UX and economic effects of some of these choices.

XiS 3y ago
Ever watched how many requests are fired off when opening the Telegram Web emoji window in any browser cache? Open it for yourself with developer tools open and cry.
411111111111111 3y ago
For the record: a PWA can also be served by a single request, it's called hydration. My issue with these kinds of discussions is that they're inevitably using outright false arguments. You can make a well performing website through SSR and a backend templating language, yes. However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language. You can make a pwa with any of the usual frameworks and it's going to perform wonderfully... The bad performance begins when people start to write terrible code or just keep adding dependencies to cyberstalk their users. But doing the same in the backend puts you into the same position wrt poor performance, so it's just not an argument for or against SPAs. It's totally fine if you decide to write your website with a SSR stack however, and it could very well be the better choice for you, depending on how your skillset is aligned with the technology.

Dalewyn 3y ago

>If your app has to make 40 requests pulling in js files, CSS files fonts, API calls etc. to show something useful that will be visibly slow To put this in a way the common man can appreciate, imagine you're at a restaurant and you ordered some clam chowder and your waiter brings it to you. If the waiter brings you the chowder complete in one bowl, you get the chowder then and there. That is HN and most websites from ye olde Web 1.0 days. Waiter: "Your clam chowder, sir." You: "Thanks!" If the waiter brings you the chowder piece by piece, spoon by spoon on the other hand... Waiter: "Your bowl, sir." You: "I thought I ordered clam chowder?" Waiter: "Your clam, sir." You: "Uhh--" Waiter: "Another clam, sir." You: "What are yo--" Waiter: "Some soup, sir." You: "..." Waiter: "An onion, sir." Waiter: "Another clam, sir." Waiter: "A potato, sir." Waiter: "Another onion, sir." Waiter: "Some more soup, sir." <An eternity later...> Waiter: "And your spoon, sir." You: "What the fuck."

parasti 3y ago
If the waiter prioritized the spoon request, you could start eating a lot sooner.
- hutzlibu 3y ago
  Oh, then we could write a new framework, for optimizing the load order, so people can at least enjoy some banner, while they wait for the real meal.
- steveBK123 3y ago
  as the content within the bowl move around as it continues to load
constantly 3y ago
“RE:RE:RE:RE:RE:RE:RE:CHECK THIS OUT ABOUT MODERN WEB DEV LOL!”

rcme 3y ago

HTTP/2 supports request multiplexing so you don’t need multiple connections or queuing to fetch multiple resources. The bigger issue is that a lot of requests are dependent on previous requests so all the latency adds up. E.g. when you fetch Reddit, it only downloads the JavaScript and then fetches the post content. The move away from server rendering of webpages has really made things slower.

cbzoiav 3y ago
Multiplexing isn't a golden bullet. You still hit limits. The initial TCP window is usually around 4KB so you have the handshake SYN RT (+ another two for TLS) followed by at most 4KB of request data. Cookies, auth headers etc. can make that a relatively low number of requests before you need to wait for the next RT. You also have the TCP window on the responses and again headers for large numbers of requests eat into that. And then as you say dependencies - load the HTML to load the CSS and JS to Auth the user to make the API calls (sometimes with their own dependency chains)...

michaelmior 3y ago

> You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. This is partially true. HTTP/2 is capable of issuing multiple requests on a single connection and retrieving multiple responses in a single packet (assuming it fits of course). So while you probably won't get the same benefit as you would with multiple parallel connections, the overhead is likely to be much less than just a simple multiple of the latency. This is especially true if you have a large number of small assets.

cbzoiav 3y ago
From my comment. > HTTP/2 reduces the problem with multiplexing but it still doesn't go away Even multiplexed you hit initial TCP window limits + all the response header overhead. And many cases you have dependencies - need the first HTML content to issue the JS request to issue the Auth request to issue the API call to issue the dependent API call...