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 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
Preview images of what? Images usually should be routed through a CDN which caches them directly in the user's country. It's extremely cheap and easy to set up. Nothing compared to running an application in multiple datacenters.
vjk800 670 days ago [-]
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.
cbzoiav 670 days ago [-]
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!
bob1029 670 days 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.
ethbr0 670 days ago [-]
> 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?
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.
bob1029 670 days ago [-]
> "servers" had order-of client compute power
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.
NikolaNovak 670 days ago [-]
It's very fast. It's almost unusable on a phone. That's not necessary though - I don't think you need much fanciness to make those tables not look teeny on the phone, just a little less pixel and size hard coding I think?
bob1029 670 days ago [-]
I am 99% sure you could solve this with a media query and some CSS totaling no more than 1KB.
XiS 670 days 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 670 days 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.
treis 670 days ago [-]
>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.
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
bob1029 670 days ago [-]
> If you break up your monolith into modules
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.
azurelake 670 days ago [-]
They do, look up the “Backend for Frontend” pattern.
bruce511 670 days 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.
jaggederest 670 days 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_ 670 days 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.
pcthrowaway 670 days 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_ 670 days 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.
jaggederest 670 days 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.
0xcde4c3db 670 days 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.
greiskul 670 days ago [-]
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 670 days ago [-]
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 670 days ago [-]
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.)
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 670 days ago [-]
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 670 days 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.
mschuster91 670 days 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 670 days 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
trinovantes 670 days 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 669 days 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.
jefozabuss 670 days 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
Dalewyn 670 days 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 670 days ago [-]
If the waiter prioritized the spoon request, you could start eating a lot sooner.
steveBK123 670 days ago [-]
as the content within the bowl move around as it continues to load
hutzlibu 670 days 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.
constantly 670 days ago [-]
“RE:RE:RE:RE:RE:RE:RE:CHECK THIS OUT ABOUT MODERN WEB DEV LOL!”
rcme 670 days 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 669 days 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 670 days 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 669 days 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...
yuuuuuuuu 670 days ago [-]
That's exactly GP's point, right? No matter us-east-1 or not, what makes things slow has nothing to do with DC location. That latency is insignificant.
arghwhat 670 days ago [-]
HN takes - when fully cached, where it only takes 1 request - ~200ms to load, so 3/4ths of the pageload is just the roundtrip.
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.
TacticalCoder 670 days ago [-]
> HN user experience in EU is "meh"
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.
arghwhat 665 days ago [-]
I disagree, but that does not matter - even if you think it is fast somewhere in the EU, the fact still holds that your perceived loading time is in the ballpark of 2-3x longer than it would have been if hosted within the EU.
How you grade those experiences is subjective. Your "great" is likely my "meh", as physics dictate that we see similar results.
zo1 670 days ago [-]
I'm on another hemisphere, diff continent (Africa) and closeish to the south pole. And even for me HN is very fast.
yuuuuuuuu 669 days ago [-]
I think you are missin the point. The typical website is so bloated that a latency of a single roundtrip is not the root cause. They may load quicker if roundtrips are faster, but that's then mainly because they make too many roundtrips.
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.
arghwhat 665 days ago [-]
Latency of a single roundtrip is the sole reason for the bloat being an issue. The bandwidth requirements to load even the heaviest webpages at a few megabytes is negligible for most people, but these pages are slow to load even in gigabit connections exactly due to their many render-blocking round-trips chained together.
nottorp 670 days ago [-]
Q1: Why would round trip latency matter so much when the modern web 45.0 adds so much overhead?
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?
noitpmeder 670 days ago [-]
Because most sites aren't interested in their users who use bad hardware as a market share. The most attractive client base are the ones with money to spend.
est31 670 days ago [-]
Rich people tend to be old, and not all, but many old people have bad hardware, even if they are rich. Meanwhile, 87% of US teenagers have iPhones.
hutzlibu 670 days ago [-]
Fair point, but even high end users have bad connection sometimes.
strken 670 days ago [-]
It matters a lot. I just spent three days on a 130kbps 1000+ms latency high packet loss connection, and RTT was one of the problems that made lots of sites I tried (practically) unusable, due to launching dependent queries in series without any retries. The other big one was gigantic interaction-blocking assets served from CDNs with aggressive timeouts.
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.
nottorp 670 days ago [-]
Pretty sure the guilt is shared. The profit seeking personal data peddlers don't choose overengineered solutions that only make sense at google scale.
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.
midoridensha 669 days ago [-]
The SV techbros should have to test their sites on 2010-era notebooks running through two VPNs connecting through Australia and Finland.
dr-detroit 670 days ago [-]
[dead]
arghwhat 670 days ago [-]
The reason HN loads in... 500ms in EU is that it takes exactly two roundtrips to load: One HTML blob, one render-blocking CSS. Rest is fast-ish abroad is because it takes exactly 2 somewhat lean roundtrips to load over the same TLS connection: One HTML blob, one CSS file, and the latter is cachable. There is JS, but it is loaded at the end. That is a hell of a lot better than the average website.
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.
noitpmeder 670 days ago [-]
There is no reason why most sites can't return one pregenerated static HTML blob. The number of async requests is a killer.
arghwhat 670 days ago [-]
For first load? Sure, that's possible in many case.
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.
zo1 670 days ago [-]
This is why we added http cache headers, CDNs and caching of common assets, and cross domain requests. All of which are being assaulted for various levels of "privacy" concerns. Privacy I never asked for mind you, but I get it anyways. Though how convenient that tracking still happens, I still get ads, my content still doesn't belong to me, sites are slower, everything is an App, and the general experience and openness of the web is Down.
I exaggerate a bit to prove a point but the gist is definitely happening, we're just waking up to it slowly.
hughesjj 670 days ago [-]
I mean, there's a reason ajax took off in the first place. Member having to reload the entire page on every user interaction? Member iframes? Member flash and silver light and java applets?
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.
Philip-J-Fry 670 days ago [-]
AJAX took off because it's good for interactivity. If your "AJAX" requests are literally blocking the functionality of the website then they're no better than returning a big HTML blob. Your page just takes longer to load and the user experience is worse.
arghwhat 670 days ago [-]
Returning new HTML blobs will never be faster than an equivalent AJAX roundtrip. In other words, if AJAX is slow when "literally blocking", fetching new HTML is at least that slow as well.
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.
670 days ago [-]
geokon 670 days ago [-]
I don't work in the webspace so genuinely curious... are things generally still cached between website visits? I thought that was effectively non-existant now a days b/c of fingerprintability. I'm pretty sure at least for JS it's the case. CSS is different?
Ndymium 670 days ago [-]
Resources are cached within the same origin. So HN resources will be cached and used on HN visits. But if two different sites load a library from the same CDN, they will not share their caches with each other and will both load it separately.
geokon 670 days ago [-]
Oh that's right! Thanks for clearing it up for me :) That does make more sense
SahAssar 670 days ago [-]
> 3 times faster pageload is a significant UX difference.
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.
heipei 670 days ago [-]
Same here. We run a very content/media-heavy SaaS SPA application completely out of a single location in Germany and have customers that are primarily located in the US, and also in places like Australia and Japan. We don't use any CDN, every request has to go to our origin in Germany. Yet customers regularly tell us how fast and snappy our application is. Why? While we do make dozens or even hundreds of requests per page navigation in the SPA (images, XHR), these are all fired off in parallel, and none of these are blocking anything. A CDN would probably improve things slightly, but currently we don't feel like we need it.
marginalia_nu 670 days ago [-]
CDNs can actually add quite a bit of latency depending on where you're located.
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.
quickthrower2 670 days ago [-]
Is that CDN or DDOS protection? CDN should serve static assets near the user.
Has to be quicker unless something went very wrong.
marginalia_nu 670 days ago [-]
Yeah, you can't have a public search endpoint or it will get spammed into oblivion. API endpoint is not cloudflared anymore though, since I use an API key system. But anything that is anonymous is basically toast if you don't use serious bot mitigation.
Cloudflare rejects about 2.5M search queries per day from bots. About ~20k make it through, and some of those are humans.
komon 670 days ago [-]
I wonder what your actual cache hit rate is? Sounds like it could use some tuning since 100-150ms sounds consistent with most requests hitting the origin?
progval 670 days ago [-]
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.
TekMol 670 days ago [-]
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.
samwillis 670 days ago [-]
Latency absolutely does accumulate for code as the parent described that cannot make a request until the previous one has returned (images linked from css files for example, or a spa with poorly chunked code). There is a lot of that code out there. "Modern" tooling and practices reduce that, but it not a solved problem for the majority of legacy code.
TekMol 670 days ago [-]
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 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.
drewmol 670 days ago [-]
Interesting for me:
reddit.com made 136 requests, 2.3MB Transferred, 3.0MB resources loaded by page
ireddit.com 254 requests, 19.2 MB!! transferred 22.3 MB resources
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.
samwillis 670 days ago [-]
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 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.
eerikkivistik 670 days ago [-]
I for one agree with both of you.
bandrami 670 days ago [-]
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!)
senttoschool 670 days ago [-]
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 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.
bandrami 670 days ago [-]
I take your point that more-recently designed sites have moved away from this antipattern but there's still a lot of the Web that has that mid-teens "hey bro I see you like javascript so I put some javascript in your javascript" mentality.
raverbashing 670 days ago [-]
> 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)
progval 670 days ago [-]
CSS, JS, y18.svg, and the GIF are fetched in parallel, so they only count once toward visible latency. triangle.svg is fetched after the CSS is done, so it does (though for me, it's done downloading before y18.svg is)
senttoschool 670 days ago [-]
True and not true.
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.
670 days ago [-]
littlestymaar 670 days ago [-]
> Browsing HN only needs one 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).
oefrha 670 days ago [-]
> It's never just one round-trip
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.
littlestymaar 670 days ago [-]
Thanks for pointing that out, it looks that my knowledge was a bit outdated.
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.
taneq 670 days ago [-]
I'm long out of web dev, but... is this really how (well designed) web apps work? It seems lazy, you should be able to statically generate a list of most, if not all, assets and queue them all up simultaneously.
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.
oefrha 670 days ago [-]
Which is why I get a heart attack whenever I hear people talk about forgoing bundlers and using esm imports for dependencies directly in production. Some will tell you that dozens/hundreds of small requests aren’t a problem since h2 can load them simultaneously in the same connection. What they don’t mention is the cascade of roundtrips as imported deps are parsed from scripts. Apparently they don’t care because they assume all users live 20ms from their data canters.
taneq 670 days ago [-]
Sadly this seems to be industry-wide these days, so many things don't work well (or at all!) without a fast internet connection. Most recent example that's been bugging me is Explorer in Windows still connects synchronously to network shares as far as I can tell.
oefrha 670 days ago [-]
As things get faster developers have to introduce lazier practices to maintain the same level of shittiness. Eliminate parallel request limit and they spam you with hundreds of scripts. Eliminate head of the line blocking and they come right back at you with cascade of dependencies blocking. Of course “things get faster” isn’t universal when it comes to network latency and throughput, so the experience strictly worsens for a subset of users.
resonious 670 days ago [-]
Do you think that's why Reddit takes 5 seconds to show a cookie banner?
rozenmd 670 days ago [-]
Here, I built a tool to help you visualise what response times are like from around the world so that you "buy this" idea:
Where are the request servers hosted? What's the peering like for those hosts?
I feel like people also often forget that bad peering by ISP can have a big influence on the overall latency.
selfhoster69 670 days ago [-]
Yep, this is the reason why I'm hesitant to switch ISPs despite crappy service during peak hours. They have PNIs/local CDN hostings/prominent IX peering and good international peering.
rozenmd 670 days ago [-]
It's on AWS Lambda
ssss11 670 days ago [-]
I blame adtech without even knowing if it is the cause in each instance. Some news sites have like 50+ trackers lol.
Cthulhu_ 670 days ago [-]
There's a few factors to keep in mind. HN is much smaller, uses less resources, less individual files; less roundtrips (of the hypothetical 104 ms) to get all the resources.
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.
flagged24 670 days ago [-]
This is why I don't buy the push to edge compute. There is often lower hanging fruit to be concerned about.
dogleash 670 days ago [-]
Hyped tech that lets someone feel like they're improving their product is a hell of a drug.
015a 670 days ago [-]
Latency isn't just a static number bolted on to baseline performance. While it may intuitively feel correct to say "if distance adds 100ms to every request, then a website with 200ms baseline performance would be 33% slower, but a website with 5000ms baseline performance would only be 2% slower"; its not. Its additive. A typical website like reddit will require hundreds if not thousands of requests to prop up the home page; many of these requests cascade in batches, their inputs being dependent on the output of the other; so, adding on 100ms to every request can very realistically mean the addition of 1-2s of load time, on a site that's already slow because its poorly engineered.
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.
ajsnigrutin 670 days ago [-]
> A typical website like reddit will require hundreds if not thousands of requests to prop up the home page;
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.
015a 670 days ago [-]
Well, they do, and continue to do so. If you'd like to wave that magic wand you seem to believe you have and instantly change the behavior tens of millions of people toward making the world perfect, I would support it. Short of attaining perfection, making things just a bit better through achievable means is a more productive path.
ttepasse 670 days ago [-]
> Preview images of what?
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.
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.
phamilton 669 days ago [-]
Just a nit, but aren't DNS lookups going to be independent of distance to us-east-1?
onion2k 669 days ago [-]
That depends on where the name server is. If a website is only hosted on us-east-1 it's common to see the canonical name server being in the US as well.
cdogl 670 days ago [-]
I'm in Melbourne and this is indeed one of the fastest websites I use. But most websites are bloated JavaScript apps with a gazillion assets so it's chalk and cheese really.
innocenat 670 days ago [-]
> Preview images of what? Images usually should be routed through a CDN which caches them directly in the user's country. It's extremely cheap and easy to set up. Nothing compared to running an application in multiple datacenters.
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.
670 days ago [-]
bombela 670 days ago [-]
I live right in the middle of the Silicon Valley and I observe the same timings.
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.
bigbacaloa 670 days ago [-]
HN is an old fashioned text based thing with no bells or whistles whatsoever. Of course it's responsive.
vjk800 670 days ago [-]
Yet this is all I ask for as a user.
cypress66 670 days ago [-]
In fact vastly superior to new reddit.
aaron695 670 days ago [-]
[dead]
quickthrower2 670 days ago [-]
I think cloudflare is in front of HN these days
kiwijamo 670 days ago [-]
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.
re-thc 670 days ago [-]
~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.
littlestymaar 670 days ago [-]
Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.
But even 600ms is OK on today's web (or even on today's desktop apps it seems…)
re-thc 670 days ago [-]
> Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.
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
alam2000 669 days ago [-]
[dead]
TekMol 670 days ago [-]
Have you thought about testing that assumption?
jrockway 670 days ago [-]
The speed of light in a fiber optic cable is slower than light in a vacuum, about 2.14e8 m/s.
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.)
littlecranky67 670 days ago [-]
Your post is a good read for everyone trying to calculate number of RTT solely on the HTTP layer, which is done so often, but always wrong.
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.
re-thc 670 days ago [-]
> DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice
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.
kiwijamo 670 days ago [-]
People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.
fragmede 670 days ago [-]
It depends on the competency of your ISP and how aggressive they are about so-called features. In several cases, the ISP provided DNS decided not to return NX results and instead returned a page of ads which was great for email servers, back in the day. The other failure mode I've seen is that the ISP's DNS servers are overloaded and take several seconds to respond.
citrin_ru 670 days ago [-]
Several cases is no enough reason for me to avoid ISP DNS by default, many if not most ISP don’t spoof NXDOMAIN and provide fast DNS.
criley2 670 days ago [-]
There's also the reality that using your ISP's DNS almost entirely moots any VPN you use. The main reason to use a VPN is to hide your browsing from your ISP and anyone your ISP might be reporting to (in the US for example we've seen several programs where the government intercepts ISP data at special places in interconnects, so even if your ISP publicly says your DNS is safe, it could actually be logged to a spy database associated to you)
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...
selfhoster69 670 days ago [-]
In India, internet providers already provide a portal to the police and other agencies with no accountability.
If you use VPN then you need to ensure that DNS traffic goes via VPN too of course. Not using ISP DNS is not enough in this case.
nobody9999 670 days ago [-]
>People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.
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.
selfhoster69 670 days ago [-]
In my experience, ISPs DNS servers are slower compared to 8.8.8.8 or 1.1.1.1, especially for "complex" lookups where there are as many as 6 CNAMEs in the DNS chain.
Also, they often run a single instance of bind, with little to no load-balancing.
hosteur 670 days ago [-]
Yeah in an ideal world. But then you have isps logging and selling your dns lookups as well as blocking certain dns names etc.
I think these are the main reasons for people to use other dns providers.
sznio 670 days ago [-]
I don't want to be subjected to my ISP (and even worse, government) "security" blocklists.
matharmin 670 days ago [-]
DNS is typically a single round-trip for CNAME + A. And if you're using a resolver such as 8.8.8.8 or 1.1.1.1, it will route to a resolver close to you in most cases, and already have the results cached for any major site.
js2 670 days ago [-]
I've been doing this long enough that I remember when all the big web sites were hosted in California. In fact, my company had its web farm in Sunnyvale which we managed over frame relay from Atlanta.
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.
lordnacho 670 days ago [-]
> 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.
sgt 670 days ago [-]
I've even seen sites that don't load properly or aren't usable before the cookie banner renders, which may be loaded inefficiently from somewhere else. It's tragic!
Good article! I always notice this same effect when I visit my parents in Argentina or I'm in Europe.
> 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].
Another way that a global cdn helps is that your HTTPS negotiation takes place closer by.
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.
I think the peering agreements of the local ISP are likely to be a factor as well.
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.
chrismsimpson 670 days ago [-]
To counter the top comment at the moment, being from Sydney, Australia, I totally do buy it. It also works both ways, if you want to build something with global reach but host it locally you’re immediately going to be penalised by the perceptions that come with latency. Also, I might add that the latency builds up non linearly the more throughput you’re attempting to achieve (e.g. streaming video).
Disclaimer: I am currently working for a startup attempting to build a video creation and distribution platform with global reach.
burntcaramel 670 days ago [-]
As an Australian, I agree that I usually prefer when a service is hosted nearby. Yet… 200ms latency, that’s pretty good actually. For some real data, I just tried `ping ec2.us-east-1.amazonaws.com` and time is 240ms. That’s in Tasmania, NBN over Wifi. I’m happy with that!
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.
sgt 670 days ago [-]
That puts things into perspective for us in South Africa*. My RTT to Europe is about 170-180ms. It used to be a bit better, not sure what happened. But the point is that it's just barely within what I would consider "fast" in relation to Europe.
(*) Similar to AU, we're also in the middle of "nowhere"
rozenmd 670 days ago [-]
It shows up if you need a CDN pretty clearly when you monitor uptime from around the world.
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)
sk0g 670 days ago [-]
Ironic for an Australian co's GitHub alternative to be less responsive than GitHub itself in Australia.
re-thc 670 days ago [-]
Add to that Github is also in the same region as Bitbucket.
670 days ago [-]
rozenmd 670 days ago [-]
GitHub appears to distribute their traffic between us-east and eu-central:
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
re-thc 669 days ago [-]
What happened to Tokyo? :(
rozenmd 670 days ago [-]
Actually I just built a tool to visualise this if you want to check it out:
Do they test full rendering time or only RTT? Also it would be useful to know IP addresses from which test request are being made. Tested a site hosted in Hetzner and got 135ms latency from Frankfurt which is unexpectedly high. Ping RTT from some US east networks to this site is around 120-150ms, how it shows the same latency within DE?
rozenmd 670 days ago [-]
Just RTT - it downloads the whole webpage content (equivalent of running curl <url>)
I run the checks via AWS Lambda for now, might put it somewhere more stable like Hetzner/DigitalOcean for better accuracy.
jwally 670 days ago [-]
I'm dense and just saw this. Its awesome fwiw!
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!
rozenmd 670 days ago [-]
That's actually a feature of the underlying platform I work on:
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.
londons_explore 670 days ago [-]
As a European, visiting the USA, you certainly find that most of the internet just works better.
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.
neurostimulant 670 days ago [-]
I usually get ~300ms ping from my home to us-east-1. You can absolutely feel the latency, especially on SPAs that performs many small xhr sequentially which compounds the latency even more. Apps that felt almost instant when used in network with <10ms latency are suddenly felt pretty sluggish.
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).
the_mitsuhiko 670 days ago [-]
I mostly notice edge hosted apps as a problem now. Some newfangled sites have horrible cold start times if they are not too busy in Europe.
rightbyte 670 days ago [-]
Oh the hubris of adding another level of indirection ... or maybe it is layer of abstraction. Not sure.
dncornholio 670 days ago [-]
Funny, I can pinpoint players location based on their pings pretty accurately too. 300ms + is Asia, 350+ is Australia, Americans are 120+, South America 170+.
Ping towards USA has lowered the most. This used to be 225ms in the earlier online days.
r24y 670 days ago [-]
This article brought to mind a different but related scenario. I live on an island that was recently affected by a typhoon. Internet speeds are usually pretty good, but in the aftermath of the storm cable internet has been up-and-down depending on the day, and the cell towers are very spotty. I've found that most modern apps depend on a high-speed connection, and give a very poor experience otherwise. Of course this seems obvious in hindsight, but it's a different experience living through it.
sargun 670 days ago [-]
AFAIK, there is no generic datastore that does multi-region, with moving around the leader for a given subset of data available. Something like what's written in the Spanner paper would be amazing (microshards, and moving around microshards based on user access) if it was accessible.
867-5309 670 days ago [-]
no mention, or realisation, of the storage and bandwidth requirements for hosting anything other than text. html, js and database queries are cheap to stick on a global CDN, but when it comes to larger multimedia files, such as images and videos, the costs soon skyrocket
withinboredom 670 days ago [-]
I remember when we first moved to the cloud from a datacenter. It was in us-east-1, and literally the day after the switch over (before we started configuring multi-region) was the first time us-east-1 had its major outage.
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.
lionkor 670 days ago [-]
If you want a smooth experience that is easy to set up, you can provide a download link (gasp) and serve that over a CDN, and just have your app be native.
You'll only pay for backend queries, not for every single button style
mduggles 670 days ago [-]
It’s a solvable problem if you optimize for multiple regions from day 1 of the app but migrating an existing stack to multi-region after the fact is often a large enough undertaking that you pick the region of the majority of users and go with it.
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.
Jamie9912 670 days ago [-]
Even if you have gigabit in Australia, the latency when browsing Youtube and clicking through menus is a world of difference when you compare it to the US
marcyb5st 670 days ago [-]
Is it the same while watching videos (i.e. a lot of buffering or similar)? I thought that YT caches popular content close to end users [1].
The tab of browser devtools that let you simulate slow connections should probably add simulation of this kind of latency, as well as a 'simulate AWS outage' toggle if that's even possible. (don't know enough DNS to know how hard the latter is)
I guessed from the title that this would focus on redundancy, but I guess that's rarely noticable.
makeworld 670 days ago [-]
> In reality, the ping you’ll experience will be worse, at around 215ms (which is a pretty amazing feat in and of itself - all those factors above only double the time it takes to get from Sydney to the eastern US).
Isn't it double just because ping measures round trip time?
josephcsible 670 days ago [-]
No, that was already accounted for. 52ms is the one-way time and 104ms is the round-trip time in the theoretical best case.
thih9 670 days ago [-]
There’s also the device speed. It might provide a different reference point for different users.
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).
jwally 670 days ago [-]
Does anyone know of an out-of-the-box solution for measuring regional latency? If not, please somebody make and productize it.
I'd love to know how my sites behave in Frankfurt, Mumbai, SF, Sydney, etc.
RGBCube 670 days ago [-]
Ngl, a website where you input a URL and it checks the latency around the world would be interesting. Bonus points for tying to guess where it's hosted.
Funny enough, the blog is not opening for me at all, despite being a static side, which should be proxied via CDN all the time.
reportgunner 670 days ago [-]
I think this is mainly a (first world) problem for americans using american websites when they are abroad.
670 days ago [-]
shubhamgrg04 670 days ago [-]
us-east-1 is the Silicon Valley of cloud regions. Overcrowded yet irresistible!
snailtrail 670 days ago [-]
[flagged]
aerio 670 days ago [-]
Sounds like you didn't read the article properly and missed the authors argument that using CDN's are more important than people think.
Better luck next time!
ketchupdebugger 670 days ago [-]
The author is not correct though, as with any webapp these are not static content that you can host on a cdn. These are dynamic content that needs to be loaded. Adding a mutliregion architecture is complicated.
As a side note, I also know which apps are hosted on us-east-1. I just need to look at the us-east-1 aws incident from last month and which apps were affected.
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.
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 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 of what? Images usually should be routed through a CDN which caches them directly in the user's country. It's extremely cheap and easy to set up. Nothing compared to running an application in multiple datacenters.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!
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
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.
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.
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.
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
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.)
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.
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.
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...
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.
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?
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.
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.
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.
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.
Cloudflare rejects about 2.5M search queries per day from bots. About ~20k make it through, and some of those are humans.
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.
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.
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).
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.
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.
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
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.
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...
https://entrackr.com/2022/11/exclusive-indian-isps-we-alread...
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.
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.
https://www.retro-gaming.it/videogiochi_img/movie_wargames/w...
> 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/...
[2] https://app-router.vercel.app/streaming/edge/product/1
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)
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
https://onlineornot.com/do-i-need-a-cdn?url=https://bitbucke...
I run the checks via AWS Lambda for now, might put it somewhere more stable like Hetzner/DigitalOcean for better accuracy.
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!
https://onlineornot.com/api-monitoring
If it doesn't quite match what you expect I'd be happy to add additional features!
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...?
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.
I believe that’s the source he’s using.
Better luck next time!
As a side note, I also know which apps are hosted on us-east-1. I just need to look at the us-east-1 aws incident from last month and which apps were affected.