I'm a big fan of CSR, and I don't think it's as bad as some detractors claim it is (or was), however, Server-Side Rendering will always always always be ideal. You simply can't beat it, no matter how good Client-Side Rendering gets over time!

I just feel like there's no competition: CSR will never supplant SSR, though for some cases just using CSR is good enough™ and it's okay.

I still say CSR is bullshit for one simple reason; tis a walking talking WCAG violation which means you are flipping the bird at users with accessibility needs, often flipping the bird at users who intentionally block JavaScript due to bandwidth concerns, and to be BRUTALLY FRANK?

If you are seeing performance benefits from its use, you likely don't know enough about HTML, CSS, or JavaScript to be outputting a damned thing to the client in the first bloody place!

Which is why I'm no fan of GARBAGE like React when it comes to web deployment. (IF I were to use it, it would only be for native crapplets)

As the saying goes:

If you cannot make a fully functional website without JavaScript FIRST, you likely have zero business adding scripting to it!

Good scripting should enhance an already working page, NOT be the only means of providing base functionality.

To that end though, if your page relies on some scripttardery to load before the user can 'interact' with content then you have ZERO damned business making websites! That's why even as SSR "React" is incompetent asshat BULLSHIT!

Content of value, marked up semantically, targeted to specific media with CSS -- if you aren't outputting that first in a manner that works WITHOUT JavaScript, you aren't doing your uncle-huffing JOB as a web developer!

Which also means that if you are in a environment like healthcare, insurance, banking, government, and so forth, your scripttardery will also land your ass in COURT! See the US ADA and UK EQA laws, as well as most contracts in those industries demanding WCAG compliance.

.... and one of the biggest aspects of WCAG compliance is having pages work WITHOUT scripting client side!!!

Though of course, actually having semantic markup is something most developers have ZERO blasted clue how to do, just like all the other things the head-bobbing mouth-breathers are either ignorant of or outright scoff at like separation of presentation from content, progressive enhancement, graceful degradation, and so forth. Hence why so many know-nothings praise bootcrap like it was the second coming ignoring how they piss all over their markup with presentational classes defeating EVERY bit of web development progress made since 4 Strict was introduced -- hence most such dipshits vomiting up 60 to 200k of markup to do 6 to 16k's JOB! Hence the mentally enfeebled wasting 200k to half a megabyte of CSS on doing 24-32k's job! Hence the bloated agonizingly useless megabytes of scripting on websites that have NO LEGITIMATE REASON TO EVEN HAVE JAVASCRIPT ON THEM!!!

Then the scripting junkies have the unmitigated gall to claim their bloated slow loading train wreck improves the user experience? BULLCOOKIES!

Though it's real fun watching the ignorant half-assed bull go bits-up face-down when they go to deploy on a server that's sending CSP headers. <style>, style="", onevent="", <script>var scriptingHere=""</script>, href="javascript:", CSSStyleSheet.insertRule(), eval, pulling frameworks from other servers... WHAT THE?!? Sorry, they no longer exists thanks to a HTTP header we're using, your code is shit, refactor.

There are two questions here - SEO and performance and I'll answer them separately. 🙂

SEO

Should you SSR: Probably, but not for the reasons you think

Yes, Search crawlers are now able to parse and execute javascript. I remember reading about how Google uses the time between two network calls to figure out if the page has loaded - if the time is more than a mean-time it means the page load is complete.

But... that being said, the Google bot in particular is a PhantomJS script (if I remember correctly) that runs as Chrome 41. That means that you need add a lot of polyfills for things you take for granted, like native Promises and animations. This is why probably SSR makes more sense since you won't be shipping down unnecessary polyfills to all your users just so that the Google bot can render your page.

Here is a pretty neat video on this, straight from Google:

---

Performance

Should you SSR: I don't think so.

With tiny libraries like Preact and VueJS, I don't feel performance will take a huge hit. Bundle sizes are getting smaller by the day, so I don't feel you should take the effort to SSR here.

However, if your bundle size is huge, then SSR kind of makes sense.

---

Accessibility

Should you SSR: Definitely

I know it's not part of your original question, but I feel like it's a point worth mentioning. Accessibility takes a pretty big hit if you don't SSR.

There are compressing browsers like Opera mini, as well as web views that don't execute JS the way you want it to, or sometimes not execute JS at all. In cases like these, SSR is the only way you can deliver content to your user(s).

I've personally worked at a company where ~30% of our user base was on either Opera mini or UC Browser - both of which are compressing browsers that are notorious for not executing JS the way you want it to. We had to take SSR very seriously there, so as to keep those users.

Food for thought. 😄

You'll be fine in most cases for SEO.

Using JS, you limit yourself to only the Googlebot, as most search bots aren't capable of parsing it.

Beyond that, if you don't have static pages/routes, or you're not using pushState properly -- you're screwed. You'll be crawled, but when it comes time to find your site via the search, it'll be hard to rank high when only your root app URL is available. Make sure if you're linking to routes, your app is able to load the route in a separate new window (ie: yoursite.com/about-us), without going to the root of the app first and navigating to the page.

I'm not a fan of "hashbangs" for URLs either, since they aren't recognized by every service (like Google Analytics).

You also get better performance from SSR thanks to the way it renders the DOM. Rather than loading a fat JS bundle up front with all the compiled HTML, you serve the HTML first and hydrate the DOM with JS interactivity. Makes React faster since it's bogged down less with all the HTML rendering, and makes your server faster since it can offset loading of often less critical assets (like JS). You can see from these infographics the logic behind the performance benefit:

Obviously, things like SSR matter for apps that plan optimizing for performance and SEO. If you're making an app that doesn't need to be Google searched, or doesn't have to be lightning fast -- client side rendering works just fine if you do it right.