10 ms·

Will serving real HTML content make a website faster?

186 points by tkadlec 4y ago

IYasha 4y ago
JS queries are tools of Satan! Today web 2.0 uses 1000% faster machines to make web experience 100% slower! What an age! PS: thank you for calling HTML HTML!
can16358p 4y ago
Shouldn'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 faster JS execution? Or perhaps a very spotty barely 1-bar 4G connection. (Just assumptions, maybe both are false, but you get the idea) I'm a bit fan of client-side generation using JS too but I don't think this experiment is exhaustive of many practical scenarios. If we see more connection types and more variety of devices with different CPUs then it'd be more convincing.
- Veliladon 4y ago
  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.
  - epolanski 4y ago
    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.
- wubsitesgood 4y ago
  Some of the tests in the article are run on Desktop Chrome using a "cable" connection speed instead of 4G, which looks to have about a 6x faster round trip time than their 4G does. Those results are a little less impactful but still significant (many seconds faster still in some metrics). More testing environments would make the results more or less significant, as you'd expect. In ideal browsing conditions, the impact will be more minor, and in the spotty barely 1-bar connection you mention, the difference would be much more dramatic than the 4G examples in the post.
- giantrobot 4y ago
  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. [0] https://www.gutenberg.org/ebooks/84 https://www.gutenberg.org/ebooks/84
vxNsr 4y ago
This basically just tells us what we already know, SSR is faster for the client usually
- epolanski 4y ago
  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)
  - Cyberdog 4y ago
    "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 content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.
    - lmm 4y ago
      > "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 load but being fully functional when you do. The assumption that anything that isn't HTML is "bells and whistles" is pretty dubious (as is the converse assumption that everything in the HTML is valuable).
      - Cyberdog 4y ago
        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.
megaman821 4y ago
The 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.
- makapuf 4y ago
  OK but you could maybe render static html frames and fill placeholders with pre rendered html as soon as it is available? (A bit like htmx can do)
- wubsitesgood 4y ago
  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 though, the improvement in that first test is still large (over 8 seconds faster in those tests). If the experiment took a few seconds longer on the server, it still would be 5 or 6 seconds faster to render content than the control.
  - megaman821 4y ago
    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.
NohatCoder 4y ago
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.
- nicoburns 4y ago
  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.
  - morelisp 4y ago
    > a few hundreds of ms Gotta be honest, I’m grimacing already. An order of magnitude too much.
    - Existenceblinks 4y ago
      For me, generally sub 100ms is acceptable. a few hundreds .. No thanks html over the socket is faster than that.
    - nicoburns 4y ago
      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.
      - wubsitesgood 4y ago
        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.
kmeisthax 4y ago
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. Apparently my skepticism has been validated.
- jen729w 4y ago
  As usual, it depends. I just tested my own site, which I built using Gatsby — a JS framework — and https://astro.build 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.
  - deleted 4y ago
    [deleted]
  - P5fRxh5kUvp2th 4y ago
    I bet it could be rewritten to feel instantaneous as well. it's a common misconception that SSR implies no XHR at all. That's never been true except prior to IE5 adding the technique for outlook.
    - Spivak 4y ago
      SSR doesn't mean no XHR, it usually just means that change in route means round trip to the server. If you're doing SSR only for the initial page load then it's typically called hydration.
thwarted 4y ago
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)).
- klysm 4y ago
  The ui is not that functional compared to other git front ends.
- pragmatic 4y ago
  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.
  - sbdncuvh 4y ago
  - morelisp 4y ago
    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?
    - pvillano 4y ago
      Yes, in the current context of the need for client side rendering.
      - morelisp 4y ago
        No, you've assumed the question. "Applications are much harder to cache and start up fast" because you're defining "applications" to intentionally exclude architectures which are cachable and fast to start. If I shipped a git repo viewer as an executable, nobody would be asking why it's not rather a txt/doc/PDF. It's unquestionably an application, not a document.
