Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will serving real HTML content make a website faster?

blog.webpagetest.org

Post reply on HN
Print view View original

31–40 of 109 posts

Re: Will serving real HTML content make a website faster?

#31

Post by Cyberdog »

epolanski wrote: post #19
vxNsr wrote: post #4

This basically just tells us what we already know, SSR is faster for the client usually

I don't think it necessarily is. You do get better LCP and FCP but other metrics suffer (time to interactive, TTFB and several other metrics are primary examples). It's a compromise, and hydration is a huge performance hit. (I work on performance of a SSR ecommerce)

"Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site is to display content (Reddit, Twitter, pretty much everything else). If I (resentfully) click on a Reddit link on a SERP, I'm going there to read the content, not to flip open menus or whatever.

"Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.

Re: Will serving real HTML content make a website faster?

#32

Post by morelisp »

nicoburns wrote: post #13
NohatCoder wrote: post #7

Time for a hot take: You don't need to make your website fast, all you have to do is not make it slow in the first place. Partially or fully generating a web site client side can be plenty fast, the slowness tends to come from using some bloated framework to do so.

In my experience, it's not even the framework that's the problem. Client-side rendered React is plenty fast for example. Not as fast as server-rendered (or even better, static) HTML, but fast enough (measured in a few hundreds of ms) that you won't notice the difference. It's generally things like loading lots of 3rd party scripts, or not paying to how many network roundtrips are required on the critical loading path…

> a few hundreds of ms

Gotta be honest, I’m grimacing already. An order of magnitude too much.

Re: Will serving real HTML content make a website faster?

#33

Post by [deleted] »

jen729w wrote: post #14
kmeisthax wrote: post #9

I remember when single-page applications were all the rage. I was highly skeptical that they could beat just loading HTML, given that the performance benefits were all predicated upon amortizing the initial load cost over many page requests. It's a very risky bet given that a lot of sites don't have a lot of repeat traffic to begin with, unless you just so happen to be an application in the guise of a website. Appare…

As usual, it depends. I just tested my own site, which I built using Gatsby — a JS framework — and https://astro.build , whose entire schtick is that they deliver as little JS to the page as possible. (Because I’m thinking of rebuilding my site using Astro. But that’s not relevant here.) In the default test, my page loaded in 1.6s and Astro in 1.9s. In the ‘not bad’ ratings below the main figures, my site fared bette…

[deleted]

Re: Will serving real HTML content make a website faster?

#34

Post by imachine1980_ »

nicoburns wrote: post #13
NohatCoder wrote: post #7

Time for a hot take: You don't need to make your website fast, all you have to do is not make it slow in the first place. Partially or fully generating a web site client side can be plenty fast, the slowness tends to come from using some bloated framework to do so.

In my experience, it's not even the framework that's the problem. Client-side rendered React is plenty fast for example. Not as fast as server-rendered (or even better, static) HTML, but fast enough (measured in a few hundreds of ms) that you won't notice the difference. It's generally things like loading lots of 3rd party scripts, or not paying to how many network roundtrips are required on the critical loading path…

or loading everithing instead of lazy loding the images or use 3mb image instead of kb webp

Re: Will serving real HTML content make a website faster?

#35

Post by lmm »

Cyberdog wrote: post #31
epolanski wrote: post #19

Earlier quoted context omitted.

I don't think it necessarily is. You do get better LCP and FCP but other metrics suffer (time to interactive, TTFB and several other metrics are primary examples). It's a compromise, and hydration is a huge performance hit. (I work on performance of a SSR ecommerce)

"Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site is to display content (Reddit, Twitter, pretty much everything else). If I (resentfully) click on a Reddit link on a SERP, I'm going there to read the content, not to flip open menus or whatever. "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the conten…

> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.

Not necessarily. If you "load" the page but it doesn't do what it should when I click on it, that can be much more frustrating to the human than taking a little longer to load but being fully functional when you do. The assumption that anything that isn't HTML is "bells and whistles" is pretty dubious (as is the converse assumption that everything in the HTML is valuable).

Re: Will serving real HTML content make a website faster?

#36

Post by aaaaaaaaaaab »

jen729w wrote: post #14
kmeisthax wrote: post #9

I remember when single-page applications were all the rage. I was highly skeptical that they could beat just loading HTML, given that the performance benefits were all predicated upon amortizing the initial load cost over many page requests. It's a very risky bet given that a lot of sites don't have a lot of repeat traffic to begin with, unless you just so happen to be an application in the guise of a website. Appare…

As usual, it depends. I just tested my own site, which I built using Gatsby — a JS framework — and https://astro.build , whose entire schtick is that they deliver as little JS to the page as possible. (Because I’m thinking of rebuilding my site using Astro. But that’s not relevant here.) In the default test, my page loaded in 1.6s and Astro in 1.9s. In the ‘not bad’ ratings below the main figures, my site fared bette…

>Now that my page is loaded, Gatsby does some neat pre-loading on hover of links. So clicking around my site is literally instantaneous.

*Except with touch-based interfaces. Which are the majority of browsers today.

Re: Will serving real HTML content make a website faster?

#37

Post by lowwave »

1vuio0pswjnm7 wrote: post #29

There could be a companion article: "Will Consuming Only Real HTML Content Make A Website Faster? Let's Experiment!" Having myself run this "experiment" for many years now by (a) controlling DNS so that only the domain in the "address bar" URL is resolved^1 and (b) making HTTP requests using a TCP client and/or an unpopular nongraphical web browser that only processes HTML and does not perform auto-loading of resourc…

> IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.

yeah as one those developers who jumped on the processing everything on the client/browser side, and supported all the browser having fancy JS features when ajax first popularised by gmail, I have come to regretted my decision. Especially with all the standards proposed by an advertising companies, the user/consumers don't really benefit from the usage of the web.

Re: Will serving real HTML content make a website faster?

#38

Post by nescioquid »

jokoon wrote: post #25

It's really funny because I asked on stack exchange why websites are slower than apps, my question for removed for being opinion based, and I got an answer about hydration. In my view, the dom should be made obsolete, and there should be tighter restrictions, by making things immutable, or just completely redesigning how the dom works. I'm not an expert, but the dom smells very weird.

The protocol and the document object model essentially assumed a static world. It's amazing what we've cobbled on top of an essentially stateless mode of encoding/structuring and accessing documents.

Why stop at the dom? Why not the protocol too?

Re: Will serving real HTML content make a website faster?

#39

Post by Cyberdog »

lmm wrote: post #35
Cyberdog wrote: post #31

Earlier quoted context omitted.

"Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site is to display content (Reddit, Twitter, pretty much everything else). If I (resentfully) click on a Reddit link on a SERP, I'm going there to read the content, not to flip open menus or whatever. "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the conten…

> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that. Not necessarily. If you "load" the page but it doesn't do what it should when I click on it, that can be much more frustrating to the human than taking a little longer to lo…

If the purpose of your site is to show content to a human, then anything on the page that isn't the content the human wants to see is bells and whistles. I will die on this hill.

Re: Will serving real HTML content make a website faster?

#40

Post by pragmatic »

thwarted wrote: post #11

A point of comparison should be to git.kernel.org, which loads and renders instantly (at least compared to all these other sites), contains a massive amount of actual content per page, is highly cacheable on the server, and uses exactly zero javascript while remaining usable (for its use case at least, which is all links and little form interaction (only the search box)).

Imagine a spectrum from document to application (from left to right).

This is the almost fully left as a pure document with low interactivity.

Applications are much harder to cache and start up fast.

Post reply on HN