Photo by Daniel H. Tong on Unsplash
What is SSR and why should you care?
SSR stands for Server Side Rendering. I will talk mostly abo...
For further actions, you may consider blocking this person and/or reporting abuse
As interesting this topic is - didn't we have this in the 2000's? Where all these rich serverside frameworks emerged? What I find a smart move is to serve a basic - perhaps even statically prerendered - version of the site and hydrate it on the client. But I did that in 2013 with JSPs, where I painted everything needed already on the page; including a script tag with serialized JSON to have an initial state going.
Don't get me wrong: I like the idea moving towards a Jam Stack, but it is something like new vine in old bottles :]
Was it actual hydration or re-render?
It wasn't called hydration at the time. What I did was rendering an initial state of a document, put a script block inside where the state was rendered as a variable - simply an object, which was then picked up by backbone to get the frontend going.
That gave me a fast startup and a fully SPA-like UX in a traditional multidocument application.
We moved an existing application from traditional serverside baked in the early 2000s to a more modern version, where you had small SPAs so to say.
Unfortunately I left in 2015. So I can't tell how it came out. But a full SPA would only be consequential. 😉
So in a sense we played at the time with such types of concepts already.
Only, that you could now dismiss fully fledged web frameworks and go with Gatsby or vuepres mix and match with APIs living in AWS or on premise.
There's a lot more attention being paid to SSR lately. Server-side React has definitely been one way to do it, but others have taken a nearly no JavaScript necessary approach, such as Texas for Elixir/Phoenix. Excellent read!
I'm quite ashamed that there's a lot of terms here that I don't fully understand. Oh btw, that cover photo is spooky once your post reached the top :/
First Meaningful Paint - see this image
source
I'm ashamed that you feel like that. I didn't try to sound smart, it's just how I call it at work. Please don't feel like that. I will try to explain some of those, feel free to ask questions. This post was more like I thought out loud about pros and cons. I guess this type of posts are not beginner friendly
Thanks for the thorough follow up! I'm not really huge into the JS ecosystem so SSR is still hazy. So let's say I built a React implementation of a shopping cart and stuff it into a
shopping-cart.js. If a client issues a GET request to/shop, I build a template, include the relevant HTML and CSS and of course the JS file, and return that to the client. How is SSR different from that?You know how typical React based website looks like - there is html with header, scripts, styles but without actual content, like it has
<div id="main"></div>where React will be mounted as soon as application loads in the browser. With SSR thisdivwill be prefilled with HTML, the same one as React would generate in the browser, but now it is done on the server. Make sense?Oh yeah I get it now. "rendering" in this context pertains to the
ReactDOM.render(document.getElementById('root'), <ShoppingCart />);which happens on the server as opposed to being done once the client loads the page.Graceful degradation - is when you develop for modern browsers first and for less modern browsers (category which also includes browsers with disabled JS) you provide less features, but still it is decent experience, not something broken.
SSR - server side rendering. React components kind of decoupled from render implementation, so you can use
rect-domin the browser and it will generate DOM nodes, but it will generate strings on the server. This decoupling allows you to render React applications on the server. Please tell me if I failed to explain. Side note: there are also renderers for native applications, for Canvas, for terminal.Nice thoughts. I've actually left SSR due to many reasons. I've written a blog post about it. Can you look into it and share your thoughts? coffeencoding.com/why-ssr-is-not-a...
It has similar ideas and I generally agree, except one bit
Not quite correct. It has two phases, and first phase is done without browser. So prerendered pages get indexed faster. Google uses Chrome 40-ish for indexing, so it means your SPA should work in Chrome 40-ish. A lot of SPAs don't provide polyfills for it and basically fail to render, and googlebot sees JS error instead of content. So prerendered content (SSR or prerendering) is always a safe bet.
The last time I checked, Google is using Chrome 54. I have a few websites without SSR, there haven't been any problems with indexing.
But yes, if your site has thousands of pages, SSR can improve indexing speed
source: developers.google.com/search/docs/...
Oops! sorry, somewhere I read it's 54. My mistake!
I'll correct it
Great post! One thing I would add is SSR matters a lot when using Web caching / CDNs such as Akamai. It means we can skip going to the origin of the data to request and build these pages and highly reduce the load on the data services.
Unless we are talking about non-cacheable data, like the user data, but for these then client-side rendering can be more appropriate.
I actually wrote a tool that has support for server side rendering. It's like Netlify, but with SSR support.
The advantages are:
Check it out: stormkit.io (It's currently in its alpha stage)
Guys just put Varnish in front of everything and forget about multiplying requests. The first load will do the calculations and all the other times it will return already generated desired http response string without even waking up a web server.
I know I know every app has different needs, you cannot just do full page caching, it depends on session, cookies and etc. But if you invest time in configuration it right (with Varnish it can be pain in da a$$), you can achieve an amazing performance.
Maybe HTTP caching is a bit off topic here, but I think it can be really good friends of SSR.
Great post, thanks for sharing!
If your server in Europe, but client is in Japan SSR will not help you here
WHY?
Hi! Thanks for the article. Did you ever take a look at github.com/shakacode/react_on_rails? Lots of sites with Rails backends have server-side rendered React.
I don't get to work with Rails a lot recently, but otherwise I guess this is a good choice
I think you should explain in a bit more detail what are SSR, First Meaningful Paint and Graceful degradation for someone that is not familiar with it.
Thanks for the comment. I guess title and content misaligned a bit. This is more pros and cons article instead of introduction for the beginners. I can add definitions, but this wasn't initial purpose of the article. I will change title appropriately.
I like to use a dedicated render service and a separate API service. You can run the rendering on a node server or serverless. The API might use a totally different technology in this case.