Noticing when an app is only hosted in us-east-1(blog.jonlu.ca) |
Noticing when an app is only hosted in us-east-1(blog.jonlu.ca) |
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
Reddit takes over 5 seconds until the cookie banner is ready for me to click it away.
Twitter takes 6 seconds to load the homepage and display the single tweet which fits on it.
preview images take a little longer to load
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!
Q2: Why don't we just force all the SV techbros to test their sites - AND their browsers - on a $200 notebook with eMMC storage from 2 years ago?
When the CSS is cached, this becomes ~200ms. Considering that the roundtrip is 168ms, this means that the vast majority of the pageload is just waiting for bytes to cross the atlantic. The roundtrip to eu-central is 30-50ms in comparison, less than 1/3rd. 3 times faster pageload is a significant UX difference.
Now, the reason we accept it with HN is that HN is just a list of direct anchor tags - the majority of the content is other websites. If the page had been more interactive, firing requests and dynamically fetching content, it would feel sluggish at best.
The difference in UX caused by latency is huge.
Going from 3s to 1s would be significant. Going from 200ms to 67ms wouldn't be very significant. There are very diminishing UX returns when going below ~300ms.
My server is located in Sweden, and for users in US West, access through Cloudflare adds like 100-150ms ping. It's very noticeable, bordering on intolerable for API access.
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.
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.
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).
With only a tiny bit more effort you could improve things even further by generating 'resource packs' (just zip files really) like games do, that you can load and then unpack locally.
https://onlineornot.com/do-i-need-a-cdn?url=https://news.yco...
I feel like people also often forget that bad peering by ISP can have a big influence on the overall latency.
HTTP / TCP overhead and throttling is another factor; there's a few bounces back and forth before a request can be fulfilled.
However, the factor here is that with http/2 and other advancements, the number of roundtrips and the number of requests needed to get resources is reduced by a lot. HTTP 1 needed one request per resource, HTTP 2 and 3 can bundle them into the same connection. I'm not explaining it very well, there's good resources out there.
anyway, HN is an example of old internet style websites, where latency is compensated for by the webpages just being small and snappy. A lot of advances in things like latency and speed have been undone by heavier websites.
There are newer web technologies and methodologies to help get around some of these problems that request cascades have. React itself, on the other hand, in how it loads children, then children of children, oftentimes conditionally based on data availability, has made the problem worse. There's also CDNs, and more recently, edge-local compute like CF Workers. The emergence of all of these technologies to help triage the problems geographic centrality in service deployments creates should be all the evidence you need to change your mind that this is a real problem.
But, it will remain a problem, because much like passwords to passkeys: It takes a very long time to clear out the calcification that's been built up in our human and computer systems. Not only does it require a shift in how we think about systems design; it requires convincing people like you that this is, in fact, a problem; people who may have not left town for years, not experienced the internet from the other side of the globe. Ashburn VA is ~2500 miles from the west coast of the US; ~4000 miles from Europe, Hawaii, or Alaska; and ~11,000 miles from Perth, Australia or Jakarta. Yes; the US is that large, and the world is that large; your experience in Europe is barely different than what a person living in California would experience, on a site that centralizes itself in us-east-1. There's a lot more distance to cover once you move out of the West.
How about if you make a site, that doesn't require hundreds of requests to display? One html, one js, 5, maybe 10 images, that can be loaded after the text and placeholders are rendered, and that's it.
Lazy loading images drives me a little bit nuts. Previously with JS, now build into the browser. You scroll down and then you’re waiting for an image, regardless of CDN. The latency of an additional connection is notable. It’s particularly aggravating if you’re have opened a page in a background tabs minutes or hours ago and when you start reading it, the page isn’t really there as expected but still needs to lazy load.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
Aren't there several requests to complete though? Assuming 5 synchronous requests before the first byte of your web page is rendered (a DNS lookup, a TLS connection to establish (which requires 2 requests), then a preflight request, and finally the actual request) that's a full half a second just on the flight time regardless of all the other costs. That's an extra 10% on top of the 5s it takes for Reddit to load. Subsequent requests would be faster but generally it's the first page load people really notice.
I don't think most service cache data that isn't normally used in that region. In my experience I noticed that Twitter, YouTube, and Facebook feel sluggish when you are viewing Japanese content from Singapore compared to viewing the same content in Japan, etc.
Hacker news loads to content faster than Google or Bing search.
In fact hacker news is pretty much the only website I can actually feel slower to load when I am in France. Because the latency is actually not lost into the noise for once.
It is interesting to note however I don't observe much latency issues despite a 130ms round trip.
If you feel latency, it's probably not the one-direction or round-trip latency, but rather the MANY round trips that are typically required for an HTTP request. DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice (8.8.8.8 or whatever) to get to the authoritative server if it's not already cached (or distributed; big DNS providers will serve your zone in many regions). Then you have to set up a TCP session, which is 1.5 round trips. Then you have to set up TLS, which varies, and make an HTTP request, and wait for the response. (I counted 5 total round trips until you see the response.)
So basically if you calculate the speed of light between two points, multiply that by 2*(2+5) = 14 in the worst case to see your time to first byte. Doing something 14 times is always going to be slow.
The underlying issue here is not so much the distance, but rather that TCP, TLS, and HTTP don't care about latency at all. (I'll ignore the application layer, which probably wants to redirect you to /verify-session-cookie and then /hey-you-logged-in for some reason. And yes, TLS1.3 has 0RTT handshakes now too, eliminating some trips.)
This is the problem that HTTP/3 aims to fix; one round trip replaces the TCP handshake, TLS handshake, and HTTP request. You shoot out a packet, you get back an HTTP response. (You still have to do the DNS lookup, so we'll call this 3 round trips total.)
Whenever I'd visit the west coast, I was shocked how much faster the web seemed.
So I sympathize with the sentiment.
Thing is though, the entire web feels pretty sluggish to me these days. And that's with us-east-1 less than 300 miles away from me. Because most web sites aren't slow due to where they're hosted, but rather because of how bloated with crap most of them have become.
It doesn't seem much faster than it seemed in 1995 when I first got online. There's much more stuff, but the latency doesn't really seem much better.
It's probably commercial: people don't mind wasting 3-4 seconds at a time loading Reddit/FB/etc and in that time a whole bunch of code that's useful to the website operator is loaded. All the stuff that tracks what you're up to.
> Using a global CDN can help get your assets to your users quicker, and most companies by this point are using something like Cloudflare or Vercel, but many still only serve static or cached content this way. Very frequently the origin server will still be a centralized monolith deployed in only one location, or there will only be a single database cluster.
Notably: even if the source of truth is single-region, there's a lot that can be done to improve the experience by flushing parts of the page at the edge.
Check out https://how-is-this-not-illegal.vercel.app/ where the layout.tsx[1] file is edge-rendered right away with placeholders, and then the edge renderer streams the content when the single-region database responds.
Furthermore, consider that parts of the page (like the CMS content) can also be cached and pushed to the edge more easily than, say, a shipping estimate or personalized product recommendations, so you can have content as part of that initial placeholder flush. We have an e-commerce example that shows this[2].
[1] https://github.com/rauchg/how-is-this-not-illegal/blob/main/...
There are (in http 1.1 at least) many back and forth steps to negotiating the HTTPS connection, the encryption key, etc. A global cdn into a cloud service (CloudFront is the example I know best) lets the user do those back and forths with a server very close to them, then handle the long haul to where the request is handled in one round trip.
Eg: putting CloudFront in front of your API calls can make them faster! Great video by slack on the topic: https://m.youtube.com/watch?v=oVaTiRl9-v0
When I moved inside Europe I suddenly noticed slow connections to Github pages. I expected that it had something to the physical location of the Github pages servers. However, when I connected to the VPN of my previous location it all was snappy again. That eliminated the physical distance as a cause.
Disclaimer: I am currently working for a startup attempting to build a video creation and distribution platform with global reach.
But the problem, like many of the other commenters are saying, is for a single request us-east-1 is actually fine. But for a modern web app but many requests, that compounds real quick. I actually think living here is an advantage as a web developer because it’s like those athletes that only train at high altitudes — living in a high latency environment means you notice problems easily.
(*) Similar to AU, we're also in the middle of "nowhere"
The response time for Bitbucket for example is:
100ms from us-east
300ms from us-west
400ms from eu-central
600ms from tokyo
800ms from sydney
(numbers from OnlineOrNot)
https://onlineornot.com/do-i-need-a-cdn?url=https://bitbucke...
If you could do something simple in the style of POSTMAN, but with less options - I'd pay fwiw. Not a lot, but if it existed - I'd want it!
Send a POST request to ${url} with ${headers} and ${body} and tell me how long it took from your servers...that'd be awesome!
I tested on my sass that has a CDN and got scared a little bit, but then did a second call and cache hit everywhere, thank god.
Particularly the part quoted in this comment: https://news.ycombinator.com/item?id=36507013
But tbh I think this is mainly a problem for apps that have a long chain of dependent requests. If you make 3 requests one after the other, it's probably fine. If the DOM isn't stable until after a series of 10 requests, any amount of latency is noticeable.
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.
Some of my worst experience was being forced to use SFTP to transfer thousands of small files to a server in us-east-1, which can take hours due to latency alone compared to transferring the same set of files using rsync / compressed archive which finish in minutes, and using RDP to access a remote windows machine behind a VPN, then run putty there to access a Linux server (the VPN only allows RDP traffics), and then I need to transfer thousands of files to the Linux server as well (my solution was to punch a hole through their shitty VPN via an intermediary bastion host I fully control, which allows me to use rsync).
Ping towards USA has lowered the most. This used to be 225ms in the earlier online days.
The owners were pissed that it had gone down and it wasn't that it went down, it was that we were basically sitting around with our thumbs up our ass. When things went down in our DC, we just fixed them or at least we could give an ETA until things went back to normal. We had absolutely nothing. We couldn't access anything, and AWS was being slow in acknowledging an issue even existed.
That was a good lesson that day: the cloud is not necessarily better.
You'll only pay for backend queries, not for every single button style
The process of setting up an active passive region with the db is becoming more common but an active/active design is still relatively rare outside of apps designed for massive scale.
[1] https://peering.google.com/#/infrastructure -> Under the edge nodes part
I guessed from the title that this would focus on redundancy, but I guess that's rarely noticable.
Isn't it double just because ping measures round trip time?
If you’re opening a website on a low end smartphone with an outdated system, the network latency might be not noticeable (because the UX of the device is so slow anyway).
I'd love to know how my sites behave in Frankfurt, Mumbai, SF, Sydney, etc.
Is pretty interesting.
If someone set up a postman style clone, but I could drop-down and run it from a server in ${wherever} - that might be worth something...?
I believe that’s the source he’s using.
To add to your post, don't forget TCP congestion window scaling, which will add some more roundtrips - this mostly depends on the size and bandwidth of the ressources, so smaller sites like HN have an advantage here. Especially if the initial ressources fit within the initcwnd (10*MSS, usually around 15kb). But this, like many of the parameters you mentioned, are highly flow- and also software specific, it becomes so hard to make meaningfull predictions.
I hope your DNS doesn't have to do that. Most anycast DNS should have lots of PoPs (regions) and are really fast.
CDNs usually solve a lot of the static asset issues.
The main issue is the database.
I run the checks via AWS Lambda for now, might put it somewhere more stable like Hetzner/DigitalOcean for better accuracy.
Suggestions aside, look at the difference between HN and Google (measured in milliseconds):
us-east: 39 HN, 40 GGL us-west: 128 HN, 118 GGL europe: 186 HN, 109 GGL tokyo: 291 HN, 143 GGL sydney: 405 HN, 303 GGL
Kind of interesting, did not expect Googles latency to be that high in Sydney.
https://onlineornot.com/api-monitoring
If it doesn't quite match what you expect I'd be happy to add additional features!
That’s not true. TLS 1.3 0-RTT cuts down on handshake roundtrips, taking one roundtrip to establish the TCP connection before data can be sent; and HTTP/3 (QUIC) with 0-RTT actually makes it zero roundtrip, HTTP request is sent directly and response is received in one roundtrip.
It looks like the 0-RTT thing only work for connection resumption so it will only work if the user has already visited the site before.
Still, even without it, TIL that since TLS1.3, there's only a single round-trip and not two in the TLS handshake.
Cloudflare rejects about 2.5M search queries per day from bots. About ~20k make it through, and some of those are humans.
US East (N. Virginia)
62ms 200 OK
Europe (Frankfurt)
62ms 200 OK
US West (N. California)
175ms 200 OK
Asia Pacific (Sydney)
359ms 200 OK
Asia Pacific (Tokyo)
662ms 200 OK
SV techbros are a fun pinata to smash, but that's a load of bullshit intended to conflate individual workers (easily hateable and zero power to fix anything) with ad-tech/paywalls/lead acquisition/overoptimisation driven by profit-seeking (too diffuse to hate, too little understood for lawmakers to regulate effectively...yet), and make slow websites seem like a technical or competency problem instead of an auctioning-your-eyeballs-and-spamming-you-with-modals.
I also have a feeling hardware designers could use being forced to live somewhere that's not a dust less constant temperature air conditioned office in California, but that's another matter for a different rant.
But even 600ms is OK on today's web (or even on today's desktop apps it seems…)
The solution there is use a CDN, even for the API. Or some anycast IP solution like Global Accelerator (AWS), Global load balancer (GCP) or Front Door (Azure).
You connect to the nearest region for HTTPS handshake and then that takes the "fastest" route back to your origin.
There's a video from AWS documenting how Slack did exactly that: youtube.com/watch?v=oVaTiRl9-v0
HN user experience in EU is "meh" because HN is one of the fastest loading dynamic pages on the web to load, meant to give you whiplash from the load speed.
Not all pages can load with 1 request, even when designed well, so they will be sub-"meh". HN, if hosted in EU, would have gotten a "daaang" rating.
It's not: it's super quick, the fastest website I check on a daily basis, by very far. If only all the web could be like this!
Which is user tekmol 's point: "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."
HN is great in the EU. If most of the pageloading is just the roundtrip, you've already won, no matter if your users are on the same continent as your unique server or not.
How you grade those experiences is subjective. Your "great" is likely my "meh", as physics dictate that we see similar results.
That it makes a significant difference for HN (as in: "measurable") is because HN is so snappy in the first place.
Apart from that, being located in Europe, I agree with the other posters that claiming HN being "meh" in Europe is just nonsense. It's one of the quickest websites you can come across on this planet. Anywhere on the planet.
When you use a VPN and then immediately send all your DNS lookups right back to your ISP... Hey I wonder where this person is actually from! Maybe the geographical area of the regional ISP that all their DNS lookups are coming from...
I've been using a local recursive resolver for the past 2-3 years and haven't seen a noticeable difference in resolution times as compared with using my ISP's resolver.
I would guess that using a local recursive resolver (although it caches as well, so that's less of an issue with items in-cache) increases resolution times, but only on the order of tens of milliseconds.
Which is peanuts compared to client/server query response times, especially if requests return data and/or javascript heavy results.
And given that many ISPs mine their customers' DNS queries and sometimes return incorrect (from the perspective of the customer) results, I'd rather not use my ISP's resolvers -- and that hasn't had any noticeable impact on responses to browser requests.
In fact, uMatrix tends to slow things down much more for me as I often have to choose which scripts/3rd party assets/etc. to allow in order to browse a particular site -- or just to abandon the attempt if there's too much cruft.
That especially annoys me when I need to load scripts from several different sites just to view text. In those cases, I usually just close the tab.
Also, they often run a single instance of bind, with little to no load-balancing.
I think these are the main reasons for people to use other dns providers.
But that cannot help with interactive pages or web applications, and in other cases it can be a bandwidth/latency tradeoff.
High latency is always bad and should be avoided. Serving content from the served contentinent is the minimum requirement for good UX.
I exaggerate a bit to prove a point but the gist is definitely happening, we're just waking up to it slowly.
With stuff like web sockets/Web rtc /whatever new awesome sauce is out today a lot of that has changed, but that's still really the same spirit of ajax anyway, just with actual persistent connections instead of hacking it with long polling.
You can write a shitty system regardless of paradigms used.
You can write a beautiful system even with painful primitives.
All it comes down to is how much time and talent you're willing to invest, which is admittedly a cliche and non answer, but true nonetheless.
Static HTML only has a potential latency benefit on first load due to the ability to save render-blocking resource roundtrips. For later requests where those resources are already fetched, it only adds bandwidth overhead.
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 code to see the chaos their build systems create.
Simply using a server side rendred html page and native javascript modules prevents all of that. The modules get loaded asynchronously. So the modules and their dependencies have time to load until all the html interface and the asynchronous assets like CSS, images etc are loaded and rendered. And then the modules can kick in.
old.reddit.com was 10 requests, 5kB transferred, 9kB resources I tried mbasic.facebook.com and interestingly it was (not logged in) only 1 request 1.1kB transferred, 1.1kB resources
I turned off any browser level blocking, but I do have some network level ad-blocking. I wonder why you get 111 more requests for (www.)reddit.com than I do.
Those(mbasic.facebook, old.reddit) are the old/basic interfaces I use regularly and both are requirements for me, I won't use their normal websites or apps so if they get shutdown I would leave for good.
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 product.
Modern ES modules can actually be worse if not bundled on on the server or by a build system. The browser doesn't know what to request until it starts parsing the previous response, that dependency tree can be large. That literally is accumulating latency. However with progressive improvement it's not much of an issue, but again not everyone can do that.
On top of that anyone still on HTTP 1.2 will only be doing ~5 requests to the same domain in parallel.
Point is, latency does accumulate, but it doesn't have to with well designed code structure, "modern" (rediscovered 90s) techniques, and modern browser features like preload and preconnect.
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.
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)
In modern apps, there's often additional assets loaded from Javscript calling endpoints or calling for more assets.
If you do server side rendering, there are usually fewer roundtrips.
https://entrackr.com/2022/11/exclusive-indian-isps-we-alread...
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.
Correct me if I'm wrong, but originally it was because "servers" had order-of client compute power. Ergo, it was necessary to offload as much compute to the client as possible.
And then in early js era it was because network latency and bandwidth limitations precluded server-client round-trips for anything user-interactive.
Now, we've got surplus compute and bandwidth on both sides (order-of text payloads), so caching architecture and tooling become the limiting factors.
Still do. Biggest difference: If you intend to serve the same complexity of web experience today that you were trying to serve 20 years ago, you will find a single MacBook would likely be enough to handle the traffic. The challenge is that we've taken advantage of the exponential compute growth over the years and now it feels like we still have the exact same scaling issues on the server relative to the client.
If you constrain your product & design just a tiny bit, you can escape this horrible trap and enjoy those 4-5 orders of magnitude. If you design your website like Berkshire Hathaway or HN, you are on the right power curve. Seriously - go open Berkshire's website right now just to remind yourself how fast the web can be if you can lock that resume-driven ego crap in a box for a little bit.
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.
>However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.
I'm not sure this follows. It's harder to do client side rendering because your data is across a slow HTTP barrier. And the client is maintaining state which is harder than stateless.
The problem with SSR is that it's usually tied with single applications which are usually monoliths. But neither of these are requirements for SSR. If you break up your monolith into modules and/or SOA you get the best of both worlds.
But for reasons I don't understand nobody does it this way. It's either monolith + SSR or microservices + client rendering
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.
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."
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.
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)...
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.
> 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...
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.
The former is specifically for reducing requests, while the latter is more about UX.
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.
(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.)
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.
Cheers Bruce
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.
This is what we are doing. The server-side web monstrosity is effectively 30+ independent modules that are nested inside a common template. All of these could be worked individually without anyone stepping on each other. Anything that needs to be truly common lives in the wrapper and is rarely changed.
The only part of our business that everyone absolutely has to agree upon is the SQL schema. As long as we are talking to the data in some common language, no one will get too far off track.
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.
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
