Server-side rendering has been around for awhile, but is undergoing a Renaissance as new tools like Gatsby and Next.js gain traction. So what is server-side rendering, and how is different from a client-side rendered web app? What is the advantage to server-side rendering?
Consider a web application, in which a Node server hosted by AWS serves a React application (compiled into HTML/CSS/JS). When a client-user sends a request to that web app's URL, the web app's server responds with the HTML/CSS/JS needed to load the front end of the web app. The client loads the JS, and if it's a web app of any complexity it will then fetch any resources necessary for the app to run. Consider that, in client-side rendering, a user will typically wait for one request-response cycle, wait for the JS in the response to load, and then wait for another request-response cycle.
Much has been written about user's reactions to page load times, but note that milliseconds count.
Fetching not only slows down the user experience, but presents challenges for SEO. When Google indexes your web app's URL, it doesn't wait for fetching to complete. It indexes the html that is sent back from the web app's server.
Server-side rendering is an alternative model to client-side rendering. The goal of server-side rendering is to offload as much of the work from the client to the server as possible. You can do this by rendering at run time (Next.js) or rendering at build time (Gatsby).
For example, by rendering at run time, you can make it the server's responsibility to fetch data for the web application. So when a user sends a request the app's URL, that will trigger the server to fetch data for the app, and once the fetch is resolved it will send all the HTML/CSS/JS the client needs in the response; the client won't need to fetch again. Depending on where your server is and where the storage for the data is, this can make a significant difference.
By rendering at build time, however, your server is configured to fetch any data the app needs before a client sends a response, and compose that data into static HTML/CSS/JS. Then, when a client sends a request the web app's URL, the server responds with the static HTML/CSS/JS it's already built.
Server-side rendering is ideal for web applications that don't involve significant dynamic interaction with the user, where you could ostensibly do one fetch to get all the data you need for the web app to function (blogs, smaller shops).
I hope this post has help clarify what server-side rendering is, and why it can be a powerful methodology.
Top comments (0)