React SSR, NextJS vs Chrome headless prerendering

Question

For server-side rendering I found 2 approaches:

• next.js
• chrome headless prerendering (ex react-snap)

NextJs has a lot of stars on GitHub and a great community but the other approach (chrome headless prerendering) seems cleaner and need nearly zero configuration to work.

Is there anyone who has the experience to work with both of them?
What is key pros and cons of each one?

Answer 1

(I have been struggling with this dilemma some time ago and would like to share with you some of my personal views)

Some of Pros of SSR in your SPA application

• SEO/SMO - the most desired factor, achieving crawlability of SPA like the standard website,
• performance - quicker rendering of SPA site, while HTML nodes are prerendered,
• resources - like it was always in server rendered sites, the SSR leverages computing power of existing server architecture for your users.

Useful sources: Server-side vs client-side rendering in React apps, Next.js — React Server Side Rendering Done Right.

The actual value for SEO is unbeatable, on the time of writing primarly Google can crawl SPA properly (insights & analysis), while it can be considered enough for organic search usually it is not acceptable for social medias where excerpts of links simply won't generate causing drawbacks for your bussiness.

Performance case is limited one - the React Apps (and SPA in general) are into efficiently storing site on client. And first run usually: installs offline Web worker, loads tons of cache into browser. Making this pros vitable nearly only on case of 1-st ever load of website by user.

Usability of resources or it's advantages are strictly connected to app architecture, there are cases that possibly are more performant by caching than involving server at all.

---

Using NextJS/Gatsby/SSR App Framework

The evolving nature of JS is pushing the line very fast in the matter that those frameworks need to race with the advancement. That implicates the fact of being in some time behind it's technology best features.

One of crucial example is hype made after React-Router v4 update, which taken boilerplates by storm but stomped on frameworks like NextJS Use with React Router 4 #1632 while there is much community pression, as developers we are forced to work with the architecture which is given to us.

It means being less CRA (and the React-standard in general) and more NextJS-like:

• app structure, next/head, Document, <layout>,
• @zeit/next-css, @zeit/next-sass, styled-jsx,
• static async getInitialProps () pattern,
• next-redux-wrapper, next-redux-saga,
• <Link prefetch> from next/link,
• BE routing from /pages/, files served from /static/ etc.

And makes the 'feel' of being patched to work the same like fully-fledged CRA.

The another failpoint is the standard no-SSR app won't be rather easily ported to SSR solution like NextJS/Gatsby, which have their own rules and architectures. Forcing to make such decision at best at the beginning.

Headless prerendering

Saves your application from being limited by SSR in-app solutions. SPA sites assumed to consume API without rendering on server thus many of the patterns/packages are not ready for SSR from scratch and might pollute your standard codebase.

While it might not be best optimised to serve you app with SSR is quite easy and straightforward solution if you seek for SEO/SEM.

The automatic tool (like provided by you react-snap) might struggle with some Caveats including problems of properly snapshoting the right HTML output of site (eg. the one which is the most valuable for SEO purposes).

---

While there is nothing wrong with SSR approach purely for SEO, there is reasonable fact that in near future any crawlers will make progress into best crawlability of SPAs therefore after some time, the complete SSR solutions might not be a plus.