What is the point of SSR these days?

[marbiano]

Lately, I've been reading more and more people suggesting to statically render something and then on client make subsequent requests to complete the experience with proper data, when necessary. Basically the Jamstack approach, which makes sense from a conceptual point of view.

Thing is, with that approach, I'm failing to see a scenario where doing server side requests for stuff like fetching current user would make sense.

How does the Next.js team feels about this?

[rauchg]

Next.js is a hybrid framework. We will be recommending static and static site generation as a default.

We already output .html files if you don't use getInitialProps and the getStaticProps and getStaticPaths methods (#9524) allow you to move from getInitialProps easily over to production-grade static site generation.

SSR still makes sense for veeeery large sites, but we are also addressing that with SSG. We will be doing a follow-up RFC once the one above lands to explain that.

Thanks for asking!

[arunoda]

Yes, if we speak in the traditional sense you might not need to use SSR with Next.js. But still server rendering is a core part of Next.js and that's why we could create great features like "Static Regeneration" and "CMS Preview" without support from a custom hosting provider. (no vendor lock-in)

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

[marbiano]

Thanks, @rauchg!

[subtleGradient]

SSG = "Static Site Generator"
for people (like me) who can never remember these acronyms🤪

[lukaszsobek]

So much this. Also since SSR means "Server Side Rendering" I found myself confusing what the double s's stand for in the beginning.

[julianbenegas]

In my case, I'm building a news site, and SSR is key for SEO and for Open Graph Protocol. If we don't do SSR, our site looks empty for google bots and that's no good for a news site.

Doing full SSG won't do because on every article created we'd have to build it again...

[m1rke]

Thank you @timneutkens
I am already implemented this on the following way:

export async function getStaticProps() {
  const response = (await ServerManager.getAllBlogs()) || []

  return { 
    unstable_revalidate: 1, 
    props: { article: response.data.articles.rows }}
}

Commands: next build and next export

My exported page works fine but when I add new article post to database page is not updated.
Could you please explain me what is the problem, Maybe I didn't understand everything right.
I am using next@latest version installed with yarn.

[timneutkens]

You have to use next start to use incremental generation and preview mode.

[m1rke]

After next export or next build and next start?

[timneutkens]

Not using next export indeed. so only next build && next start

[m1rke]

Okay, thank you for your time!

[arpowers]

The primary benefit of SSR is SEO and syndication related. Ever tried sharing a SPA link on Whatsapp? The metadata is the same for every page on your site.

The real question isnt about SSR but if you'd rather have an active vs static site.

Static sites have two critical disadvantages:

• builds for everything - means it takes forever to update
• no dynamic features - you can't have comments, auth, e-commerce, etc (without paying for disparate apis)

For me, it's clearly necessary to have an active server to accompany my apps and once I have that SSR is easy.

[trelljaret]

I myself think Static Sites (SSG) can be used for building a web application (SPA) where SEO is not important.
But when SEO becomes important, You HAVE TO USE SSR. There are no other better option. This makes next js much like a PHP for js stack.

[stigkj]

On the contrary. If you have a static site, i.e. every path returns a fully rendered page, it will be better for SEO than SSR because speed matters. Of course, for a dynamic site you might not be able to generate all pages build time, but then you can use the build-on-demand features of Next.js to generate and cache the pages as they are needed.

[vinay-akkipet]

@arpowers With Next.js ISR(Incremental Static Regeneration) capability the critical disadvantage you mention is mitigated, the builds for everything is no more required, it can be done while the site is active. Saying just in case you haven't had a look and also for anybody who's reading this and aren't aware of ISR in next.js.

[pmontrasio]

no dynamic features - you can't have comments, auth, e-commerce, etc (without paying for disparate apis)

Amazon is server side rendered.

[beenotung]

In general, SSR has better compatibility.

Imagine you built a SPA in ionic stencil, then someone come to your site with Android 4.4 or below, they see a blank page (or a splash screen, loading forever).

[olpeh]

I tried to write that down as a blog post earlier. You might want to check it out: https://olavihaapala.fi/2019/12/11/we-have-gone-full-circe.html

