SSR is fairly desirable for some apps, especially ones that have parts that have significant static content. That might be linked to from elsewhere. Think like

SSR is fairly desirable for some apps, especially ones that have parts that have significant static content. That might be linked to from elsewhere. Think like a blog. On such a site SSR not only can mean faster time to content for new viewers (especially with server side caching, but even without your server may well be faster than a low end mobile device), but it also means that some basic sight functionality like navigation might even work with JavaScript disabled. (For that, you simply need to ensure navigation uses `<a href="..."` tags, with JavaScript click handler that intercepts clicks and hands them off to the router. People with JavaScript disabled will make a server request, which will SSR the new destination and return it, which is better than having literally nothing work in that scenario.) Indeed, next.js is really about allowing you to use react to make more of a classic server rendered site that supports progressive enhancements (client components), but using react just an SPA. They even prefer a server side router. This has advantages like the JavaScript code bundle downloaded by the browser being much smaller, as only the code for client components is needed, while all other components are server rendedered only, so don't need to be in the client bundle. If in practice everybody comes to one url for your app, people come specifically to interact rather than for content (so time to content being visible is not an important metric, while time to interactivity is important) then sure SSR and next.js are probably not really useful for you.