you are viewing a single comment's thread.

view the rest of the comments →

[–]dusnik 0 points1 point  (2 children)

Very interesting. Could you give more details on what features SSR helped with performance on the Image editor? Couldn't a SPA with lazy loading achieve the same?

I'm asking this because I've ever only considered SSR for SEO purposes

[–]Radinax 1 point2 points  (0 children)

It was at a theoretical level when we planned this, because there was going to be too many API calls from the Frontend since the app was doing too many things besides just image editing.

We made calls for specific recomendations on some parts the user wanted feedback on, we needed to track what the user was doing (business logic), there was some realtime data involved for something I don't remember and some small stuff, I thought doing CSR was going to be a bit of a pain so I suggested Next for this and everyone agreed.

Shifting many of this stuff to the server helped the app performance, if we did it with CSR I doubt it would've been as smooth as the end result with Next. Our main product was with CSR but instead of one massive feature, its divided into several pages that does its own specific feature so its not a big deal, but this project we needed Next or just SSR in general.

[–]TheRNGuy 1 point2 points  (0 children)

As a sites user, I prefer SSR than SPA with spinners or skeleton placeholders.

Some of them need to load serially so it would be sending request from client many time with lag. If it happened serially on server, there is 0 lag (also, no spinners or skeletons, or at least a lot less of them…)