[timneutkens]

Doing full SSG won't do because on every article created we'd have to build it again...

builds for everything - means it takes forever to update

Not necessarily, more on this soon 💯

[julianbenegas]

Hey Tim, does this alude to the launch of Next.js 9.3? If so, how does 9.3 solve the issue with this? If I use a CMS, when I want to publish an article, I'd have to somehow trigger a build, or am I missing something from 9.3?

[timneutkens]

This in particular: #11552

[janus-reith]

I feel like the missing link we have here is to have a system in place which prepares static pages on demand, with some simple way to trigger rebuilds at runtime, without the need to build a complex CI around it. So basically what some classic content management systems could do a decade ago, although not decoupled back then.

E.g. I have a list of blog posts, and some page that displays the last 20 of them. Now there could be some trigger to tell nextjs: Rebuild that page, or even better but unsure if feasible, rerender just down from the tree at the point of the changed data of some refetched query.
Maybe like some kind of cache invalidation.

I could think of different triggers here which all might have their usecase:

• Based on time, e.g. refetch and rebuild every hour.
• API Calls, e.g each page exposed some api endpoint which could be called from the backend each time a change has been made. In the given example, that would be when a new blog post was written.
• By something roughly comparable to the react shadow dom, that looks for changes and rebuilds if necessary. This approch would open the possibility to work with things like GraphQL queries that use polling, or even subscriptions.

[Daniel15]

I feel like the missing link we have here is to have a system in place which prepares static pages on demand, with some simple way to trigger rebuilds at runtime, without the need to build a complex CI around it.

So basically WordPress? 🤔
Use the "WP Super Cache" plugin and it does exactly this. First time you hit a page, it generates a static HTML file. Configure the web server correctly and it'll serve those static HTML files straight from cache.

All these fancy modern technologies are cool, but it seems like we keep revisiting good old ideas :)

[janus-reith]

So basically WordPress? 🤔

Yes For example, that’s what I meant when I said

what some classic content management systems could do a decade ago, although not decoupled back then.

However it doesn’t feel like a step backwards for me and the only similarity here is page caching: We still would have all the advantages of modern technologies, could still use dynamic stuff like isomorphic rendering and have things decoupled compared to classic monoliths.

But, while probably simple, I would not favor a „Cache on first visit“ approach. Out of 1000 visitors, the first should have a fast page load aswell. Also I think this wouldn‘t cover how to do invalidations: I did a quick lookup on the plugin you mentioned, it seems like it only does this based on a fixed expiry time. This part should allow for as much flexibility as possible, with expiry time just being one of them.

The only real disadvantage I see is that things could break during runtime which would else be catched during build. However, the same would apply on any other data fetched on the client or during SSR. I don’t want to go too far beyond the scope of nextjs, but in such cases there could even be defined fallback behaviors, like to keep the existing render that succeeded, or additional hooks that could be executed on a finished page build before it becomes active to do testing during runtime. For sure this would reach a certain complexity where it might make sense again to have a CI in place specific to the usecase instead of having the next monolith, but I think there is a golden middle here which is more than the current functionality.

The current SSR vs CSR vs SSG just feels like a dead end to me and I don‘t get why I should chose between options that all have their disadvantages. The nextjs hybrid approach to have this on a per page basis also doesn‘t solve it, as those pages requiring fresh data would still have way less performance than they ideally could.

[arpowers]

I agree about WordPress having some advantages. The downside however is that WordPress is not portable and is slow and complicated to work with (old tech)

Have you guys seen https://factor.dev?

^^ that is the WordPress approach w modern tech.

[bradydowling]

Also worth looking at TinaCMS, which plays nicely with both Next and Gatsby

[negati-ve]

Also worth looking at Strapi.
it's like using a koa backend with fancy cms features

[janus-reith]

Yeah I really think we should not focus on wordpress advantages any further here, as this is a nextjs discussion and the technical stacks are completely different.
Your Project Factor for sure is technically closer and looks great btw. but uses vue. I had a quick look at the docs, it seems to also do SSR on each request, but I didn't find something regarding static prerendering - Is there by chance any kind of caching/ on demand rendering logic implemented that might be interesting to consider?

