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)).
Will serving real HTML content make a website faster?
11–20 of 109 posts
Re: Will serving real HTML content make a website faster?
#12The large failing with this test is that it assumes the time to get the relevant page data from the database and render it to HTML is 0. If Twitter had your feed ready to go from its cache this might be accurate, but realistically I would give the server a few seconds to do its work since the site is so personalized.
As the article says, the first example in the post does include the time that it takes to go out and fetch the static HTML that swaps in, and it added about a second to the server response of the experiment run that doesn't show up in the control run. For a big distributed site, a second may be more time than it would really take to put together a dynamic response. Even with that 1-second additional delay included th…
I agree that server rendered would be faster, just the article had presented the absolute best-case scenario for the server. That said there could be other tradeoffs at play. Maybe loading the JavaScript and requesting a small amount of JSON each page is faster loading the initial page and then scrolling 10 pages down is faster than the server rendering out each page and appending it to the end.
Re: Will serving real HTML content make a website faster?
#13Time 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 which make it slow.
Re: Will serving real HTML content make a website faster?
#14I 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 better.
Now that my page is loaded, Gatsby does some neat pre-loading on hover of links. So clicking around my site is literally instantaneous. The same is not true of Astro, where every click is a classic HTTP request.
I am not judging Astro. That’s not the point of this post. I’m no Gatsby fanboy, I think it’s horribly over-complicated. I’m just saying. It’s complicated.
Re: Will serving real HTML content make a website faster?
#15Shouldn't we have more devices and more connection types to have a more controlled experiment? It's always 4G, mobile Chrome and I assume the same device. Very likely same carrier at the same place, so roughly same connection conditions in terms of latency DL/UL bandwidth and jitter. Also always the same device with same CPU/GPU. Perhaps a flagship new shiny phone with a superfast SoC which gives a headstart to faste…
Measuring the speed of a page rendered on an iPhone 14 on an mmWave 5G connection a foot from an antenna is not a worthwhile test. If it takes 5 seconds for Twitter to load a tweet (which it does on my iPhone 12 Pro on WiFi) is that somehow better? A tweet, famously limited to 140 characters takes 5 seconds to load?
A news article or tweet takes way too long to load on my phone, it's just ludicrous that on a mid-range phone and connection it would take 45 seconds! A copy of Frankenstein[0] (~78k words) weighs in at 463KB. A random CNN article or tweet is not a damn copy of Frankenstein. There's no reason either should take more than a second to load and render.
An HTML document with a bare minimum CSS to not be ugly has enough information to render and be useful to a user. It can do that with a single request to a server. At minimum the same page rendered with JavaScript needs two connections to a server. It's also got a higher minimum threshold for displaying something to the user because the JavaScript needs to be downloaded, parsed, interpreted/JIT, then requests for useful resources made. All to do things a browser will already do for free.
There's full JavaScript applications that can't be built with just HTML and CSS. Of course they need to load and run the JavaScript. A tweet or news article are not applications. They do not need to load the equivalent of copies of Doom to display a dozen paragraphs of text or just 140 characters of text. The modern web's obsession with JavaScript everywhere is asinine.
Re: Will serving real HTML content make a website faster?
#16Time 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
You absolutely do, even setting aside UX and accessibility benefits, there's a huge impact in SEO as web core vitals impact seo a lot.
If you are in a niche business or have no competition, then this argument is weaker of course and you're left with the previous 2.
Re: Will serving real HTML content make a website faster?
#17Shouldn't we have more devices and more connection types to have a more controlled experiment? It's always 4G, mobile Chrome and I assume the same device. Very likely same carrier at the same place, so roughly same connection conditions in terms of latency DL/UL bandwidth and jitter. Also always the same device with same CPU/GPU. Perhaps a flagship new shiny phone with a superfast SoC which gives a headstart to faste…
4G on a Moto is basically the worst case scenario but also how half the world interacts with the internet at large. If you're going to pick one scenario that describes a lot of users, they're pretty much dead on.
I think 4G doesn't tell the whole story, especially in several businesses that target users in specific conditions (e.g. tourism, where your users have poor unstable 4g) or specific markets withpoor avera8ge mobile connections.
Re: Will serving real HTML content make a website faster?
#18This page is serving me a recursive stream of Captchas, as pudgetsystems reviews the security of my connection; not a great look for the topic alluded to in the headline.
Re: Will serving real HTML content make a website faster?
#19This 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)
Re: Will serving real HTML content make a website faster?
#20Time 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 You absolutely do, even setting aside UX and accessibility benefits, there's a huge impact in SEO as web core vitals impact seo a lot. If you are in a niche business or have no competition, then this argument is weaker of course and you're left with the previous 2.
The commenter you're replying to would likely agree - the comment's point isn't about the value of speed, it's that by default pages are fast, and it takes deliberate (but ubiquitous) deviations from the rendered HTML to slow it down.