Improving Chat Performance and Building a Custom UI Component Library for Dream11

Challenge

This goal was time-sensitive as a cricket tournament was coming up. As it’s one of the most popular sports in India, Dream11 wanted to be ready for the influx of users. 

Secondly, we wanted to ensure that the in-house team could seamlessly develop the app in the future. That’s why we created a custom components library.

That’s why our collaboration focused on two main areas:

1. Optimizing chat performance to deliver a smooth user experience to prevent churn and brand reputation issues.‍
2. Creating a new design system with reference to the React Native Paper library to make further development more cost and time-efficient.
   
   First, we cleaned up the codebase from React Native anti-patterns, libraries, and components misusage. Once we cleaned the codebase, we introduced the DMAIC optimization cycle.
   ‍

Performance optimization

The DMAIC cycle looks like this:

Step 1 – Define – laser focus on already confirmed/reported issues such as re-renders and the creation of a backlog of potential performance improvements.

Step 2 – Measure – Macro tool measurements.

Step 3 – Analyze – selection of the most promising performance changes.

Step 4 – Improve – implementation in line with the latest React Native best practices.

Step 5 – Control – the Marco tool measurement re-run compared to the 4.58.0 native version. 

To identify all areas that need improvement, we profiled the whole app. The comprehensive approach combined with the DMAIC methodology allowed us to pinpoint the issues that would help our client achieve its business goals. 

Performance Analysis

We began our work with performance analysis. We analyzed four areas of focus:

1. Initial load of Chat List
2. Loading of messages in the Chat window
3. Scrolling Through the Chat List
4. Scrolling Through the Chat Window

In our experts’ opinion, the most critical problems of the app that needed immediate addressing included slow rendering time of chats, slow load times on chats for subsequent visits, frame junk when scrolling, slow parsing of crypto nodes, and slow parsing of data models. 

Performance Findings

Performance analysis allowed us to prepare a list of performance findings – areas that we wanted to optimize in the first place because they yield the biggest benefits for the app’s users.

Slow rendering time on chats

The first problem we needed to tackle was slow rendering time on chats. This was top priority for Dream11, as slow chats had a direct negative impact on user experience. 

To optimize the rendering time, we had to improve several aspects of the app. 

First, we minimize the bundle size. We excluded parts unrelated to the chat from the bundle to do that. Ultimately, we reduced the bundle size from 50 MB to 11 MB.

We got rid of unnecessary re-renders. This improvement allowed us to optimize multiple parts of the Chat screen. As a result, we reduced the average mounting time by 30%.

Our initial performance analysis discovered that the app uses a JS bundle instead of highly-optimized Hermes. That caused React Native to parse much data when the Chat mounted. This change improved the initial load time between 60 and 70%.

In the next step, we disabled lazy loading. Lazy loading consumed additional resources during important interactions. Disabling lazy loading improved the totla screen mount time by 5% on low-end devices, as the app doesn’t have to parse extra chunks in memory. 

Another performance issues we solved was shimmers optimization. We replaced the implementation done with <rte-code>Animated Gradients<rte-code> and replaced it with <rte-code>NativeShimmers<rte-code>. This action improved rendering of shimmers by over 60%. But we didn’t stop there. Further optimization with the <rte-code>MaskedView<rte-code> approach allowed us to reach a final 88% improvement. 

And last but not least, we calculated Animated styles only for already mounted components. We optimized the mounting time for each Chat message by 40%. 

Slow load times on chats for subsequent visits

The Android Fragment of the React Native Chat screen wasn’t reused when the user came back from the home tab to the chat. That resulted in unnecessary re-mounting of the whole screen. 

That change resulted in subsequent navigation to chat screen being instant. 

Frame junk when scrolling chat screen

Another performance aspect we wanted to improve was frame junk when scrolling. We encountered this problem while profiling chat screen. To make the experience more user-friendly, we decided to implement Flashlist instead of Flatlist. We enhance the chat screen to 21 FPS on low-end devices

Slow parsing of crypto-nodes

In Dream11 app, the <rte-code>SendBird<rte-code> data is parsed into models. The models used a lot of resources and included decrypting data using <rte-code>crypto-js<rte-code>. 

To solve this issue, we introduced <rte-code>rect-native-quick-crypto<rte-code> the time to parse improved by 90% on a real device. 

Slow parsing of data models

As explained above, data from <rte-code>sendBird<rte-code> was parsed into models. These models were associated with each item in the list. As the models were bloated with unnecessary data, we analysed them and removed the data models didn’t need to operate. As a result, we observed a decrease in the component mounting time.

Key Optimization Gains

The optimization introduced by our team directly impacted user experience. We were able to address the issues that we uncovered during the performance analysis phase. 

The key gains included:

• up to 500% quicker parsing of crypto models, thanks to switching to more performant modules. 
• 50% faster rendering time for chats. We were able to achieve it by simplifying logic. 
• up to 50% quicker load times for chats on subsequent visits, thanks to optimized memoisation. 
• decreasing shimmer render time by 88% due to using <rte-code>MaskedViewNativeShimmer<rte-code> approach. 
• up to 18% less frame junk when scrolling by using Native Stack Navigator and Flashlist
  ‍

Delivering the library

Before developing components, we received mockup designs created in Figma and acceptance criteria for each element. 

Using the Figma models and acceptance criteria, we refined the tasks. The Dream11 team was available to dispel any doubts. 

We divided the project into four parts:

• Setup,
• Design foundations, 
• Development of the components, and
• Testing

First, we set up a fork based on the React Native Paper library.

To automate the integration of the code written by two of our React Native developers, we set up continuous integration. The code was always up to date regardless of who was working on the project. 

Finally, we set up a Storybook to test the components. 

In the second part, we developed the basis of the design – color, layout, and typography. 

Once we had the basics down, we started working on the UI library components. 

The components we developed included:

• AppBar,
• TextField.
• Button,
• Icon Button,
• Toast, which included animation and swipe-to-dismiss,
• Match Status,
• Search, and
• many more!

After development, we performed unit, integration, and accessibility tests and ran the storybook stories for every component. 

We presented finished components during demo sessions to Dream11’s key stakeholders. During the meetings, we received feedback and implemented it later on. But, because we got comprehensive explanation and acceptance criteria initially, most components were accepted on the first try. 

More performant app and time and cost-efficient solution for future development

As a result of our partnership, Dream11 now has a performant app that fulfills the needs of its end-users. Sports fans with low-end Android devices enjoy a smoother and faster chat. The performance improvement directly impacts business metrics, such as churn rate or new customer acquisition. 

Moreover, a UI component library tailored to their needs. The in-house team can develop the app faster, thus reducing the costs of building new screens. Moreover, the users can enjoy an improved user experience as buttons and other components behave consistently across the app.