SSR to help mitigate slow client data transfer and improve TTI?
I'm involved in an ongoing saga at work to improve the state of a SPA that is just an order form. This app was built with CRA before I started working here, and we are rendering on the client-side, fetching data via GQL (7-ish requests in total), then doing a bit of processing of that data before setting in state and allowing full interaction.
I've had some success moving the app away from using Context for everything and triggering tons and tons of updates, and also restructuring the way in which we are fetching data. However, I'm still not fully happy with the performance of the app on mobile. I've been told that we do have users that may be on slower phones and with connections as slow as 2G worldwide, and so I'm looking to see how I can potential mitigate some of the issues a user may run into.
Please forgive me if this is a super basic question, as I'm not incredibly familiar with SSR/Next in practice and I could just have a fundamental misunderstanding. But it struck me that if a big area of concern is the potential slow speeds of CPU/network on the client side, it might make sense to send off for the data necessary to allow interaction on the server-side with something like getServerSideProps. This data is not consistent and varies depending on the URL's query string, so unfortunately generating something static and rebuilding doesn't strike me as feasible.
If we were to send requests on the server, then we would not be beholden to the client's network speeds for this data transfer. However, I'm not sure if there's a trade-off I'm unaware of. I'd assume the transfer of HTML would be much lighter than some of the data we're fetching, but would we potentially have to pay a tax during hydration that will end up effectively meaning it takes just as long to load, but that we lose the expeditated TTFB we get from client-side rendering?
Just wanted to check if this thinking makes sense, and if it's something I should prototype. Thanks, have a great day!
7 Replies
I'd lean on keeping it clientside, it's usually better to display loading indicators than a blank screen; In ssr land, all the fetching that happens in the clientside would still need to happen, just at a different place.
For sure, that makes total sense. I mostly just wasn't sure about whether it's a worthy tradeoff for users with an exceptionally slow connection. Throttling to 2G speeds I'm seeing that in addition to the already astronomical time the bundle takes, fetching the data itself is taking over a minute in cases where we have a very heavy response due to geocurrencies settings.
But it's possible I'm thinking about a case where I functionally can't really improve the UX beyond a certain point, and I should just accept the L.
Thank you very much for the insight!
Oh man I love this question, I really hate how much people don't talk about the trade-offs of ssr and how it can be bad, seems you've thought about a lot.
One often overlooked aspect of performance is deletion. Before looking to optimise I'd check to see how much of the code can be deleted
Just out of curiosity, why do you say that in "ssr land", all the fetching that happens in the clientside would still need to happen? I'm not really sure I understood what you're trying to say 😄
I was trying to convey the idea that the time it takes something to load on the client wouldn't disappear; Those requests would be made serverside while the user stares at a blank screen.
Of course there's an argument to be made that maybe your servers are closer to each other than your user, but I don't think that would be enough to justify a 30s loading spinner in the client becoming a 20s blank screen
I appreciate it! And thank you all for your responses. I don't really have any more senior FE devs where I work or any friends that I can turn to, so being able to get a quick perspective is a godsend.
I've worked with some very strong engineers, interestingly enough the best frontend engineers were actually just really good at everything..being full stack is just so powerful especially with product teams.
Also they didn't even do anything fancy on the frontend or cutting edge, the most fancy thing was react/redux with some rxjs. Even then, if you explained a new framework to them (like trpc, next etc) they'd pretty much instantly know all the pros and cons to it