How redBus scaled mobile web — PWA and other optimisations
Mobile Web has been an important growth medium for redBus and we get a whole lot of new users everyday from this channel. With this in mind, we wanted to provide a simple and elegant experience to our new customers plus serve/engage with our existing mobile web users efficiently.
This however required us to handle the 3 common challenges dogging mobile web applications
- Network drops
- Different types of browsers and devices.
- Time spent for rendering on to the browser
In addition to the above, we also wanted to ensure that the application scales well for our geographic expansion efforts taking in to consideration — language, templates, timezone, different types of payment etc ..
Our Old Stack
More or less, our mobile web had this stack (above). We were doing well even here, but had problems specifically around
- TTFB — Time for first byte
- Page Speed Score
- Time spent on rendering on to the browser
Looking at the various stack available out there, we zeroed on ReactJS <> NodeJS stack. We decided with ReactJS for the scalable component model and fast rendering and NodeJS for its performance. Another important aspect of ReactJS is its Isomorphic rendering of pages — this makes it SEO friendly as well.
Our New Tech Stack of Mobile Web Platform
- ReactJS — JS Library for the App.
- Dust.js — Streaming views .
- NodeJs — Application Backend.
- Webpack — JS/CSS Module Bundler.
- Gulp — For Build and deployment process.
- ES6/Babel — ES6 to ES5 conversion.
- Livereload — Ease of development with automated build process.
While we improved and revamped our Tech Stack, we also put in a few innovations to improve usage experience especially on slow networks / devices. These include :
- Canvas-sing the Seat Layout
- Solr-izing city suggestions
- Progressive Web Apps [PWA]
Canvas-sing the Seat Layout — Accelerated rendering
We converted our DOM based Seat Layout to a HTML5 Canvas model for Mobile customers. Canvas improved the rendering performance because the hardware acceleration makes canvas drawing really fast, as the rendering is using the GPU rather than CPU. Also this view is more adaptable for both Horizontal, Vertical and can scale for different dimensions. We also keep a snapshot of customer seat selection from canvas for the future reference.
Seat Layout on Desktop
Seat Layout on Mobile Web
Solr-izing City Suggestions — What you need, right on top
We have enabled location based search in some geographies — with this the customer can search by the actual Boarding Point / Dropping Point (we call this as BP-DP enabled search). Obviously the response time of city suggestions should be really fast and should keep track of the context (geo-location and from parameters).
Solr was a no-brainer here and our auto suggestion is built on top of this. Based on the popularity of the selections, we score the entires and thus ensured there are few minimal clicks required.
As an example
[Che] : Chennai city comes as the first result as it is more popular and frequently used by customers.
Progressive Web Apps (PWA)
There has been a lot of work done in the industry on this front. PWA as stated by Google tries to get the same experience of a native App on to the mobile web. Service Worker is the underlying technology for caching, provides an LRU cache used in our app for storing previous visited pages and search results on the browse page. With Service Workers, we can intercept every network request and serve a response from cache even when the user is offline.
The salient features adopted in redBus part of PWA effort are:
- Add to Home screen — User will be able add Brand icon to device home screen, which is shortcut to access Mobile Web App.
- Splash Screen — Will give an App like experience during the Mobile Web App load.
- Full Screen experience — Hide the browser’s address bar, to show more App content.
- Caching App shell and Data offline for the visited pages — Customer can view the Home, SRP, Upcoming tickets etc. in offline mode as well. All the API calls will look for the recent updated content in cache first and call the network only if data is not available in cache.
Lighthouse is one of the powerful tool introduced by Google for auditing PWA features. This tool is evolving as we speak and is a good benchmark to see how we perform.
We scored a 100
Our efforts got us a 100/100 in the Lighthouse score, no mean effort!
A little on how we did PWA
Progressive web apps tends to be architected around the concept of an App Shell.
- Migration to Single Page Application(SPA) for Caching the App shell and the static assets helped in improving the funnel throughput.
- To reduce page load time we asynchronously prefetch the static assets (stored on our CDN) of upcoming pages in the booking funnel.
- For further optimisation, on our bus results page we have implemented an infinite scrolling technique which recycles the below fold content. We used this to achieve infinite scrolling.
- Offline — Background SYNC — https://developers.google.com/web/updates/2015/12/background-sync — When our customers do not have network connectivity, the below message is shown to them. Automatically when they are back in the network the notification is shown to them even if the browser is closed.
Overall Mobile Web for Bus/Hotels experienced an excellent growth. Some of the KPIs are :
- Session duration has increased by 18%
- Returning users have increased by 16%
- Reduced ~20% load on servers due to cached API Calls
- Render time decreased from 310ms to 16ms search results page with >400 results
- Home page render time decreased from 38ms to 1.2ms when SSR with react was removed
- Overall first load HTML size is a tiny 11kb
Render performance improvement of search page after moving to react-infinite as the renderer. Measured using react-perf tools.
Overall we feel the mobile browser is getting stronger and evolving every day. All this effort would not have been possible without some smart folks at redBus who take a lot of pride in their development.
Originally published at blog.redbus.in on April 28, 2017.