41–50 of 193 posts
However I think a bug chunk of the effect is that European mobile networks seem to take a second or two to 'connect' - ie. If you take your phone from your pocket and open an app, the first network request takes 2-3 seconds. Whereas for whatever reason, the same phone in the USA doesn't seem to have such a delay.
Earlier quoted context omitted.
No, HN is not just one request, it is 7. And no, latency does not accumulate. Because the browser requests assets in parallel as it loads the html. Also, assets can easily be routed through a CDN.
Sadly nowadays sites will send javascript which contains a request to fetch more javascript which contains a request to fetch more javascript which renders an html element which... wait for it... requests more javascript. This sounds like it's an exaggeration but no. At least on newer browsers we're no longer universally loading a javascript interpreter written in javascript (though sometimes we still are!)
For web apps, what matters most is above the fold load speed + time to interactive.
In the era when React got popular but Next.js hasn't yet, we had really slow performing sites because it did exactly what you said. Then people finally figured out that pure client-side rendering apps are too slow so people started switching to server side rendering. Non-interactive websites switched to just static websites that load from CDNs.
Modern web apps and modern static websites are in a much better state than the 2014 - 2018 era.
Earlier quoted context omitted.
You describe the issue of dependencies. You don't need modern tooling to prevent it. A server side build step to combine assets only makes things worse. Because on first load you get bombed with a giant blob of code you don't need. Or the developers get lost in the complexity of it and it becomes a giant hairball of chaos. The Twitter homepage takes 185 requests to load. AirBnB 240. Reddit 247. Look at the source cod…
All quite true, server renders pages are the quickest route to first render, in-line your CSS for that first page and it's even quicker. All best practices for sites that fit those categories, content and e-commerce for example. But not all sites and apps can do that, and almost certainly not for all functionality and pages. Bloat isn't just about tooling, it's organisational too. Lots of teams all working within one…
I don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe. If you have users in Sydney, Australia ... ... you are floored at 104ms of latency for your request When I open AirBnB with a clean browser cache, it takes several seconds until I see something useful. Those 104ms of latency don't make a dent. Reddit takes over 5 se…
HN front page isn't filled with garbage and loaded with a million lines of pointless javascript like all other sites you mentioned. HN front page is 27 kb in size while, for example, reddit is 943 kb. Performance issues with websites are entirely a self-made problem. There are plenty of fast, lean and yet very functional web pages like HN that prove that prove it.
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!
Earlier quoted context omitted.
Sadly nowadays sites will send javascript which contains a request to fetch more javascript which contains a request to fetch more javascript which renders an html element which... wait for it... requests more javascript. This sounds like it's an exaggeration but no. At least on newer browsers we're no longer universally loading a javascript interpreter written in javascript (though sometimes we still are!)
A lot of the JS calling for more JS is third party services that don't block render. For web apps, what matters most is above the fold load speed + time to interactive. In the era when React got popular but Next.js hasn't yet, we had really slow performing sites because it did exactly what you said. Then people finally figured out that pure client-side rendering apps are too slow so people started switching to server…
I don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe. If you have users in Sydney, Australia ... ... you are floored at 104ms of latency for your request When I open AirBnB with a clean browser cache, it takes several seconds until I see something useful. Those 104ms of latency don't make a dent. Reddit takes over 5 se…
Browsing HN only needs one round-trip (fetch the HTML), maybe two if you don't have it cached (fetch the CSS). Many apps need more round-trips, by loading assets sequentially. For example: fetch the HTML, then the JS, then the JS downloads its config, then the JS fetches some assets. Latency accumulates with every round-trip.
It's never just one round-trip: the TCP handshake is one round-trip in itself, then there's the TLS handshake needing two addionnal round-trips, and only then comes the HTTP round trip. So the minimum latency you can have to load just the HTML is in fact 4 times the round-trip time. (And I left DNS aside, because the DNS resolution process involves talking to different servers that are thelselves at different distances).
Earlier quoted context omitted.
HN front page isn't filled with garbage and loaded with a million lines of pointless javascript like all other sites you mentioned. HN front page is 27 kb in size while, for example, reddit is 943 kb. Performance issues with websites are entirely a self-made problem. There are plenty of fast, lean and yet very functional web pages like HN that prove that prove it.
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…
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.
Earlier quoted context omitted.
It is not. A simple traceroute shows traffic from Auckland, New Zealand is routed all the way to the San Diego via Los Angeles. Cloudflare sites typically have traceroutes terminating here at Auckland (best case scenario) or in some cases across the pond in Sydney, Australia. It is interesting to note however I don't observe much latency issues despite a 130ms round trip.
~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.
But even 600ms is OK on today's web (or even on today's desktop apps it seems…)
Earlier quoted context omitted.
No, HN is not just one request, it is 7. And no, latency does not accumulate. Because the browser requests assets in parallel as it loads the html. Also, assets can easily be routed through a CDN.
> HN is not just one request, it is 7 For those curious, it's /, then css, js, then 2 svgs, 1 ico (favicon) and 1 1x1 gif. None over 10k over the wire (/ is ~40k before compression)