6 ms·

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

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.
    - morelisp 4y ago
      > HN, which is about as fast as sites get in my experience We have different experiences. HN is light but it's not fast.
- imachine1980_ 4y ago
  or loading everithing instead of lazy loding the images or use 3mb image instead of kb webp
  - NohatCoder 4y ago
    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.
    - IYasha 4y ago
      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.
- NohatCoder 4y ago
  I'd put it like this, sometimes the framework culture does a lot more damage than the framework itself.
epolanski 4y ago
> 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__alchemist 4y ago
  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.
  - epolanski 4y ago
    My bad then.
P5fRxh5kUvp2th 4y ago
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.
- NohatCoder 4y ago
  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.
pragmatic 4y ago
Also, doesn’t matter how fast the front end is if it immediately throws up a spinner as it waits on the api.
zozbot234 4y ago
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.
- kayodelycaon 4y ago
  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.
  - Existenceblinks 4y ago
    How about spreadsheet and google map app!? \s \s \s!
bachmeier 4y ago
> 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.
- Spivak 4y ago
  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.
- NohatCoder 4y ago
  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.
Existenceblinks 4y ago
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.

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.
  - morelisp 4y ago
    > HN, which is about as fast as sites get in my experience We have different experiences. HN is light but it's not fast.
imachine1980_ 4y ago
or loading everithing instead of lazy loding the images or use 3mb image instead of kb webp
- NohatCoder 4y ago
  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.
  - IYasha 4y ago
    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.
NohatCoder 4y ago
I'd put it like this, sometimes the framework culture does a lot more damage than the framework itself.

epolanski 4y ago

> 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__alchemist 4y ago
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.
- epolanski 4y ago
  My bad then.

P5fRxh5kUvp2th 4y ago

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.

NohatCoder 4y ago
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.

pragmatic 4y ago

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

zozbot234 4y ago

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.

kayodelycaon 4y ago
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.
- Existenceblinks 4y ago
  How about spreadsheet and google map app!? \s \s \s!

bachmeier 4y ago

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

Spivak 4y ago
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.
NohatCoder 4y ago
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.

Existenceblinks 4y ago

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.