Popshop Live is a popular e-commerce live-streaming platform that was looking to speed up its mobile app. Over the past year, the app had seen 100% user growth, and was rapidly pushing up against the limits of its mobile infrastructure: core user flows like launching the app and displaying products for sale were now taking 2-3 seconds on high-end devices. Cognizant of the fact that customers drop off for any wait past 500 milliseconds, the Popshop Live team turned to Product Science for help.
What Product Science does for clients
Product Science is a self-service performance management platform for mobile businesses. Using our flagship product, the PS Tool, we record traces of common actions (like launching the app) in customers’ apps, analyze them, and enable teams to identify potential optimizations.
Unlike many tools which focus on what is going on in a particular thread PS focuses on connections between threads. This gives customers a more detailed view into what’s going on in the app, and makes it easier to diagnose issues.
We offer automatic pattern detection that allows our customers to optimize their apps independently with minimal assistance from our team. At this time, customers connect their projects and using our technology are able to diagnose flows themselves, identifying insights and recommendations based on analysis with the PS Tool.
How Product Science helped Popshop Live
Popshop Live’s mobile app was built on Android with React Native. During the first thirty days of working with the tool, Product Science identified optimizations for starting the app and opening products that resulted in over 4 seconds of total performance savings. This included fixing suboptimal API requests and pre-loading fonts, comments, and other content.
The Results
App Start Flow
Background
The app start flow is from the moment the app starts to the moment when the loading screen disappears.
Insights
The app start flow is One of the biggest wins that Product Science was able to deliver for the customer was in helping them to identify suboptimal API requests in the app start flow.
In particular, OkHttp, the HTTP client that the customer was using, defaulted to allowing only 5 concurrent network requests, which meant that any more requests above that were bottlenecked.
In the image below (Figure 2), the PS Tool shows those five requests. A blue flag is placed where the first network request finishes. The screenshot also shows a sixth network request, circled towards the bottom right, which isn't allowed to begin while there are five running already. This delayed request is marked by the same blue flag. from the moment the app starts to the moment when the loading screen disappears.
Additionally, two separate methods in the code were making the same (redundant) API request, contributing another 1400 ms to the delay (Figure 3).
Fortunately, the fixes for these suboptimal API requests were relatively simple. The max number of concurrent requests for OkHttp could be increased with a simple configuration change. For the redundant API calls, we recommended using shareReplay(1). This would cache the data rather than re-fetching it.
Ultimately, Product Science helped shave off over two seconds from the app start time.
Main Search Screen Flow
Background
The main search screen flow covers the following sequence:
Open App → Tap Search Icon → Choose Search Category → Type Search → Search →Scroll Results
Insights
When doing a search on Popshop Live, users have the option to filter their search by account, by show, or by product. The default is to search by account. But if the user chooses another search category, they have to wait between 173ms and 720ms for the initial data for that category to load before starting a search.
Product Science recommended proactively loading initial data for search in all three tabs, rather than waiting for a user to switch tabs and load data reactively. This would decrease the wait time for a user searching for data by, on average, 446 ms.
Open Product Flow
Background
The open product flow starts when a user scrolls down the home page before choosing a livestream (a “live”, associated with a product) and ends when the purchase page for a product is done loading.
Insights
The PS Tool identified three delays for Open Product Flow. The first was that loading for the live previews on the homepage only began after the user started scrolling.
The PS Tool determined that these previews could be loaded preemptively, before the user starts scrolling, to significantly speed up the homepage experience and allow users to open products faster.
The second was that after selecting a product livestream, there was a delay of ~620ms while waiting for the comments to load. The PS Tool recommended that the comments could be fetched earlier – for example when the live previews were loaded.
Finally, the PS Tool identified that after opening the livestream and selecting the product in the bottom right corner, there was a delay of ~1030ms while waiting for the product image to load. Again, a possible solution was to fetch the product image earlier (perhaps upon the loading of the livestream).
While it's easy to recommend a developer to preload content, there is a balance to be struck. Loading content at the last second requires the user to wait. But over-zealously downloading in anticipation of all possible user flows comes at the expense of lag, battery-drain, and caching of assets that will probably go unutilized. The PS Tool identified the specific items that should be preloaded for both app start and product selection and put tangible time measurements to weigh the cost of leaving them unloaded.
Conclusion
The PS Tool uncovered numerous insights over the course of Popshop Live’s first 30 days. One of the most dramatic recommended improvements to app start time was made possible by identifying repeated API requests and artificial limitations on simultaneous HTTP requests by the networking client that the customer leveraged. The tool also provided recommendations to improve other flows, like search and product open.
Making adjustments to the customer’s code based on these recommendations would reduce app start time by over two seconds (39% faster!) and open product time by 1.65 seconds.
Moreover, using Product Science’s tool saved the customer ~794 hours of labor compared to manual diagnostics by dedicated performance engineers. Based on the average salary of a performance engineer, this equates to savings of over $40,000 USD.
To learn more about how Product Science can save your mobile business time and money with our self-service performance management tool, please reach out at hello@productscience.ai.
