blickpixel / Pixabay

Server-side rendering is not new—in fact, it’s how all websites were originally loaded before they made their way to browsers. However, things have shifted over the years with more dynamic front-ends. Many solutions have come along, but increasingly—and with the rise of isomorphic JavaScript—we’re seeing developers bring server-side rendering back for certain parts of an application to get faster loading pages with better SEO.

Here’s a look at how server-side rendering works.

CSR vs. SSR: A quick review of how websites are loaded into browsers

Whenever you visit a website, your browser makes a request to the server that contains the contents of the website—HTML, scripts, and data. That browser request and response (resulting in a loaded, interactive page) can happen in a matter of milliseconds, but of course that speed is always going to depend on a few factors.

  • The quality of your internet speed
  • The current traffic/calls being made to that site
  • How far away the server is located from you
  • If you have a cached version of the page you’re visiting in your browser
  • How the website has been optimized to be loaded, which is what we’ll talk about in this article.

When the webpage is loaded, it can either be rendered in the browser (client-side rendering) or on the server. Each is slightly different, and has its own pros and cons:

Graphic showing the difference between client side rendering and server side rendering.

What is Server-Side Rendering?

The difference lies in that HTML file your server first responds with—and what the user is seeing on screen while the browser is loading the rest of what its needs to fully render an interactive page. With server-side rendering, those HTML files on the server are pre-rendered for the browser. Without having to wait for the page to load (because the browser is loading the JavaScript and the framework), it’s totally viewable, although there’s a bit longer wait before certain parts are interactive. Even though you’re talking milliseconds, this is a bonus because the page is viewable just that much faster while other things happen behind the scenes.

Server-side Rendering Pros

While SSR isn’t new, it’s able to solve certain newer, modern problems that have arisen with the shift to client-side rendering. Originally, developers were less inclined to use SSR as much because it required the entire web page to be loaded every time something changed in the View. Dynamic front-ends, interactive content, and sleek desktop-like user experiences became the norm, but they added complexity, leading to bloated client-side implementations with blank loading screens and other lags in performance. That wait time might be milliseconds, but it was noticeable enough to look for a less-limiting solution.

If you’re looking for instant page loads or the ability to handle a lot of dynamic content that needs to change in realtime within the View, SSR with a JavaScript library like React has some pros:

  • Better performance for end users. Server-side rendering the View of an application means end users see the page faster because the HTML has been pre-rendered before it gets to the browser. When a user loads a webpage, they get to see that initial view of the page without having to wait for their browser to download the JavaScript. The page isn’t interactive (yet), but you’re getting quicker “above the fold” loads—no blank, white screen. (Although it’s possible to replace that blank screen with an image or icon.)
  • Better customer engagement. The above can be argued to contribute to better engagement because that speed creates a smoother user experience.
  • Easy to manage code. Creating JavaScript applications that share code across both the front and back ends with frameworks and libraries like React can be easier codebases to manage.
  • SEO-friendly. The beautiful thing about SSR is that it’s also great for search engine optimization (SEO), since most search engines have an easier time crawling and understanding pre-rendered HTML views.
  • Data is synced through the use of WebSockets, a protocol that allows an interactive communication between server and browser. An app can be displayed in real-time without a page refresh for a more streamlined UX.

SSR Is Not a Silver Bullet

It’s important to note that there are drawbacks and circumstances when SSR is not going to always be the better option. Don’t expect to implement SSR in your application and immediately see incredible performance boosts across the board. It depends on what you’re building, the latency of your server, and other aspects to be the right fit. A few things to note about SSR:

  • Larger document size. That pre-rendered HTML file is going to be larger.
  • Time to First Byte (TTFB) is slower because the server will have to be doing a bit more work up front.
  • Server will be able to execute fewer requests. While this request is occurring, there will be less server throughput.

The Rise of Isomorphic JavaScript

Isomorphic (or, universal) JavaScript allows you to create “universal apps” that are able to work on both the server and client-side. While there’s a bit of a debate as to whether these terms are truly talking about the same thing, the general consensus was that we needed a buzzword to cover two phenomena:

  • The fact that you can now write JavaScript code that is able to run across multiple environments (client-side, server-side, natively on mobile devices, etc.) with little to no modifications.
  • The fact that you can now create applications that can switch between client-side and server-side rendering without losing state.

The first feature is about programmer productivity, the ease with being able to write code that looks the same across multiple platforms. The second feature is functional, the ability to fast boot with server-side rendering and seamlessly switch to the dynamic client-side rendering that made single page applications (SPAs) so popular—harnessing the best of both worlds. JavaScript frameworks that allow you to do these two things are permitted to use the Isomorphic (or Universal) buzzword.

How to Optimize Your App for Server-Side Rendering

Many JavaScript frameworks like Angular 2, Vue.js, and React use both client-side and server-side rendering. Many generally use client-side rendering out of the box, so to optimize code to be server-side rendered, developers will have to know certain technologies in that framework ecosystem to help them implement SSR. SSR libraries and frameworks that can be used on top of these frameworks. For example, if you’ve built an Angular 2 app, you might insert a React component with the Redux library. Other options include:

With newer frameworks like React with its Virtual DOM, the documentation to get started with SSR is simple enough for a beginner developer to pick up. If you’re looking to hire a developer to help make portions of your app optimized for SSR, specify SSR as a required experience in your job post. Or, you might opt to use a back-end framework like Ruby on Rails for server-side rendering along with a lighter front-end framework—there are plenty of combinations to try with documentation available all around the web to help you out.