[arpowers]

Factor is easily cached, authentication is done in the client so the source is same for all requests.

it would be easy to add static stuff but that's a competitive space and a solved problem.

Factor's advantages come from having an active server which works behind the scenes to help you avoid using 100 apis and SaaS tools to make a decent app.

[Daniel15]

But, while probably simple, I would not favor a „Cache on first visit“ approach.

You can also pre-cache commonly-accessed pages before they're visited. Some things are just not precacheable though, for example search results.

Also I think this wouldn‘t cover how to do invalidations: I did a quick lookup on the plugin you mentioned, it seems like it only does this based on a fixed expiry time.

You can configure it to cache indefinitely and only clear the cache when changes are made (eg. new posts are published)

The downside however is that WordPress is not portable and is slow and complicated to work with

If you want something very fast you'd likely need to look at something like Hugo. IMO JS apps are actually more complicated than PHP apps... dependency management with npm has a lot more edge cases compared to Composer.

Yeah I really think we should not focus on wordpress advantages any further here, as this is a nextjs discussion and the technical stacks are completely different.

True, I agree, but on the other hand it's useful to compare advantages and disadvantages of alternative solutions in order to build something that's the best of both worlds.

There's also more modern hybrid approaches with WordPress where you use it as a 'headless' CMS. All the post management is done in WordPress, and the actual site is build using a static site generator that uses the WordPress API as input. You get some of the advantages of WordPress (great post management experience particularly for non-technical users, not having to use/deploy Node.js) along with some of the benefits of a static site generator (fast for users, more secure as it's just serving plain HTML). That's worth considering when comparing different systems.

[arpowers]

For me, working with WordPress is like nails on a chalkboard. I just can't bring myself to spend hours and hours learning and debugging obsolete tech (my opinion).

[j0lvera]

I will leave a comment here for people wanting to, or currently using WordPress, so they don't get discouraged.

WordPress is far from being an obsolete tech. It's widely used (~37.8% of all websites) and It will keep growing as long as they continue evolving.

You can spend hours and hours learning and debugging with any technology, I have been doing it myself with Next.js (which is a joy to do with, btw).

You can even use Next.js with WordPress and have a powerful combination. I've done it for clients and personal projects.

SSG combined with WP and the soon to (official) be Static Regeneration will be an amazing tech stack that I look forward to using.

[mustafa-hanif]

SSR is still needed if your content changes frequently, like a classifieds website. And you need SEO also.

[timneutkens]

Reported the spam bot.

[Fonger]

For small to medium websites, SSG is great. However, SSR is definitely necessary since we have millions of dynamic pages. We can't afford it to be compiled during build and we need realtime update for those pages.

[timneutkens]

You don't have to generate all pages up-front when using Next.js SSG features, the fallback behavior allows for generating additional pages: https://nextjs.org/docs/basic-features/data-fetching#fallback-true and incremental ssg (open RFC) will solve re-rendering them.

[stigkj]

As far as I can see, one needs SSR when wanting to release features to only some of one's users, for example only logged in users should get the new features, or only 10% of the users, etc. We are using this all the time to make sure we make stuff that users actually think is nice.

The problem with this is of course not being able to take advantage of caching of almost static pages, i.e. it will be a small number of variants for each page which would be easy to cache.

Does anybody have a good solution in Next.js for this use case?

[arunoda]

for example only logged in users should get the new features, or only 10% of the users, etc.

Actually you don't need SSR for this. You can expose data for these features behind an API and fetch data from the client side. I don't think static pages/regeneration is a solution for user specific pages.

I'd like to share more feedback, if you give more information. May be in a different thread.

[eric-burel]

Let me know if I get it right:

For "public-first" websites (blog, e-commerce)

• Public website with static public data: use SSG, static public data are fetched at build time
• Public website with dynamic public data: use SSG, static public data are initially fetched at build time + Incremental Static Generation for updating public dynamic data + client-side to fetch data that changes really really quickly
• Public website with some private data: same + you fetch private data client-side as usual in a SPA
• Public website with a very strong requirement of having fresh data being server-side rendered: you use SSR, but that barely ever happens for most applications

