This website uses cookies to better the user experience of its visitors. Where applicable, this website uses a cookie control system, allowing users to allow or disallow the use of cookies on their computer/device on their first visit to the website. This complies with recent legislative requirements for websites to obtain explicit consent from users before leaving behind or reading files such as cookies on a user’s computer/device. To learn more click Cookie Policy.

Privacy preference center

Cookies are small files saved to a user’s computer/device hard drive that track, save, and store information about the user’s interactions and website use. They allow a website, through its server, to provide users with a tailored experience within the site. Users are advised to take necessary steps within their web browser security settings to block all cookies from this website and its external serving vendors if they wish to deny the use and saving of cookies from this website to their computer’s/device’s hard drive. To learn more click Cookie Policy.

Manage consent preferences

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Cookies list
Name _rg_session
Provider rubygarage.org
Retention period 2 days
Type First party
Category Necessary
Description The website session cookie is set by the server to maintain the user's session state across different pages of the website. This cookie is essential for functionalities such as login persistence, ensuring a seamless and consistent user experience. The session cookie does not store personal data and is typically deleted when the browser is closed, enhancing privacy and security.
Name m
Provider m.stripe.com
Retention period 1 year 1 month
Type Third party
Category Necessary
Description The m cookie is set by Stripe and is used to help assess the risk associated with attempted transactions on the website. This cookie plays a critical role in fraud detection by identifying and analyzing patterns of behavior to distinguish between legitimate users and potentially fraudulent activity. It enhances the security of online transactions, ensuring that only authorized payments are processed while minimizing the risk of fraud.
Name __cf_bm
Provider .pipedrive.com
Retention period 1 hour
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to support Cloudflare Bot Management. This cookie helps to identify and filter requests from bots, enhancing the security and performance of the website. By distinguishing between legitimate users and automated traffic, it ensures that the site remains protected from malicious bots and potential attacks. This functionality is crucial for maintaining the integrity and reliability of the site's operations.
Name _GRECAPTCHA
Provider .recaptcha.net
Retention period 6 months
Type Third party
Category Necessary
Description The _GRECAPTCHA cookie is set by Google reCAPTCHA to ensure that interactions with the website are from legitimate human users and not automated bots. This cookie helps protect forms, login pages, and other interactive elements from spam and abuse by analyzing user behavior. It is essential for the proper functioning of reCAPTCHA, providing a critical layer of security to maintain the integrity and reliability of the site's interactive features.
Name __cf_bm
Provider .calendly.com
Retention period 30 minutes
Type Third party
Category Necessary
Description The __cf_bm cookie is set by Cloudflare to distinguish between humans and bots. This cookie is beneficial for the website as it helps in making valid reports on the use of the website. By identifying and managing automated traffic, it ensures that analytics and performance metrics accurately reflect human user interactions, thereby enhancing site security and performance.
Name __cfruid
Provider .calendly.com
Retention period During session
Type Third party
Category Necessary
Description The __cfruid cookie is associated with websites using Cloudflare services. This cookie is used to identify trusted web traffic and enhance security. It helps Cloudflare manage and filter legitimate traffic from potentially harmful requests, thereby protecting the website from malicious activities such as DDoS attacks and ensuring reliable performance for genuine users.
Name OptanonConsent
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonConsent cookie determines whether the visitor has accepted the cookie consent box, ensuring that the consent box will not be presented again upon re-entry to the site. This cookie helps maintain the user's consent preferences and compliance with privacy regulations by storing information about the categories of cookies the user has consented to and preventing unnecessary repetition of consent requests.
Name OptanonAlertBoxClosed
Provider .calendly.com
Retention period 1 year
Type Third party
Category Necessary
Description The OptanonAlertBoxClosed cookie is set after visitors have seen a cookie information notice and, in some cases, only when they actively close the notice. It ensures that the cookie consent message is not shown again to the user, enhancing the user experience by preventing repetitive notifications. This cookie helps manage user preferences and ensures compliance with privacy regulations by recording when the notice has been acknowledged.
Name referrer_user_id
Provider .calendly.com
Retention period 14 days
Type Third party
Category Necessary
Description The referrer_user_id cookie is set by Calendly to support the booking functionality on the website. This cookie helps track the source of referrals to the booking page, enabling Calendly to attribute bookings accurately and enhance the user experience by streamlining the scheduling process. It assists in managing user sessions and preferences during the booking workflow, ensuring efficient and reliable operation.
Name _calendly_session
Provider .calendly.com
Retention period 21 days
Type Third party
Category Necessary
Description The _calendly_session cookie is set by Calendly, a meeting scheduling tool, to enable the meeting scheduler to function within the website. This cookie facilitates the scheduling process by maintaining session information, allowing visitors to book meetings and add events to their calendars seamlessly. It ensures that the scheduling workflow operates smoothly, providing a consistent and reliable user experience.
Name _gat_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _gat_UA-* cookie is a pattern type cookie set by Google Analytics, where the pattern element in the name contains the unique identity number of the Google Analytics account or website it relates to. This cookie is a variation of the _gat cookie and is used to throttle the request rate, limiting the amount of data collected by Google Analytics on high traffic websites. It helps manage the volume of data recorded, ensuring efficient performance and accurate analytics reporting.
Name _ga
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga cookie is set by Google Analytics to calculate visitor, session, and campaign data for the site's analytics reports. It helps track how users interact with the website, providing insights into site usage and performance.
Name _ga_*
Provider rubygarage.org
Retention period 1 year 1 month 4 days
Type First party
Category Analytics
Description The _ga_* cookie is set by Google Analytics to store and count page views on the website. This cookie helps track the number of visits and interactions with the website, providing valuable data for performance and user behavior analysis. It belongs to the analytics category and plays a crucial role in generating detailed usage reports for site optimization.
Name _gid
Provider rubygarage.org
Retention period 1 day
Type First party
Category Analytics
Description The _gid cookie is set by Google Analytics to store information about how visitors use a website and to create an analytics report on the website's performance. This cookie collects data on visitor behavior, including pages visited, duration of the visit, and interactions with the website, helping site owners understand and improve user experience. It is part of the analytics category and typically expires after 24 hours.
Name _dc_gtm_UA-*
Provider rubygarage.org
Retention period 1 minute
Type First party
Category Analytics
Description The _dc_gtm_UA-* cookie is set by Google Analytics to help load the Google Analytics script tag via Google Tag Manager. This cookie facilitates the efficient loading of analytics tools, ensuring that data on user behavior and website performance is accurately collected and reported. It is categorized under analytics and assists in the seamless integration and functioning of Google Analytics on the website.

