5 ms·

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hit

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

MatthiasPortzel 3y ago
Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.
- leecb 3y ago
  > taking over 500ms and a complete page reload For me this is 45ms to transfer the 2 kB (compressed) of HTML; the whole process takes under 60ms total, which is pretty darn close to "instantaneous" for the "complete page reload." EDIT: I'm in Texas, so most of this time is probably just round trip time to the west coast.
- icedchai 3y ago
  Where are you located? It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.
  - MatthiasPortzel 3y ago
    It may be <100ms, but that completely misses my point. My point is that it could be <1ms, and no reload, if the Reply box was added in JavaScript to the previous page.
- tedunangst 3y ago
  Gives you more time to think about your reply. The fact that people on other sites comment in less than 500ms could be considered a negative.
ninepoints 3y ago
I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even accurately track the navigation stack. Sure it loads quickly, but we can load a hello world in a p tag pretty quickly too. HN as a site is a perfect example of how bad a SSR experience can be.
- arielcostas 3y ago
  Don't know who built this site or how old it is, but the UX is definitely sub-par compared to many other server-rendered sites. Submitting a form and losing the scroll position doesn't happen in every site, even if the page gets reloaded. And the font thing is more of a CSS problem than a SSR/client-rendering problem.
  - quaintdev 3y ago
    Maybe it's time to implement this site Ux with htmx
  - illwrks 3y ago
    A lot of it could be improved with some CSS changes (scaling etc) as a sprinking of javascript which could handle commenting without reloads. My opinion is that it's perfect for what it is, a discussion board and nothing more. It's not a social media site.
    - pc86 3y ago
      Not that this should be the answer, but there are a lot of HN browser plugins. Most have at least some level of theming and inline commenting. I'm currently a fan of Refined Hacker News (no affiliation) - https://github.com/plibither8/refined-hacker-news https://github.com/plibither8/refined-hacker-news - but I'm sure there are others just as good out there.
la_fayette 3y ago
To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...
- Phrodo_00 3y ago
  If you're talking about static sites, wordpress definitely isn't it, it renders server side every request. (Google's Blogger.com used to be static, not sure about now). HN is likely not static either.
- traverseda 3y ago
  I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cache instead of generating a page for you. A cache is not a static site, although maybe next.js is redefining the term, I don't know. Get off my lawn.
  - michaelmior 3y ago
    SSG long predates Next.js. It was by no means the first, but I wrote something that I think could be called a SSG (not the term I used at the time) back in 2010 while the first release of Next.js wasn't until 2016. [0] https://michael.mior.ca/blog/designing-an-offline-cms/ https://michael.mior.ca/blog/designing-an-offline-cms/
    - traverseda 3y ago
      Sure, static html sites have existed forever, but I don't know when the term "SSG" was popularized. I assume it was pretty recently all things considered.
  - la_fayette 3y ago
karmakaze 3y ago
Mostly true--the hn.js would indicate otherwise: function vote (id, how, auth, _goto) { ... $('unv_' + id).innerHTML = unv; new Image().src = vurl(id, how, auth, _goto); }
- garbageoverflow 3y ago
  Sorry, could you point me to the piece of code that requests all comments via an API and renders them accordingly?
robertoandred 3y ago
Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.
- Maxion 3y ago
  And the complexity of the application, which isn't always up to the developer.
- bob1029 3y ago
  Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request. I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.
  - michaelmior 3y ago
    > Information-theoretic, there is no way you can beat SSR in this scenario. I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything. That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.
  - nfw2 3y ago
    Not always. SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive. I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.

MatthiasPortzel 3y ago

Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.

leecb 3y ago
> taking over 500ms and a complete page reload For me this is 45ms to transfer the 2 kB (compressed) of HTML; the whole process takes under 60ms total, which is pretty darn close to "instantaneous" for the "complete page reload." EDIT: I'm in Texas, so most of this time is probably just round trip time to the west coast.
icedchai 3y ago
Where are you located? It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.
- MatthiasPortzel 3y ago
  It may be <100ms, but that completely misses my point. My point is that it could be <1ms, and no reload, if the Reply box was added in JavaScript to the previous page.
tedunangst 3y ago
Gives you more time to think about your reply. The fact that people on other sites comment in less than 500ms could be considered a negative.

ninepoints 3y ago

I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even accurately track the navigation stack. Sure it loads quickly, but we can load a hello world in a p tag pretty quickly too. HN as a site is a perfect example of how bad a SSR experience can be.

arielcostas 3y ago
Don't know who built this site or how old it is, but the UX is definitely sub-par compared to many other server-rendered sites. Submitting a form and losing the scroll position doesn't happen in every site, even if the page gets reloaded. And the font thing is more of a CSS problem than a SSR/client-rendering problem.
- quaintdev 3y ago
  Maybe it's time to implement this site Ux with htmx
- illwrks 3y ago
  A lot of it could be improved with some CSS changes (scaling etc) as a sprinking of javascript which could handle commenting without reloads. My opinion is that it's perfect for what it is, a discussion board and nothing more. It's not a social media site.
  - pc86 3y ago
    Not that this should be the answer, but there are a lot of HN browser plugins. Most have at least some level of theming and inline commenting. I'm currently a fan of Refined Hacker News (no affiliation) - https://github.com/plibither8/refined-hacker-news https://github.com/plibither8/refined-hacker-news - but I'm sure there are others just as good out there.

la_fayette 3y ago

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...

Phrodo_00 3y ago
If you're talking about static sites, wordpress definitely isn't it, it renders server side every request. (Google's Blogger.com used to be static, not sure about now). HN is likely not static either.
traverseda 3y ago
I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cache instead of generating a page for you. A cache is not a static site, although maybe next.js is redefining the term, I don't know. Get off my lawn.
- michaelmior 3y ago
  SSG long predates Next.js. It was by no means the first, but I wrote something that I think could be called a SSG (not the term I used at the time) back in 2010 while the first release of Next.js wasn't until 2016. [0] https://michael.mior.ca/blog/designing-an-offline-cms/ https://michael.mior.ca/blog/designing-an-offline-cms/
  - traverseda 3y ago
    Sure, static html sites have existed forever, but I don't know when the term "SSG" was popularized. I assume it was pretty recently all things considered.
- la_fayette 3y ago

karmakaze 3y ago

Mostly true--the hn.js would indicate otherwise: function vote (id, how, auth, _goto) { ... $('unv_' + id).innerHTML = unv; new Image().src = vurl(id, how, auth, _goto); }

garbageoverflow 3y ago
Sorry, could you point me to the piece of code that requests all comments via an API and renders them accordingly?

robertoandred 3y ago

Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.

Maxion 3y ago
And the complexity of the application, which isn't always up to the developer.
bob1029 3y ago
Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request. I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.
- michaelmior 3y ago
  > Information-theoretic, there is no way you can beat SSR in this scenario. I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything. That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.
- nfw2 3y ago
  Not always. SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive. I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.