For "private-first" websites (Software as a Service, administration interface)

Private apps have been bugging me for a while but I think I get it better now:

• Any private app: SSG of an empty shell without data + data-fetching client-side
• Private apps with a very strong requirement of having fresh data being server-side rendered: SSR (could happen for mobile users for instance, but still a limited use case)

Specifically, one might be tempted to systematically use SSR for private apps, because technically the render is always depending on the current logged user (so the current request cookies or auth header). Even if you load the data later, client-side, you still need to check if the user has access to the page.

But using getServerSideProps just for auth check, is mostly wrong: it leads to a huge increase in the auth process complexity (you must impersonate the user, including for complex workflows like token refresh, see #17515) and in code complexity (we have 200 line monster at Vulcan to check redirections).

Instead, using a simple, dedicated server for auth check, and then considering the private app as it is was public seems smarter and simpler.
Like in a company, you check if people are allowed to enter at the door (that's your auth server), but then you consider that if they are in the company, they are authorized persons (so you can safely render an empty shell of your private pages). You eventually get the actual private data client-side to fetch the data.

In all those scenarios, using getServerSideProps is fine, but meant at advanced use cases with a good reason to use it, as getStaticProps + Incremental Static Generation is most often sufficient.

Maybe it could be doable using just Next, but I think this would need to be able to setup a kind of middleware that runs only when the server is running but not during SSG (without a custom server).

[rqbazan]

Hey guys, could somebody give me their point of view about: https://github.com/theninthsky/client-side-rendering#ssr-disadvantages. This case study has some good points about CSR, SSR, and SSG.

[Daniel15]

Some of the points in that "SSR Disadvantages" section are arguable:

When moving to client-side data fetching, SSR will always be slower than CSR, since its document is always bigger and takes longer to download.

Server-side rendering will often give you a faster perceived loading time, since the user will see content before the scripts finish loading. You just need to be sure to disable any functionality that requires JS before the scripts load. With client-side rendering, nothing is rendered until the scripts have finished loading.

Since all images are initially included in the document, scripts and images will compete for bandwidth, causing delayed interactivity on slow networks.

By default, browsers only prioritise images that are visible within the viewport (i.e. what's visible in the browser window). Images outside the viewport will be loaded after scripts, unless they're preloaded. The newer fetchpriority attribute can be used to make scripts a higher priority than other content like images. CSS and font files are highest priority so there's no need to worry about those.

SSR page responses mostly don't return a 304 Not Modified

This is an issue with how the backend is implemented, rather than an issue specifically with SSR. Since CSR needs to fetch data from the network, it'll still have the same issue with its data fetching.

Fetching data on the server is usually a bad idea, since some queries may take several hundreds of milliseconds to return (many will exceed that), and while pending, the user will see absolutely nothing in their browser.

You absolutely can render a loading screen with server-side rendering, by using a chunked HTTP response (or whatever HTTP/2's replacement is). You can render the HTML for a loading screen, then when the data has finished loading, render an inline <style> to hide the loading screen then render the actual page.

[eric-burel]

It's good content, here's my take:

You have to be extra precise when you say "slower" in this context. SSR is necessary slower by TTFB (Time to First Byte) because it does a computation before responding that CSR don't do.
But many factors have to be taken into account, like how you cache your SSR (you can become very fast if some content is actually the same for multiple users and you cache it properly, I've named this Segmented Rendering), do you stream the return (kind of things we'll see in incoming versions of Next), and also with Server components, you'll be able to have SSR on components as well with more flexibility.

It hit the spot regarding the fact that rendering and data fetching are 2 separate things. There are actually 2 approaches in the wild:

• data fetching by default. This used to be the recommended way with Apollo, and somehow it starts being trendy again with Wundergraph using this approach or Plasmic
• data fetching handpicked. This is what Next.js recommend and the current trend. You SSR only critical content that should be accessed without JS OR that can be cached afterwards (see Segmented Rendering again, or Next.js ISR)