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