A Complete Guide to Integrating Server-Side Rendering into a React App: Twitch and TikTok Experience

  • 16381 views
  • 8 min
  • Sep 18, 2020
Mykola V.

Mykola V.

IOS/Android Developer

Yana S.

Yana S.

Copywriter

Share

Since React introduced a simple way to enable server-side rendering, this type of rendering has gained popularity because of its compelling advantages. This article shows you why you should build a server-side rendered React application and explains how you can do it. 

What is server-side rendering? 

Server-side rendering (SSR) is a technique used to render a single-page application (SPA) on the server instead of in the client’s browser. 

Benefits of SSR for a React application

One of the most significant benefits of SSR is the possibility to enhance application performance. However, it’s hardly the only benefit SSR offers. Let’s look through all the benefits React server-side rendering integration can bring to your application.

Improved performance and user experience 

When an application is rendered on the client side, the application’s JavaScript file is downloaded to the client’s browser before the application page starts loading. As JavaScript files are usually big, this significantly increases the initial page loading time. 

Here’s how client-side rendering works:

react server-side rendering integration

Alternatively, you can integrate server-side rendering into your React application. With SSR, there’s no need to download a JavaScript file before the page is loaded. The client's browser immediately displays a completely rendered HTML file. This avoids the loading time required for client-side rendering. 

Let’s see how an app with server-side rendering works:

react server-side rendering

If your application uses SSR, your website visitors don’t need to wait for the application content to appear while staring at endless loaders or spinners. 

SEO friendliness

Long initial loading isn’t only an issue for users. Your users may be patient enough to wait until a page is loaded, whereas Google bots won’t. 

These bots are good at indexing static HTML pages, and they do it fast. The same can’t be said of indexing pages with JavaScript. Just like your website users, without server-side rendering, bots need to wait until a JavaScript file is downloaded and page content is shown. However, the time bots spend on one page is limited. Thus, if your website fails to load in time, bots will leave it unindexed, and consequently, unranked. 

Content sharing 

When a social network user shares a link to a server-side rendered application in a post, a snippet with an image and a title is automatically generated. 

react SSR

This snippet provides a preview of the page and lets users get additional information about the link’s contents. Thus, social network snippets can help you attract attention to your application’s content and increase traffic. 

Accurate page loading metrics

Rendering an application on the client’s end deprives the server of information about how fast the website’s content was received by the client. When an application is rendered on the client’s side, you have no analytics on how long it took for the client to see your application’s content. Thus, you won’t know if the speed is sufficient or if there’s room for improvement. 

How to build a server-side rendered React app with Next.js

Here, we provide tips you can use to integrate server-side rendering into your React application.

At RubyGarage, we use Next.js to enable SSR for React applications. First, let’s see what Next.js is and why we prefer it. 

What Next.js is and why we use it

Next.js is a robust framework built on top of React that facilitates the production of scalable React applications. The primary reason why the RubyGarage development team uses Next.js is the flexibility it offers to choose whether to render on the client end, server end, or a mix of both on a per-page basis.