the__alchemist 4y ago
This 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.
smm11 4y ago
I'd been thinking that 5G is a thing only because the IOT is a thing. It had nothing to do with phones, but the build-out is funded by phones. So when it all settles down, phones will be as slow as they were in the 3G era, at best, what with so much stuff clamoring for data. Plain Jane HTML is going to save us.
- stjohnswarts 4y ago
  I've seen this with my telco provider with 5G, full bars and it is still almost unusable. replace people with IOT devices pinging and sending tiny messages constantly it's gonna be rough :)
jokoon 4y ago
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.
- nescioquid 4y ago
  The protocol and the document object model essentially assumed a static world. It's amazing what we've cobbled on top of an essentially stateless mode of encoding/structuring and accessing documents. Why stop at the dom? Why not the protocol too?
- pjc50 4y ago
  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)
1vuio0pswjnm7 4y ago
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 resources. No images, JS, CSS, etc. The answer to the question is yes. This "makes a website faster", or, more specifically, as someone else in the thread has stated, it does not make the website slow. It does not accomodate the practices of "web developers" that slow a website down. But most importantly, IMO, it makes "website speed", not to mention appearance, more consistent across websites. Good luck achieving any semblance of that with a popular graphical web browser. Most web pages submitted to HN can be read this way. I find it easier to consume information when it follows a consistent style of presentation and without the distractions enabled by "modern" web browsers. 1. This is the only URL the www user is informed about. In the short history of the www so far, auto-loading from other domains, whether through HTML, Javascript or otherwise, has unfortnuately been abused to the point where allowing it produces more risk-taking for the www "user" than convenience for the www "developer". Sadly, instead of deprecating the "web development" practices that have been abused and make websites slow, the new HTTP standards proposed by an advertising company and supported by CDNs cater to this practice of "composite" websites comprised of resources from various third parties. It stands to reason that advertisers and therefore "tech" companies and their providers, e.g., CDNs, stand to benefit more from "composite" websites than www users do. IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.
- lowwave 4y ago
  > 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 companies, the user/consumers don't really benefit from the usage of the web.
kyle-rb 4y ago
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.
- acdha 4y ago
  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/ 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.
  - Self-Perfection 4y ago
    That is way alternative frontends for bloated websites exist. For instance, one can read twitter via nitter, which uses zero JavaScript. Check how fast it loads: https://nitter.privacy.com.de/SpaceX/status/1571950786896330752 https://nitter.privacy.com.de/SpaceX/status/1571950786896330...
  - kyle-rb 4y ago
    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.
pier25 4y ago
It Depends ™
jedberg 4y ago
What this doesn't account for is html rendering time on the server. The reason websites use local javascript to render html is so they don't have to do it on their server while you have to wait for the result. This way you have the perception of a page load while the html renders. It's actually a better experience for the user. This entire analysis assumes that the server renders the html instantly. Unless it is static content that is highly cacheable, chances are the render time on your machine isn't much slower than the server, but the website can use a lot less compute resource to make the webpage for you since your computer is doing part of the work. Also, chances are they have to transmit less data to you, which cuts down on network latency as well.
- jlembeck 4y ago
  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
  - jedberg 4y ago
    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.
    - _gabe_ 4y ago
      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 ¯\_(ツ)_/¯
chmod775 4y ago
There needs to be a website hall of shame that serves particularly slow websites rendered into PNGs/WEBP/WEBMs (+JS code to make them interactive/clickable) if those would load faster and use less data volume than the real thing.
- IYasha 4y ago
  That would be Alexa's top 100 I presume )
superkuh 4y ago
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.
- nicbou 4y ago
  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.
- Existenceblinks 4y ago
  I'm sad we are downgrading quality of workforce just to increase the size of the pool. Try not to have gate keeper mindset but the new army of js warriors coming in industry makes the ecosystem off of engineering basis.
kbenson 4y ago
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?
- bo1024 4y ago
  I wonder how much electricity Twitter is saving by running the scripts on their users' machines instead...
  - kbenson 4y ago
    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.
