Analysis: Hey Next.js, Is Server Side Rendering Dead?

👨‍👩‍👧‍👦 Community
1

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?

Now Google can render client-side JavaScript apps. It even prefers to do that instead of just looking at the HTML output. So, for dynamic web apps, SSR is not needed to index inside Google.

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)

2

In case it helps, Luis explained in this post more about SEO and SSR: https://frontity.org/blog/seo-for-headless-wordpress-themes/#javascript-and-server-side-rendering.

1 Like
3

I’m not an SEO expert, but some experts have explained to us that Google still uses the SSR version of the sites for indexing. And only runs the CSR JavaScript crawler to check some pages and verify that your SSR & CSR version match (google penalizes pages that don’t match after CSR). In addition, the CRS JavaScript crawler requires more resources, so it consumes the crawling budget for your site faster.

It even prefers to do that instead of just looking at the HTML output. So, for dynamic web apps, SSR is not needed to index inside Google.

From what we know, that sentence it’s not true unless things have radically changed in the last couple of months.

1 Like
4

I’ve compiled a few references on this topic and they all seem to conclude that SSR is the best solution to guarantee a good indexing and SEO of your site.

SEO in 2020 - SSR vs SPA

:date: 07/03/2020

Håkon Krogh @hakonkrogh
Head of Engineering at @crystallizeapi

https://spa-blog.kroghweb.no/seo-in-2020-ssr-vs-spa

If SEO is a concern for your application, you still have to avoid an SPA and go either SSR or Static Site Generation (SSG), like Gatsby and Next.js if you are looking for React alternatives.

What I learned about SEO from using the 10 most used JS frameworks

:date: 06/02/2020

Jan-Willem Bobbink @jbobbink
SEO with a focus on performance

Server Side Rendering (SSR) is just the safest way to go. There are cons, but for SEO you just don’t want to take a risk Google sees anything else then a fully SEO optimized page in the initial crawl.

Is My Single-Page Application SEO Friendly?

:date: 24/01/2020

Anthony Gore @anthonygore
Publish tutorials and courses on VueJsDevelopers.com

My advice: if you are going to use the SPA architecture, be sure to provide server rendered or prerendered pages.

1 Like
5

Yes, that’s our information: SSR is still the best way to get quickly indexed by Google. And our CMS users are the most sensible ones to SEO, so they won’t risk doing it worse than ideal.

Yes, it is. We are doing so for the JavaScript assets :slightly_smiling_face:

It doesn’t make sense to do so for the data because that is included in the HTML.

Yes, they do hybrids of static site generation and dynamic rendering. I don’t think that it makes sense to explore something like that in Frontity at this point.

1 Like