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

81–90 of 109 posts

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

#81

Post by azangru »

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…

> 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 possible because web developers were enabled, through various browser apis, to build them; and I am grateful for that. Wishing that web developers were not enabled to build complex things on the web is inconceivable to me. It's the culture and the education around web development that should change; not the enablement of web developers.

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

#82

Post by jeroenhd »

kyle-rb wrote: post #44

These types of tests tend to be unfair to actual web apps, since they only really account for first-time-use. Twitter is slow in this experiment because it has to load a bunch of JavaScript up front. But that's not the case in practical use! Twitter uses service workers and HTTP cache headers (e.g. `expires`) to make sure that most non-first-time-users aren't actually loading most things every time. Client-side rende…

I've been using Nitter rather than Twitter for a while now, at least for reading tweets. A submit feature and SSE/a websocket listening for new posts would not kill Nitter's performance if that were its intentions to implement but the difference between the two is night and day.

Twitter is the slowest website I come back to after Reddit. It's a hot mess and the fully loaded web app isn't any faster. Yes, the megabytes of content being loaded for rendering 280 characters aren't indicative of web app performance, but clicking through to the main app is still slow and unreliable. My old phone used to get hot from the Twitter web app for no real good reason. There's less than a kilobyte of content in a tweet yet I have constant issues with getting all images to load when they come into view or scrolling back up without having the content jump around because some recommendations block decided it exists again now.

Getting faster devices solved Twitter's problems for me for a while but it's still ridiculous if you open Nitter and compare the performance. It's a clear example of what's wrong with modern web development because the "traditional" design of Nitter does everything I want it to do and 90% of what most people want it to do (needs tweets, DMs to become interactive) at a fraction of the load time.

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

#83

Post by epolanski »

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 interactive" and "time to first byte" are pointless numbers if the purpose of your site

They matter for SEO.

> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve.

Satisfaction varies. TTI is a relevant metric. E.g. On our ecommerce it takes less than 10 seconds to load the entire page (sub 5 for most pages), but then the user can literally do nothing till all hydration has happened and executed which is simply not a great experience.

Our users, if using the website through slower connections/devices are looking at 40 seconds + delays before they can do anything meaningful, that's unacceptable.

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

#84

Post by NohatCoder »

bachmeier wrote: post #28
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.

> You don't need to make your website fast, all you have to do is not make it slow in the first place. This requires testing. Which is, apparently, something most companies don't know how to do correctly.

Actually no, the point is if you don't put in anything that potentially makes the website slow you can be reasonably certain that it isn't. Obviously you still want to test the website, but it is not like this path is particularly test demanding.

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

#85

Post by youngtaff »

jedberg wrote: post #57
jlembeck wrote: post #56

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.

Caching… either of the whole page or parts of it (at various layers) is one reason

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

#86

Post by 1vuio0pswjnm7 »

throwaway742 wrote: post #76
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…

What browser do you use?

For reading HTML, I use various versions of links 1.x and links 2.x, patched to meet personal preferences. Of course links can make HTTP requests, as well as display HTML, but I use a variety of programs to make HTTP requests. When I use links to make HTTP requests, it is always through a loopback-bound proxy.

For commercial use of the www of course I am forced use a popular graphical web browser like everyone else. But I make minimal commercial use of the www. Most www use for me is academic or recrerational.

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

#87

Post by NohatCoder »

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…

I'd put it like this, sometimes the framework culture does a lot more damage than the framework itself.

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

#88

Post by pjc50 »

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.

You cannot obsolete web browser features. That is simply not going to happen because of the long tail of devices. I'm not sure how you'd want to redesign the DOM, but you can't do that in a backwards-incompatible way either.

You could probably speed up pages significantly by introducing deferred rendering to the DOM, but: backwards incompatible change.

(That was my answer about hydration that you didn't like)

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

#89

Post by no_time »

>a team may deem the initial performance impact of JS-dependence a worthy compromise for benefits they get in other areas, such as personalized content, server costs and simplicity, and even performance in long-lived sessions

notice how all these "benefits" only benefit the developer at the expense of the user or have nothing to do with the problem at hand. "personalized content"? really?

Pre client side Youtube,Twitter,FB,Reddit were all superior feats of engineering to their modern JS heavy counterparts.

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

#90

Post by NohatCoder »

imachine1980_ wrote: post #34
nicoburns wrote: post #13

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…

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

You have to be careful with the lazy loading, sometimes it ends up being just more round trips. And then there are those annoying sites that refuse to load anything that is off screen, and you end up having to wait over and over again.
Post reply on HN