Hacker News Reader

Comment by NohatCoder | Hacker News Reader

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.

View on HN

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.

> a few hundreds of ms

Gotta be honest, I’m grimacing already. An order of magnitude too much.

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.

> HN, which is about as fast as sites get in my experience

We have different experiences. HN is light but it's not fast.

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.

For me, generally sub 100ms is acceptable. a few hundreds .. No thanks html over the socket is faster than that.

I'd put it like this, sometimes the framework culture does a lot more damage than the framework itself.

or loading everithing instead of lazy loding the images or use 3mb image instead of kb webp

You have to be careful with the lazy loading, sometimes it ends up being just more round trips. And then there are those annoying sites that refuse to load anything that is off screen, and you end up having to wait over and over again.

Those are the cursed sites! Not only you have to wait for content you want, but you always get content you DON'T want just when you're about to finish your reading. Then - BAM! - page starts lagging, twitching, spitting out another megabytes worth article you didn't ask for.

While this is technically true, it's always been technically true, even when those in the religion of the SPA claimed it was clearly faster to use CSR over SSR.

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.

Really it is a lot more about how much stuff you load than how you do it. CSR can at times provide savings, for instance by doing fake page changes and not having to load menus and stuff when the content changes. But of course you have to keep the JS light in order to not eat the savings.

Also, doesn’t matter how fast the front end is if it immediately throws up a spinner as it waits on the api.

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.

How about spreadsheet and google map app!? \s \s \s!

> You don't need to make your website fast, all you have to do is not make it slow in the first place.

This requires testing. Which is, apparently, something most companies don't know how to do correctly.

Actually no, the point is if you don't put in anything that potentially makes the website slow you can be reasonably certain that it isn't. Obviously you still want to test the website, but it is not like this path is particularly test demanding.

Automated performance regression testing in browsers isn't trivial. Hell automated correctness testing in browsers isn't trivial. It's just not a well-trodden path -- automating browsers to test anything at all is messy and brittle.

The `***-dom.js` is 130.5 kB minified. Imagine parse and evaluate time browser takes before doing anything else. .. Oh also that's 0 LoC app, just a lib.

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

My bad then.

Reply on news.ycombinator.com