There are some interesting points on this article that I’d like we comment
With SSR, we have to run React on the server. It consumes a lot of resources. If you need to fetch data on the server, it adds latency to your overall page load time.
As I understand our reasoning behind this is that:
With a good cache layer & strategy the processor consuming & the latency in the server is minimum
Is this correct? Can you develop this? Is there any place where we explain this in more detail?
What do you think of this? Do we have more data on why a SSR is the best solution for improving the SEO of a site?
But still, SSR helps to implement various social media features like Twitter cards. For even that, we only need to render the HTML head.
Is this enough reason to apply a SSR strategy? Are there any more problems for SEO you’re aware of when not applying a SSR strategy?
This app preload data just like any other asset on your website. we can render the data without waiting for a fetch API call.
Have you checked this? Is there any possible application in Frontity?
With incremental static regeneration, but we can generate static pages and update them on-demand in the server. Here we create pages inside the server, and that uses server-side rendering.
It seems Next.js have their own cache layer integrated in the Framework. Is this correct? Is this something that could makes sense for Frontity? I guess right now the solution in Frontity is applying a good cache layer and a good cache strategy
Taking into account the reasoning of this article about SSR and Next.js, I’d like to understand the reasoning we have over why SSR (Server Side Rendering) is a better option than SSG (Static Sites Generators) in a the stack: WordPress + React., and why Frontity is the best option for applying this SSR strategy (I guess here is when it enters the Developer Experience and the Extensible nature of Frontity)