no_time 4y ago
>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.

186 points by tkadlec 4y ago

JS queries are tools of Satan! Today web 2.0 uses 1000% faster machines to make web experience 100% slower! What an age! PS: thank you for calling HTML HTML!

can16358p 4y ago

Shouldn'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 faster JS execution? Or perhaps a very spotty barely 1-bar 4G connection. (Just assumptions, maybe both are false, but you get the idea) I'm a bit fan of client-side generation using JS too but I don't think this experiment is exhaustive of many practical scenarios. If we see more connection types and more variety of devices with different CPUs then it'd be more convincing.

Veliladon 4y ago
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.
- epolanski 4y ago
  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.
wubsitesgood 4y ago
Some of the tests in the article are run on Desktop Chrome using a "cable" connection speed instead of 4G, which looks to have about a 6x faster round trip time than their 4G does. Those results are a little less impactful but still significant (many seconds faster still in some metrics). More testing environments would make the results more or less significant, as you'd expect. In ideal browsing conditions, the impact will be more minor, and in the spotty barely 1-bar connection you mention, the difference would be much more dramatic than the 4G examples in the post.
giantrobot 4y ago
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. [0] https://www.gutenberg.org/ebooks/84 https://www.gutenberg.org/ebooks/84

vxNsr 4y ago

This basically just tells us what we already know, SSR is faster for the client usually

epolanski 4y ago
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)
- Cyberdog 4y ago
  "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 content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.
  - lmm 4y ago
    > "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 load but being fully functional when you do. The assumption that anything that isn't HTML is "bells and whistles" is pretty dubious (as is the converse assumption that everything in the HTML is valuable).
    - Cyberdog 4y ago
      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.

megaman821 4y ago

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

makapuf 4y ago
OK but you could maybe render static html frames and fill placeholders with pre rendered html as soon as it is available? (A bit like htmx can do)
wubsitesgood 4y ago
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 though, the improvement in that first test is still large (over 8 seconds faster in those tests). If the experiment took a few seconds longer on the server, it still would be 5 or 6 seconds faster to render content than the control.
- megaman821 4y ago
  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.

NohatCoder 4y ago

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.

nicoburns 4y ago
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.
- morelisp 4y ago
  > a few hundreds of ms Gotta be honest, I’m grimacing already. An order of magnitude too much.
  - Existenceblinks 4y ago
    For me, generally sub 100ms is acceptable. a few hundreds .. No thanks html over the socket is faster than that.
  - nicoburns 4y ago
    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.
    - wubsitesgood 4y ago
      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.

kmeisthax 4y ago

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. Apparently my skepticism has been validated.

jen729w 4y ago
As usual, it depends. I just tested my own site, which I built using Gatsby — a JS framework — and https://astro.build 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.
- deleted 4y ago
  [deleted]
- P5fRxh5kUvp2th 4y ago
  I bet it could be rewritten to feel instantaneous as well. it's a common misconception that SSR implies no XHR at all. That's never been true except prior to IE5 adding the technique for outlook.
  - Spivak 4y ago
    SSR doesn't mean no XHR, it usually just means that change in route means round trip to the server. If you're doing SSR only for the initial page load then it's typically called hydration.

thwarted 4y ago

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

klysm 4y ago
The ui is not that functional compared to other git front ends.
pragmatic 4y ago
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.
- sbdncuvh 4y ago
- morelisp 4y ago
  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?
  - pvillano 4y ago
    Yes, in the current context of the need for client side rendering.
    - morelisp 4y ago
      No, you've assumed the question. "Applications are much harder to cache and start up fast" because you're defining "applications" to intentionally exclude architectures which are cachable and fast to start. If I shipped a git repo viewer as an executable, nobody would be asking why it's not rather a txt/doc/PDF. It's unquestionably an application, not a document.

the__alchemist 4y ago

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

smm11 4y ago

