Who are we?
Truebil is an online marketplace for certified used cars. It’s a one-stop solution that includes title transfer, insurance, loans, and service warranties. In a mobile-first market like India, we witness almost 95% of our 1.4 monthly active users experiencing Truebil through their smartphones. Thus we had no ambiguity of approach in taking a mobile-first course.
A mobile-first approach also meant that a significant number of users are accessing their internet through broadband network connections. Add to it the fact that Truebil’s web app, and not a native app, is the primary access point for our users, we knew we needed to chase speed. Web performance metrics like page load time and time to first meaningful paint directly affect user engagement and enhances our business like nothing else. This is when we decided to shift from client-side rendering to server-side rendering and this our story.
What is Server-Side Rendering?
Today a lot of web apps are generated by Javascript. What that means is, in an HTTP request-response protocol, a request from the browser to the server is served back with an empty HTML doc and a heavy JS bundle which is then processed down to an HTML doc by the browser natively on the device. This design is termed client-side rendering.
On the contrary, in a server-side rendering design, the server generates HTML and responds with the ready-to-be-rendered HTML doc which is now almost immediately viewable on the device. This significantly enhances the first meaningful paint(FMP) time, especially on underpowered devices or ones with slow connections.
However, this automatically doesn’t imply that SSR is the best course for you to take, as you will learn basic incentives behind taking up the relatively complex development approach.
Why do we do it?
The most important enhancements that we went after during the shift were First Meaningful Paint (FMP), Time To Interactive (TTI) and Search Engine Optimization (SEO). While SSR helps reduce FMP and TTI via the reduction in download time and the early viewability, SEO is another reason why one might look at SSR. Most search engines are better optimized to parse HTML docs than JS files. While Google has an improved JS parsing, HTML response still means that the search engine will better be able to rank you up in relevant searches.
How we did it?
Our approach has been a hybrid one. Popular web applications like Netflix are also known to also have taken the course. Here, the landing page, the first response to the browser follows an SSR design while subsequent responses follow CSR design. The first response will present a ready-to-be-rendered HTML doc and when the web page is viewable and interactive, the browser then pre-fetches JS bundle and other resources for the next pages. So the next pages user travels to are client-side rendered but with improved performance.
For this to work, the JS code must be designed to execute both CSR and SSR. A web app developed with this philosophy is called a universal web app.
This serves all the purposes of SSR from performance to SEO, while keeping the average time to first byte metric down. We have employed Nuxt.js framework to accomplish this.
Impact we created
Talking in numbers, FMP is reduced from 3.5-5 seconds to 1 second, TTI is reduced from 9 seconds to 5 seconds, while our organic traffic has seen a jump of approx. 5-10%. The better performance also helped improve our internal business metrics like lead generation by a fascinating 10%. Talk about impact. This reinforces our commitment to building a first-class web application with a focus on user experience and our reliance on outstanding engineering.
Here are detailed performance effects from SSR and prefetching approach:
