In 2018, does SSR still provide an advantage over CSR for: (1) SEO, (2) performance?
I have read a number of articles singing praises for one or the other. SEO and performance are the two greatest weapons that SSR seems to wield over CSR. However it seems that in 2018 most search providers have crawlers capable of parsing JS and some async calls (up to 10s for Google). And with frameworks like Preact being tiny, especially when gzipped, I don't really buy the performance argument either. Has anyone come across a definitive, recent writeup that compares the SEO and rendering performance of SSR and CSR?
There are two questions here - SEO and performance and I'll answer them separately. 🙂
Should you SSR: Probably, but not for the reasons you think
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:
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.
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.
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:
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!
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!!!
Then the scripting junkies have the unmitigated gall to claim their bloated slow loading train wreck improves the user experience? BULLCOOKIES!
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.
Please use an hybrid/enhancement approach:
SSR for first page load (benefits: SEO, accessibility, speed)
Then if browser supports JS, use a router, catch link clicks, and do CSR for faster and more app-like transitions (details like GA events can be done programmatically).
Plus, for SEO, never underestimate the importance of a clean and full sitemap no matter the approach you choose.
Test your CSR with 'fetch as bingbot', 'fetch as googlebot' .
It depends. In some countries you might only get a 2G connection. Camping sites have terrible flaky wifi. Both download size and latency becomes an issue. CSR takes time to load and run JS, but once running, an CSR app can react snappier (optimistic UI).
If the requirement is: offline-first app, then CSR is the only option.