Understanding Server-Side Rendering

In this article, we’re going to learn about Server-Side Rendering, what this technique is and why we should consider it when we’re creating new apps. We’re going to learn how we can benefit from server-side rendered apps, including improving our SEO and making it easier for Google to index our pages.

Server-Side Rendering is not a new technique, but a lot of people don’t understand the concepts behind it, how it can benefit us, why we should use it, and where and when should we use this technique to get a better user experience.

So, first, let’s read a brief introduction about some concepts that we should understand: TTFB and SEO. Then, we’re going to have a brief introduction to Client-Side Rendering, the standard way that we’ve been building apps since the beginning of web development. And then finally we’re going to learn more about Server-Side Rendering and its benefits.

Introduction

Since the beginning of the web, we have always been creating new techniques and improving the old ones. With apps, we change our ways to improve our work and drive better results for our users. Back at the start, when we started to create applications using just raw HTML and CSS — and little bit of jQuery — we didn’t have a lot of the terms and techniques that we have nowadays. We didn’t know anything about Server-Side Rendering, and for a long time we didn’t even know that it was possible. We were more worried about delivering new features, without any concern about UX/UI or app performance. But at some point, it got inviable and we had to start to think about those concepts.

Since for so long performance on our apps wasn’t a concern, improving our techniques for building better apps was slow at first. But now it is one of our primary concerns — we’re always striving for better app performance — and that has pushed us to create a lot of techniques in the last couple of years, such as Server-Side Rendering.

If you’ve tried to create a JavaScript app recently, using any type of framework or library that’s been widely used — such as React, Vue, Angular — you know that two of the most painful points about it are Time to First Byte (TTFB) and also the famous SEO (Search Engine Optimization).

Someone searches your website on Google, and when the user clicks on the link to go to your website, the web browser requests information from the server to display it to the user. Time to First Byte (TTFB) is just the number of milliseconds it takes for the browser to receive the first byte of the response from your web server. This is one of the most important metrics that you can measure on your website, because if you have a higher TTFB on your website, that means it’ll take longer to render the website to your user, which could mean that they leave your website, leaving you with empty hands and without any users.

Another relevant point to having a good TTFB is that Google uses it as an indicator for ranking. By having a strong ranking on Google, everyone knows that you can get more traffic and also can generate more leads to your website.

After you create your app, when you’re deploying it to see the first users entering your website and finally testing the result of a lot of work and creativity, getting traffic is still one of the most difficult points. Some people like to pay for traffic. You can use Google Ads for that, to have a campaign run on a specific niche and gain traffic on your website.

When you’re creating a new web app, to start to get organic, unpaid traffic from the search engine — mostly Google — we need to have a good SEO (Search Engine Optimization). SEO is basically the process of optimizing your website to get a higher rank on the search engine, getting more organic and unpaid traffic, by making some changes to your website design and content to make a more attractive website. This process of optimizing your website for better SEO can get quite complex, and it can take a lot of time and effort to have the best SEO on your app to get a better ranking on the search engine.

But you might be wondering now what those two points — TTFB and SEO — have to do with Server-Side Rendering. Well, everything! Since we try to create powerful web apps and have a better user experience, we need to have a decent TTFB, to not take long to render the content to the user, and also have a strong SEO to be ranked well on Google, being highly ranked means more organic traffic, which can mean more leads.

Let’s learn a bit more about Client-Side Rendering and then learn more about Server-Side Rendering so we can understand the differences.

Client-Side Rendering

If you’ve been working in web development and have been creating web apps for the last few years, there’s a high chance that you’ve been creating client-side rendered apps without noticing it. It became the standard way to create apps, and we’ve been benefiting from it a lot. But there are some points that we must consider to understand if Client-Side Rendering is the best approach for our application, as we understand and weigh its core problems.

When you’re creating JavaScript web apps — any framework or library can be used here as an example — you’re rendering browser content using JavaScript. Basically what’s happening is: you receive your HTML document, and JavaScript will help you with the rendering of the app. That’s basically the concept of Client-Side Rendering — the data is retrieved from the server, and processed at the browser to display to the user.

Image by ReactPWA

That means that the render of your page is totally up to the user, depending on what kind of network connection they’re using at the moment, and also the device they’re using. Let’s imagine that they’re using a smartphone, and they’re using a slow 3G network connection. If the application is too heavy, it’s going to take a lot of time to render the page.

Some of the cons of using Client-Side Rendering are:

• TTFB (Time to First Byte) and Performance — For most people, one of the most painful points of client-side rendered apps is the performance. While pages on server-side rendered apps are ready to be rendered, client-side rendered apps load a browser with an empty document while waiting for JavaScript to help you render the page. You still can have a really fast web app, but you’ll need to pay attention to some minor details in order to achieve that level of interaction and performance in your app.

• **SEO (Search Engine Optimization) ** — SEO is still one of the cons of having a client-side rendered app. You can achieve a nice level of SEO in your app with a client-side rendered app, but the time and effort that you must put in to achieve it is significant.

• Concerns — If you’re planning to create a client-side rendered web app, you need to attach some concerns and points that you must pay attention to in order to achieve a nice and well client-side rendered web app, such as bundling, transpiling, linting, code-splitting, lazy loading, etc.

That’s only a brief look at the cons that we have in Client-Side Rendering, but that doesn’t mean that you should never use it. You should consider what you can and want to achieve in your application, define a plan and the right technique for it, and go ahead.

Client-side rendered apps are widely used nowadays, and they won’t die any time soon. Now that we know a little bit about Client-Side Rendering, let’s finally learn about Server-Side Rendering.

Server-Side Rendering

When we have a client-side rendered app, we know that our application is rendered on the client. As you can suppose, the Server-Side Rendering concept is the opposite — your page is ready to be rendered by the server, without needing the client to wait for anything.

Every time the user enters a server-side rendered app, the client will request the information for the server, and the server will deliver the fully loaded page to the client. First, the application will be rendered as just raw HTML and CSS, to render the first view to the user. Then, while the DOM is being rendered, the app will be parsed and initialized. Only after that, will the application be fully loaded and the user be able to interact.

Image by ReactPWA

That’s one of the most beautiful things about Server-Side Rendering — you don’t need to wait for JavaScript to load the content for you, the server already does that. As you can imagine, Server-Side Rendering has a lot of benefits such as:

• Performance — Your content is totally loaded on the server-side, which means you can gain some extra and precious milliseconds or even full seconds while rendering your app.

• SEO — The content is totally crawlable by Google — or any other search engine — resulting in a better rank and more organic and unpaid traffic on your app.

• Load the application without JavaScript — If a user tried to load the application without JavaScript enabled, it wouldn’t be a problem since all the content is loaded on the server-side.

Those are only some of the benefits that you can have with Server-Side Rendering, but it comes with some costs as well. When you’re starting to create a new application, it’s very important that you define what type of application you want it to be, and define the most important points that you need to achieve in order to deliver the most genuine and balanced experience to your client.

Conclusion

In this article, we learned how browsers work and about some important metrics for search engines such as Time to First Byte (TTFB) and SEO (Search Engine Optimization). Also, to understand about Server-Side Rendering, we learned about Client-Side Rendering. Server-Side Rendering is basically the technique to return the whole page rendered from the server, and we learned how it can benefit us with a better and performative application.