Hacker News Reader

Comment by TekMol | Hacker News Reader

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.

View on HN

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.

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.

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.

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

I'm on another hemisphere, diff continent (Africa) and closeish to the south pole. And even for me HN is very fast.

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.

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.

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.

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!

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

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

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.

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.

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.

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

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.

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.

The original Space Jam (1996) site does this for navigation (and it still works fine): https://www.spacejam.com/1996/cmp/jamcentral/jamcentralframe...

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.

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.

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.

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.

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

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

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

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.

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

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.

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

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.

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.

>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

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

They do, look up the “Backend for Frontend” pattern.

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

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

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?

I am 99% sure you could solve this with a media query and some CSS totaling no more than 1KB.

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

Waiter: "And your spoon, sir."

You: "What the fuck."

If the waiter prioritized the spoon request, you could start eating a lot sooner.

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.

as the content within the bowl move around as it continues to load

“RE:RE:RE:RE:RE:RE:RE:CHECK THIS OUT ABOUT MODERN WEB DEV LOL!”

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.

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

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

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

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?

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.

Fair point, but even high end users have bad connection sometimes.

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.

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.

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.

The SV techbros should have to test their sites on 2010-era notebooks running through two VPNs connecting through Australia and Finland.

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.

There is no reason why most sites can't return one pregenerated static HTML blob. The number of async requests is a killer.

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.

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.

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.

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.

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.

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?

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.

Oh that's right! Thanks for clearing it up for me :) That does make more sense

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

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.

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.

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?

Is that CDN or DDOS protection? CDN should serve static assets near the user. Has to be quicker unless something went very wrong.

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.

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.

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.

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.

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.

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.

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.

I for one agree with both of you.

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.

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

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)

Sadly nowadays sites will send javascript which contains a request to fetch more javascript which contains a request to fetch more javascript which renders an html element which... wait for it... requests more javascript. This sounds like it's an exaggeration but no.

At least on newer browsers we're no longer universally loading a javascript interpreter written in javascript (though sometimes we still are!)

A lot of the JS calling for more JS is third party services that don't block render.

For web apps, what matters most is above the fold load speed + time to interactive.

In the era when React got popular but Next.js hasn't yet, we had really slow performing sites because it did exactly what you said. Then people finally figured out that pure client-side rendering apps are too slow so people started switching to server 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.

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.

Do you think that's why Reddit takes 5 seconds to show a cookie banner?

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

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

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.

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.

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.

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.

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.

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

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.

It's on AWS Lambda

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.

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

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.

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

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

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.

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

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.

> 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/im...

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.

Just a nit, but aren't DNS lookups going to be independent of distance to us-east-1?

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.

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.

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

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.

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

Yet this is all I ask for as a user.

In fact vastly superior to new reddit.

I think cloudflare is in front of HN these days

Have you thought about testing that assumption?

It is not. A simple traceroute shows traffic from Auckland, New Zealand is routed all the way to the San Diego via Los Angeles. Cloudflare sites typically have traceroutes terminating here at Auckland (best case scenario) or in some cases across the pond in Sydney, Australia.

It is interesting to note however I don't observe much latency issues despite a 130ms round trip.

~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.

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

> 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

Reply on news.ycombinator.com