18 ms·

I don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe.

by TekMol 3y ago

I don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe. If you have users in Sydney, Australia ... ... you are floored at 104ms of latency for your request When I open AirBnB with a clean browser cache, it takes several seconds until I see something useful. Those 104ms of latency don't make a dent. Reddit takes over 5 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.

progval 3y 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 3y 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.
  - senttoschool 3y 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.
  - samwillis 3y 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 3y 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.
      - samwillis 3y 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.
  - raverbashing 3y 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 3y 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)
  - deleted 3y ago
    [deleted]
  - bandrami 3y 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 3y 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 3y 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.
- resonious 3y ago
  Do you think that's why Reddit takes 5 seconds to show a cookie banner?
- littlestymaar 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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.
bigbacaloa 3y ago
HN is an old fashioned text based thing with no bells or whistles whatsoever. Of course it's responsive.
- vjk800 3y ago
  Yet this is all I ask for as a user.
  - cypress66 3y ago
    In fact vastly superior to new reddit.
quickthrower2 3y ago
I think cloudflare is in front of HN these days
- TekMol 3y ago
  Have you thought about testing that assumption?
- kiwijamo 3y 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 3y ago
    ~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.
    - littlestymaar 3y 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 3y 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
vjk800 3y 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.
- yuuuuuuuu 3y 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 3y 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 3y 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 3y 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.
innocenat 3y 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.
flagged24 3y ago
This is why I don't buy the push to edge compute. There is often lower hanging fruit to be concerned about.
- dogleash 3y ago
  Hyped tech that lets someone feel like they're improving their product is a hell of a drug.
onion2k 3y ago
Those 104ms of latency don't make a dent. 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 3y ago
  Just a nit, but aren't DNS lookups going to be independent of distance to us-east-1?
  - onion2k 3y 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.
Cthulhu_ 3y 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.
arghwhat 3y 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 3y ago
  There is no reason why most sites can't return one pregenerated static HTML blob. The number of async requests is a killer.
  - deleted 3y ago
    [deleted]
  - hughesjj 3y 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.
    - 3y ago
rozenmd 3y 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: https://onlineornot.com/do-i-need-a-cdn?url=https://news.ycombinator.com https://onlineornot.com/do-i-need-a-cdn?url=https://news.yco...
- eXpl0it3r 3y ago
  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.
  - rozenmd 3y ago
    It's on AWS Lambda
  - selfhoster69 3y 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.
cdogl 3y 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.
heipei 3y 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 3y 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.
  - komon 3y 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?
  - quickthrower2 3y 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 3y 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.
ssss11 3y ago
I blame adtech without even knowing if it is the cause in each instance. Some news sites have like 50+ trackers lol.
015a 3y 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 3y 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.
  - 3y ago
aaron695 3y ago
[dead]
deleted 3y ago
[deleted]
bombela 3y 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.
ttepasse 3y 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. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#loading https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

by TekMol 3y ago

progval 3y 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 3y 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.
- senttoschool 3y 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.
- samwillis 3y 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 3y 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.
    - samwillis 3y 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.
- raverbashing 3y 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 3y 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)
- deleted 3y ago
  [deleted]
- bandrami 3y 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 3y 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 3y 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.
resonious 3y ago
Do you think that's why Reddit takes 5 seconds to show a cookie banner?
littlestymaar 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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.

bigbacaloa 3y ago

HN is an old fashioned text based thing with no bells or whistles whatsoever. Of course it's responsive.

vjk800 3y ago
Yet this is all I ask for as a user.
- cypress66 3y ago
  In fact vastly superior to new reddit.

quickthrower2 3y ago

I think cloudflare is in front of HN these days

TekMol 3y ago
Have you thought about testing that assumption?
kiwijamo 3y 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 3y ago
  ~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.
  - littlestymaar 3y 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 3y 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

vjk800 3y 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.

yuuuuuuuu 3y 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 3y 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 3y 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 3y 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.

innocenat 3y 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.

flagged24 3y ago

This is why I don't buy the push to edge compute. There is often lower hanging fruit to be concerned about.

dogleash 3y ago
Hyped tech that lets someone feel like they're improving their product is a hell of a drug.

onion2k 3y ago

Those 104ms of latency don't make a dent. 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 3y ago
Just a nit, but aren't DNS lookups going to be independent of distance to us-east-1?
- onion2k 3y 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.

Cthulhu_ 3y 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.

arghwhat 3y 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 3y ago
There is no reason why most sites can't return one pregenerated static HTML blob. The number of async requests is a killer.
- deleted 3y ago
  [deleted]
- hughesjj 3y 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.
  - 3y ago

rozenmd 3y 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: https://onlineornot.com/do-i-need-a-cdn?url=https://news.ycombinator.com https://onlineornot.com/do-i-need-a-cdn?url=https://news.yco...

eXpl0it3r 3y ago
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.
- rozenmd 3y ago
  It's on AWS Lambda
- selfhoster69 3y 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.

cdogl 3y 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.

heipei 3y 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 3y 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.
- komon 3y 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?
- quickthrower2 3y 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 3y 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.

ssss11 3y ago

I blame adtech without even knowing if it is the cause in each instance. Some news sites have like 50+ trackers lol.

015a 3y 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 3y 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.
- 3y ago

aaron695 3y ago

[dead]

deleted 3y ago

[deleted]

bombela 3y 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.

ttepasse 3y 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. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#loading https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...