Hacker News new | ask | show | jobs
by arghwhat 1091 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.

3 comments

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

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.