3 ms·

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they wa

by donatj 1y ago

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off. Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.

unchar1 1y ago
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages. By every performance metric, the new app was faster. But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site. I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
- bob1029 1y ago
  SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency. My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
  - nfw2 1y ago
    Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
    - gizzlon 1y ago
      > should have no perceivable latency between the action and the feedback that the action was received. Huh, according to who? I think a small delay is totally fine. Often better than the SPA's that tried to fix this non-problem and introduced much worse problems. Edit: For example HN: I press update and there's a small delay.. So what? Most sites and SPA's have a much worse user experience than this.
      - deleted 1y ago
        [deleted]
      - nfw2 1y ago
        Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic. Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions). https://www.researchgate.net/publication/391230228_Cognitive_Integration_of_Delays_Anticipated_System_Delays_Slow_Down_User_Actions https://www.researchgate.net/publication/391230228_Cognitive... https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...
        gizzlon 1y ago
        Looked at the first one, and that's in a game setting? And they test 600 ms?? edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
- nfw2 1y ago
  I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome. Are your p90 metrics testing: - navigation after first load? - users who are going to the app after it is cached on their browser? Are your actions going through server actions or rest apis? Do you have metrics on those?
jeremy8883 1y ago
the back button does work, if you use any basic routing library. opening in a new tab does work, with any basic routing library...

by donatj 1y ago

unchar1 1y ago

We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages. By every performance metric, the new app was faster. But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site. I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.

bob1029 1y ago
SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency. My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
- nfw2 1y ago
  Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
  - gizzlon 1y ago
    > should have no perceivable latency between the action and the feedback that the action was received. Huh, according to who? I think a small delay is totally fine. Often better than the SPA's that tried to fix this non-problem and introduced much worse problems. Edit: For example HN: I press update and there's a small delay.. So what? Most sites and SPA's have a much worse user experience than this.
    - deleted 1y ago
      [deleted]
    - nfw2 1y ago
      Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic. Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions). https://www.researchgate.net/publication/391230228_Cognitive_Integration_of_Delays_Anticipated_System_Delays_Slow_Down_User_Actions https://www.researchgate.net/publication/391230228_Cognitive... https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...
      - gizzlon 1y ago
        Looked at the first one, and that's in a game setting? And they test 600 ms?? edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
nfw2 1y ago
I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome. Are your p90 metrics testing: - navigation after first load? - users who are going to the app after it is cached on their browser? Are your actions going through server actions or rest apis? Do you have metrics on those?

jeremy8883 1y ago

the back button does work, if you use any basic routing library. opening in a new tab does work, with any basic routing library...