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

41–50 of 109 posts

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

#41

Post by radicalriddler »

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…

I'm pretty new to Astro, but I did see this official plugin https://docs.astro.build/en/guides/integrations-guide/prefet... which I believe does what you're looking for.

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

#42

Post by kayodelycaon »

zozbot234 wrote: post #26
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.

Newer frameworks like Svelte or SolidJS are a lot less bloated on the client. Though we're still far from successfully minimizing the amount of network roundtrips involved in a SPA update, so there's plenty of room for improvement still.

I like what Ruby on Rails 7 has done with Hotwire and Stimulus. All html is rendered server side. If you need client side interactions, you can mount lightweight components using plain JavaScript.

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

#43

Post by lmm »

Cyberdog wrote: post #39
lmm wrote: post #35

Earlier quoted context omitted.

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

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

Sure, but a) the purpose is rarely just to show content, one of the great strengths of the web is interactivity. b) often a lot of what's in the HTML (and especially the CSS) isn't the content the human wants to see.

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

#44

Post by kyle-rb »

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 rendering isn't the thing that's slow here, it's mostly the re-downloading of the rendering code every time when that's not realistic.

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

#46

Post by acdha »

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…

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 shipping updates frequently (bundlers have been an anti-pattern for many sites for the last few years) and aren’t storing too much. On mobile in particular a lot of sites load enough junk that they fall out of the cache. I use Twitter only via their web app and the page load time on a fast iPhone is still like 10 seconds or worse, when a well-optimized HTML page can be in the hundred of milliseconds.

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

#47

Post by wubsitesgood »

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…

For what it's worth, Twitter has gone back and forth on this. They did serve useful HTML up-front in the recent past. It was faster for initial delivery and I'd imagine helped the odd person who was sent a link to a tweet and hadn't loaded the site in a while.

Other sites in the article fit a traditional website model where folks commonly land on pages from search results, but they're still very JS dependent for content. CNN and FedEx etc

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

#48

Post by jen729w »

radicalriddler wrote: post #41
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…

I'm pretty new to Astro, but I did see this official plugin https://docs.astro.build/en/guides/integrations-guide/prefet... which I believe does what you're looking for.

Oh sweet, cheers!

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

#49

Post by modeless »

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.

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

#50

Post by sbdncuvh »

pragmatic wrote: post #40
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.

No post body was provided.
Post reply on HN