Slow page load? Not anymore — The Power of Server Side Rendering

Are you tired of websites loading slowly? Does your SEO and tech team forever debate on what is the right architecture for page speed? Well, we did it too at Pickyourtrail and we also narrowed down a solution for the same.

Before the JS applications were launched into the web-world, HTML was returned in response to the HTTP call. This was done by rendering a static HTML content file, and at times by concocting the response using server-side languages like PHP, Python or Java and responding to the same in a more effective process. Due to this, problems like poor page speed and half page loading persisted. Mostly, these cases were a side-effect of Client Side Rendering.

How does client-side rendering work?

Okay if you are supernova from the tech side we are sure you’ll be familiar with the rendering concepts. For others, here’s your explanation!

Client-side rendering is when the HTML document along with a JS file will render the rest of the website with the usage of browsers. With modern web frameworks like React, the browser received an empty document with java-script links and then rendering started, thereby the page loading started becoming inconsistent. The initial page load will be slow and since the network speed isn’t something we can gamble on, for every load to be completed, it takes close to two round trips to the server’s end before the content gets displayed to the user. But. what has to be kept in mind is that — after the first load ( the longer duration load ) the subsequent loads will be super fast.

Breaking it down further:

Step 1: Browser requests a page

Step 2: Browser requests our JS

Step 3: React app boots, requests data from the back-end

Step 4: Content captured on the screen

The initial server request returns an empty HTML file before the external files are fetched for rendering. Due to this, there is a huge possibility that the crawlers may interpret the page as empty. Also, the wait time for the users will be more since they need to wait for a longer period of time for the initial render.

More waiting time = Users lose interest and leave the page

Feels awful to find low average session duration time right?

Pickyourtrail being a Single Page Application (SPA) — our earlier implementation of the website with Client-Side Rendering (CSR) application, resulted in slowness and inconsistent SEO performance. Adding to this, our pages’ meta titles and description weren’t crawled which meant, our page was improperly rendered throughout.

Google released a report earlier this year where they concluded:

“ The average time it takes to fully load the average mobile landing page is 22 seconds. However, research also indicates 53% of people will leave a mobile page if it takes longer than 3 seconds to load.”

How does server-side rendering work?

We have the best interests of the customers like preferred activities — captured via machine learning and other essentials like flights, hotels, transfers, and activities integrated to the product with the usage of APIs. Our Pickyourtrail site is built on React at the front-end using the Node concept. But we couldn’t get the best out of it due to slow page loading issues.

With ‘Results Over Reasons’ being one of our core values — we looked at the slow page saga at a broader perspective and highlighted server-side rendering.

Solutions Pickyourtrail came up with to identify performance bottlenecks

• To optimize the CSR in order to render the application fast enough for the crawlers to crawl the actual content.
• To implement SSR for the initial rendering of the application and hydrate over client side for the further interactions.

After multiple discussions and A/B testings, we waved the green flag for Server side rendering (SSR).

Server-side rendering is when a user or a search engine crawler first requests our browser and the initial render will kick-start. Once the server receives the request, it renders the requisite element(s) into an HTML string and then assigns it as a response to the client. Later, if you choose to visit a distinct page on the website, your browser will make another request to fetch the new information. This will take place every time you hit a page, your browser does not have a cached variant of.

Again, if you are a tech supernova reading this, you might want to skip to the next section. For others however, here’s how SSR works-

• The browser requests a page
• The server loads React in memory
• The server fetches required data
• The server renders React app
• The server sends generated HTML to the browser
• Crawler/user views the content
• Calls for the JS file
• React App boots, requests data from the back-end
• App re-renders (hydrates) on the screen.

How did SSR implementation benefit us?

• Faster loading time for the initial page render
• Fully index-able HTML pages.
• Increased performance rate for our customers
• Consistency in SEO metrics

The best news is, crawlers will now see our website like any other static site on the web and will index all the content rendered on the server. Now the user does not have to wait for JS to load and instead, gets a fully-rendered HTML.

From a full rendering of page only at 7th second, we got the wait time down to 4 seconds. Magic? Nah tech ;)

Some potential pitfalls of the proposed solution

Yeah, we are being down-right honest here! The grass isn’t always greener on the other side :/

SSR gives the expected performance boost, and it is true that we will be passing the content to our users faster than using a traditional React App. The catch is that, it isn’t a scalable performance boost.

In the SSR request, the server and client function almost in a similar manner . It boots up React, renders the app and spits out HTML. Also, the renderToString() method that React uses to convert the JSX code to HTML, is slow and synchronous. This puts the server under more load, and the initial response from the server will arrive later than the planned HTML — as of the traditional React App.

You need to be extra cautious since the app will run first in a Node environment where, `window` and `document` for example are not defined. You must restrain from using them outside `componentDidMount` or without `if (typeof window != ‘undefined’)`

But the silver lining to the complexities caused by SSR is that, they can be rectified with tools like Next.js.

Icing on the cake? — We not only have our page loads done at a faster rate now, but the never ending debates between the teams also stopped. So a typical win-win case for us ;)

Want to work in a team where you get to not just solve tech problems but also instantly see customer feedback on your solution? We would love to have you on-board. Drop a mail to careers@pickyourtrail.com and we’ll get in touch with you. Also, for wanderlusts waiting to embark on trips, visit Pickyourtrail and start planning your happy holidays!