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

61–70 of 109 posts

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

#61

Post by mmmpop »

aaaaaaaaaaab wrote: post #36
jen729w wrote: post #14

Earlier quoted context omitted.

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.

It's true but even without prefetching it's still fast as hell.

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

#62

Post by acdha »

kyle-rb wrote: post #52
acdha wrote: post #46

Earlier quoted context omitted.

Note that WebPageTest supports repeat tests for exactly this reason - that closes the browser and restarts it without clearing the cache. Here’s what that looks like - it helps the first render a lot (0.5 vs 1s) but the largest paint is still 7s: better than 11 but still pretty slow. https://www.webpagetest.org/result/220921_BiDcBJ_GQX/ One big thing to remember is that browser caching only works if you aren’t shippi…

Browser caching is nicer with service workers - you can use the cached version and load/install the updated version in the background, so that the user can get the updated version on their next refresh.

That’s a nice improvement but it still hits the cache size issues and it creates some hard problems you have to get right (“why didn’t reload fix it?”).

Not everyone has the resources to support that level of investment and there’s a pitfall in the middle where you get the costs but don’t see the desired benefits.

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

#63

Post by kitsunesoba »

modeless wrote: post #49
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…

Client-side rendering absolutely does make Twitter, in particular, slow. They used to do server side rendering for the initial load not that long ago, and it was so much faster than it is now. Night-and-day difference. I guess they just stopped caring. Someone probably got a promotion for launching the new thing.

Any time I have to use the Twitter site instead of Twitterrific on both desktop on mobile, the difference is huge. The site is a never-ending barrage of loading spinners.

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

#64

Post by superkuh »

It will certainly make the website more accessible to more people and reduce the load on their computers. This is required for government/public services. Look at how nice the UK NHS sites are. But for-profit corporations are free to, and seem to always, go the javascript application route because it is cheaper and easier to find teams to build them.

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

#65

Post by kbenson »

I wonder if one of the reasons we've seen a big push towards systems like this is because it does make the website faster, but in a way that's one step removed than we often consider it, or by a slightly different metric.

What if instead of client side load time, what's also being looked at is load time per finite server side compute resource? By dumbing down the server side to graphql JSON delivery + static JS, maybe that allows them to serve that specific need faster per 10k servers or something, and having to do the full page composition under heavy load server side just doesn't scale as well?

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

#66

Post by makeitdouble »

lowwave wrote: post #37
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 compani…

I see it as a rare case of "hate the players not the game"

I've come to rely a lot on gitlab and github's web interfaces through the years for diff and quickly navigate a specific commit, or a project I don't want to checkout. All the improvements coming from more JS and Ajax have been a boon to me. Sure I could do everything locally, but it's just so much more convenient.

Same for gmail as you mention it: I wouldn't go back to the previous web mail interfaces short of getting paid a living salary just for that. Same for banking web sites, which came such a long way.

The technology and trend is a net plus, advertising company coming to ruin whatever they can ruin is par for the course. I mean, looking at newspaper, TVs, Google Search, YouTube, Instagram, AppStore search etc....making anything it touches worse is in the ad business' DNA.

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

#67

Post by _gabe_ »

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.

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 Javascript. Additionally, you don't need to wait for the browser to deserialize the JS before it can start generating the HTML.

So the benefits of server side generation is no need to deserialize the code that generates the page and locality to the data. I'm guessing these two things are the biggest contributors to the speed ups.

I guess "server side rendering" is a bit of a misnomer, since you're not getting a rendered image, but rather a functional web page. It's possible I've misunderstood the whole SPA vs server side rendering arguments as well and my entire argument is invalid ¯\_(ツ)_/¯

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

#68

Post by bo1024 »

kbenson wrote: post #65

I wonder if one of the reasons we've seen a big push towards systems like this is because it does make the website faster, but in a way that's one step removed than we often consider it, or by a slightly different metric. What if instead of client side load time, what's also being looked at is load time per finite server side compute resource? By dumbing down the server side to graphql JSON delivery + static JS, mayb…

I wonder how much electricity Twitter is saving by running the scripts on their users' machines instead...

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

#69

Post by kbenson »

bo1024 wrote: post #68
kbenson wrote: post #65

I wonder if one of the reasons we've seen a big push towards systems like this is because it does make the website faster, but in a way that's one step removed than we often consider it, or by a slightly different metric. What if instead of client side load time, what's also being looked at is load time per finite server side compute resource? By dumbing down the server side to graphql JSON delivery + static JS, mayb…

I wonder how much electricity Twitter is saving by running the scripts on their users' machines instead...

I mean, yes. That's what I was getting at. It's cheaper to offload your compute to your users. It's probably much cheaper to offload a massive amount of compute onto billions of users.

They'll keep doing it until they're penalized in some fashion for doing so, if it's cheaper.

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

#70

Post by nicbou »

superkuh wrote: post #64

It will certainly make the website more accessible to more people and reduce the load on their computers. This is required for government/public services. Look at how nice the UK NHS sites are. But for-profit corporations are free to, and seem to always, go the javascript application route because it is cheaper and easier to find teams to build them.

The NHS has very different goals. Those are reflected in the standards they set for themselves. They must serve everyone, unlike big businesses who consider the edges of the bell curve too expensive to cater to.
Post reply on HN