Other reasons why we use Next.js

  • Improved performance — Next.js has several built-in performance optimization functionalities like route prefetching, hybrid and AMP-only page serving, and code splitting.
  • Streamlined development — The Next.js framework has numerous features that make it easier for developers to create React applications. These features include webpack customization, fast refresh (instantaneous feedback on edits made to React components), and easy debugging.
  • Universal deployment — The easiest and most common way to deploy a Next.js project is using the Vercel platform. However, it’s possible to deploy a Next.js project to any place that has a Node.js server. Moreover, a Next.js feature called Static HTML Export helps you generate a static site that can be hosted even on GitHub Pages.  
  • Growing community — The Next.js team works closely with engineers at Google and the React team at Facebook to make the framework as useful as possible. Among the companies that use Next.js are Netflix, Twitch, TikTok, Nike, and Hulu. This resulted in more and more people becoming interested in Next.js. The recently announced Next.js conference to be held on October 27, 2020, received 20,000 sign-ups in just two days. 

Now that you’re aware of what Next.js is, let’s see how you can enable SSR for a React app. 

Pre-rendering 

Next.js lets you use two different types of pre-rendering: static generation and server-side rendering. You can use one type of pre-rendering for certain pages and the other type for others. 

Let’s take a closer look at each of these types. 

Static generation 

Static generation is pre-rendering a page into HTML on the server when building the application. This method should be used for pages with more or less static content, such as those containing blog posts and documentation. 

With static generation, the server receives a list of blog posts, documentation pages, or other static pages and statically generates them. Thus, when a user visits one of these pages, no requests are sent to the server, and the user instantly sees the pre-rendered page. 

Next.js allows you to use static generation in two ways depending on whether a page needs to fetch data. For instance, if a page content doesn’t require external data, static generation can be enabled in the following way:

If a page needs to fetch information from an external source, static generation requires another approach. For example, if page content depends on external data, you need to use the function getStaticProps:

If a page has dynamic routes and the page paths depend on external data, static generation can be enabled with the help of the getStaticPaths function:

Static generation is beneficial for application performance. However, it’s not suitable for pages with frequently updated data. That’s when server-side rendering comes into play.

Server-side rendering 

Server-side rendering is the generation of HTML on demand for each user request. It makes the application responsive to users’ actions and shows users the most recent content from the database. This type of pre-rendering is suitable for pages with frequently updated information, on pages where requests can’t be predicted, and on pages with the contents that vary depending on who’s viewing them. 

Server-side rendering pre-renders a page into HTML at each client’s request to keep the page up to date. This means that each time a user visits a server-rendered page, a request is sent to the server. First, the server renders the page; then it delivers it to the user. 

It’s possible to enable SSR for a page with the help of the getServerSideProps function:

Or by using the getInitialProps function:

Thus, you don’t need to choose only one type of pre-rendering when building a new app or rebuild your whole application if you only need to change its pre-rendering type. 

Moreover, Next.js is a unique tool that allows for mixing these two types or pre-rendering in a single application.

Automatic static optimization 

Automatic static optimization is a built-in feature of Next.js that creates hybrid applications that mix different types of pre-rendering. With its help, Next.js identifies if a page can be statically generated. 

This tool determines if there’s a getServerSideProps or getInitialProps function on a page. If neither of these functions is present, it enables static generation for the page automatically. 

Additional handy features of Next.js

There are a few more tools at the disposal of Next.js we’d like to mention. 

Static HTML export

Static HTML exporting lets you export your application to static HTML that doesn’t require a Node.js server for delivery. This feature is enabled by default and doesn’t require any configuration. Static HTML export can be used only for apps that don’t require any of their pages to be rendered on the server side. 

AMP support

Next.js can convert any React page into an accelerated mobile page (AMP). AMP lets you optimize your application’s mobile web browsing experience for your users, providing outstanding speed and smooth loading. 

Conclusion

Server-side rendering is worth the effort, as it can significantly improve your application’s performance, SEO-friendliness, and traffic. Although implementing SSR may seem complicated, you can easily enable SSR with the help of powerful tools like Next.js and a team of skilled React developers.

CONTENTS

FAQ

  1. Server-side rendering (SSR) is a technique used to render a single-page application (SPA) on the server instead of rendering it on the client’s end in a browser.

    • Improved performance and user experience
    • SEO-friendliness
    • Content sharing in social networks
    • Accurate page loading metrics
  2. To enable server-side rendering for a React application, you can use the Next.js framework and its built-in features, such as two different types of pre-rendering and automatic static optimization. 


    If you’re looking for a reliable vendor to help you integrate server-side rendering into a React application, contact RubyGarage to get started ASAP.

Authors:

Mykola V.

Mykola V.

IOS/Android Developer

Yana S.

Yana S.

Copywriter

Rate this article!

Nay
So-so
Not bad
Good
Wow
9 rating, average 4.89 out of 5

Share article with

Comments (0)

There are no comments yet

Leave a comment

Subscribe via email and know it all first!