21–30 of 109 posts
Plain Jane HTML is going to save us.
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.
This is just realigning what many of us already knew, SSR is faster.
If I may, the argument of "well... sure, but CSR can be plenty fast!" is redrawing the line after someone stepped over it.
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.
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…
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.
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.
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.
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)).
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.
This requires testing. Which is, apparently, something most companies don't know how to do correctly.
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.
Earlier quoted context omitted.
> 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.