I'd been thinking that 5G is a thing only because the IOT is a thing. It had nothing to do with phones, but the build-out is funded by phones. So when it all settles down, phones will be as slow as they were in the 3G era, at best, what with so much stuff clamoring for data. Plain Jane HTML is going to save us.

stjohnswarts 4y ago
I've seen this with my telco provider with 5G, full bars and it is still almost unusable. replace people with IOT devices pinging and sending tiny messages constantly it's gonna be rough :)

jokoon 4y ago

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.

nescioquid 4y ago
The protocol and the document object model essentially assumed a static world. It's amazing what we've cobbled on top of an essentially stateless mode of encoding/structuring and accessing documents. Why stop at the dom? Why not the protocol too?
pjc50 4y ago
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)

1vuio0pswjnm7 4y ago

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 resources. No images, JS, CSS, etc. The answer to the question is yes. This "makes a website faster", or, more specifically, as someone else in the thread has stated, it does not make the website slow. It does not accomodate the practices of "web developers" that slow a website down. But most importantly, IMO, it makes "website speed", not to mention appearance, more consistent across websites. Good luck achieving any semblance of that with a popular graphical web browser. Most web pages submitted to HN can be read this way. I find it easier to consume information when it follows a consistent style of presentation and without the distractions enabled by "modern" web browsers. 1. This is the only URL the www user is informed about. In the short history of the www so far, auto-loading from other domains, whether through HTML, Javascript or otherwise, has unfortnuately been abused to the point where allowing it produces more risk-taking for the www "user" than convenience for the www "developer". Sadly, instead of deprecating the "web development" practices that have been abused and make websites slow, the new HTTP standards proposed by an advertising company and supported by CDNs cater to this practice of "composite" websites comprised of resources from various third parties. It stands to reason that advertisers and therefore "tech" companies and their providers, e.g., CDNs, stand to benefit more from "composite" websites than www users do. IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.

lowwave 4y ago
> 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 companies, the user/consumers don't really benefit from the usage of the web.

kyle-rb 4y ago

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.

acdha 4y ago
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/ 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.
- Self-Perfection 4y ago
  That is way alternative frontends for bloated websites exist. For instance, one can read twitter via nitter, which uses zero JavaScript. Check how fast it loads: https://nitter.privacy.com.de/SpaceX/status/1571950786896330752 https://nitter.privacy.com.de/SpaceX/status/1571950786896330...
- kyle-rb 4y ago
  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.

pier25 4y ago

It Depends ™

jedberg 4y ago

What this doesn't account for is html rendering time on the server. The reason websites use local javascript to render html is so they don't have to do it on their server while you have to wait for the result. This way you have the perception of a page load while the html renders. It's actually a better experience for the user. This entire analysis assumes that the server renders the html instantly. Unless it is static content that is highly cacheable, chances are the render time on your machine isn't much slower than the server, but the website can use a lot less compute resource to make the webpage for you since your computer is doing part of the work. Also, chances are they have to transmit less data to you, which cuts down on network latency as well.

jlembeck 4y ago
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
- jedberg 4y ago
  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.
  - _gabe_ 4y ago
    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 ¯\_(ツ)_/¯

chmod775 4y ago

There needs to be a website hall of shame that serves particularly slow websites rendered into PNGs/WEBP/WEBMs (+JS code to make them interactive/clickable) if those would load faster and use less data volume than the real thing.

IYasha 4y ago
That would be Alexa's top 100 I presume )

superkuh 4y ago

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.

nicbou 4y ago
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.
Existenceblinks 4y ago
I'm sad we are downgrading quality of workforce just to increase the size of the pool. Try not to have gate keeper mindset but the new army of js warriors coming in industry makes the ecosystem off of engineering basis.

kbenson 4y ago

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?

bo1024 4y ago
I wonder how much electricity Twitter is saving by running the scripts on their users' machines instead...
- kbenson 4y ago
  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.

no_time 4y ago

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