I am newish to the React world and have been building an app using RedwoodJS. One of the things that I need to add to my site is some good SEO tooling to help with growth and marketing. On my travels I’ve come across a few different concepts which seem to assist. Namely, they are:
SSR (server side rendering)
The prerender attribute on routes
RSC (React Server Components)
From what I gather these are all in different states. SSR seems to be experimental, prerender seems to be supported at the moment but has some bugs and RSC seems to be in development for the future. My questions are:
Which of these is the right tool for the job when it comes to SEO?
Is there one I should be investigating more or is any option fine?
Are there any considerations I should make beyond SEO when choosing one of these?
Given that they seem to be in different stages of the development cycle (as in some are available now and some are being worked on) should I choose one now and then migrate to another option in the future?
Any help is appreciated,
An utterly confused React novice
So you’re coming in at a weird time for React haha.
A lot of frameworks are cementing how their RSC picture will look and that will lead to some aspects being in flux and be a confusing transition.
SSR and prerender are a similar idea in that a user gets HTML with actual content on first page load. Otherwise, in an SPA(single page application) without some sort of pre-client render the user basically gets an empty div that the javascript will load in after the fact.
This is bad for SEO because the search engines will just see nothing as they crawl the site.
Prerender will bake in what the JS would’ve generated on the client before hand so that client gets served full html. Prerender will happen at build time as the app gets deployed.
SSR allows you to do a similar thing but will load in content at runtime which has more power in not needing to declare everything that needs to be prerendered.
So now the other aspects that make it a little hard are with RSC and how Redwood used to be architected vs. how it will be architected to allow these options going forward. Redwood used to be more of a backend server serves a static web page with the html css and js to load the rest of the content. Now you will likely have a frontend server and a backend server for RSC so deployments can be a little experimental.
I know there were some rough edges around SSR + prerendering and using dbAuth.
RSC you can sort of pre-refactor for by being mindful of what will run on server and then what will run client and nesting components. Biggest win with RSC is non blocking rendering with streaming.
I would try to do no SSR, no RSC, YES prerendering BUT experiment with the SSR and RSC canaries on the side to understand what is going on. SSR will be a big win once unlocked.
Thanks @QuinnsCode, I really appreciate the overview! I’d managed to find some resources on SSR and RSC but those were mainly in the context of other React frameworks, so your explanation has helped me connect the dot to RedwoodJS specifically.
Just to connect a few more dots on my side, is Big Horn (the large RedwoodJS which is being worked towards) aiming to release both SSR and RSC or are they different releases?
And finally, to add a bit of context to " prerender seems to be supported at the moment but has some bugs" I’m mainly referring to Issues · redwoodjs/redwood · GitHub.
I believe Big Horn is aiming for both. They sort of get solved together in theory.
With both you have these client React pieces, but then you want a way to render content on the server for reasons like SEO, minimize bundle sent to client, social media cards, OG, more direct control of app on your side of the wire.
In practice I found the deployment to be shaky and then I liked using dbAuth in some places and authentication wasn’t all solved there yet. In my SSR experiment I used Supabase but at that point I could just start yanking out prisma and go full supabase client for auth, db, realtime.
For myself, I want RSC for a better dashboard experience (w/ Streaming the key feature here).
An app of mine can waterfall on the fetches it needs to do. I could architect better I bet in a few places, but sometimes it’s just hard dealing with 3rd party api’s cascading needs with data that can change.
For SSR a fun experiment I got up was having a dynamic meta card image. This would mean each page refresh the card would have different image and/or text served. That is something prerender could not do at build. It would need to know the image to render then, not at runtime.
In theory I could have like an ad reel where it goes through a bunch of different products or pages vs a consistent image card. In practice I just had it displaying the error cat photos as the meta images dynamically on page refresh — error cat photos
