Live data from Hacker News

Will serving real HTML content make a website faster?

blog.webpagetest.org

91–100 of 109 posts

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

#91

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.

While this is technically true, it's always been technically true, even when those in the religion of the SPA claimed it was clearly faster to use CSR over SSR. This is just realigning what many of us already knew, SSR is faster. If I may, the argument of "well... sure, but CSR can be plenty fast!" is redrawing the line after someone stepped over it.

Really it is a lot more about how much stuff you load than how you do it. CSR can at times provide savings, for instance by doing fake page changes and not having to load menus and stuff when the content changes. But of course you have to keep the JS light in order to not eat the savings.

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

#92

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

On mobile, I just checked out git.kernel.org.

It takes about 4s to load and does 2 or 3 jarring text reflows, I guess as fonts load or something.

It's also unreadable. Incredibly tiny text that would exhaust my eyes to parse within a few minutes.

And besides that... It's just text. Displaying text is easy. I'm sure this would be close to instant whatever framework you used, as long as it was coded well.

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

#93

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.

How far we've come that near-real-time multidimensional dynamic views onto multi-GB data stores is considered 'a pure document' by someone. Why, just because it uses links and URLs and instead of buttons and fetch?

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

#94

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…

Also, over-engineering web sites this way creates a lot of job security. Front-end development could probably warrant university courses all on its own.

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

#95
post #57

Earlier quoted context omitted.

While it does leave out server rendering time, that could not possibly account for several seconds of difference. TTFB could maybe be increased by 300-500ms… 1/10th of what gains are happening here

Why do you think the server can render it any faster than your computer? Server CPUs aren't all that much more powerful than desktops these days.

Some desktops? Sure.

But most of the desktops, notebooks, phones and tablets doesn't have 3GHz, 50Mb L2 processors coupled with Gb/Tbs of RAM and local (compared to the client requesting the page) storage.

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

#96
post #81

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…

> stop enabling "web developers" to do the things that make them slow It's been said countless times; but Slack, Discord, Youtube, Google Meets, Figma, Google Maps, Google Docs, Github, Excalidraw, Penpot, Diagrams.net etc. etc. are all web sites. They are a different class of websites than Hacker News or Project Gutenberg, being more apps than documents, but they are an important class, too; and they were all made p…

> being more apps than documents

Is “web application” not a common term anymore? Haven’t we always made the distinction between web apps and web sites?

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

#97
post #67

Earlier quoted context omitted.

I'm not OP, but I don't think the argument is even about rendering. The whole point of SPA, if I understand correctly, is to send the javascript/data and then dynamically create the web page client side (with minimal updates when data changes). Javascript is fast, but a server can dynamically generate HTML in any language. Most server side languages and/or frameworks will be written in faster languages than Javascrip…

Most server side languages and/or frameworks will be written in faster languages than Javascript. Lots(most?)of server side apps are python, ruby, php or javascript.

In the Stack Overflow survey it looks like the top 8 frameworks are all JS, C#,and Java. Flask, Django, Laravel and RoR start coming in after all these frameworks. So it looks like most server side apps are either JS or something faster like C# or Java.

Also this is if you check professionals. It's pretty similar for all respondents, but Flask and Django rise above spring and ASP.NET, although ASP.NET Core is still above those.

https://insights.stackoverflow.com/survey/2021#section-most-...

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

#98

Earlier quoted context omitted.

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.

HN, which is about as fast as sites get in my experience takes between 600ms and 800ms to fully load with cache disabled. Around 350ms to load just HTML and CSS.

IMO a few hundred milliseconds for something that is actually webapp-like rather than just an information website is quite reasonable.

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

#99

Earlier quoted context omitted.

> a few hundreds of ms Gotta be honest, I’m grimacing already. An order of magnitude too much.

HN, which is about as fast as sites get in my experience takes between 600ms and 800ms to fully load with cache disabled. Around 350ms to load just HTML and CSS. IMO a few hundred milliseconds for something that is actually webapp-like rather than just an information website is quite reasonable.

Notably, the examples in the OP article are slower by many thousands of ms, not just hundreds.

Either way, the post isn't saying you have to abandon app-like experiences. It's only about improving initial HTML delivery regardless of what you do after that.

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

#100

Earlier quoted context omitted.

> a few hundreds of ms Gotta be honest, I’m grimacing already. An order of magnitude too much.

HN, which is about as fast as sites get in my experience takes between 600ms and 800ms to fully load with cache disabled. Around 350ms to load just HTML and CSS. IMO a few hundred milliseconds for something that is actually webapp-like rather than just an information website is quite reasonable.

> HN, which is about as fast as sites get in my experience

We have different experiences. HN is light but it's not fast.

Post reply on HN