Hello. This is the Wadiz Team.
TheWadiz tech organization often forms teams to collaborate on specific projects. In this post, we'll share how the App Development Team and FE Development Team joined forces as the Client Development Team to improve the Wadiz 's detail page loading speed by approximately 38% on Android and 66% on iOS.
Then let's start by looking at the difference in loading speed before and after the improvement!
Loading speeds may vary depending on your device and network environment.
Background of Introduction
The Client Development Team collaborated with the App Development Team and Front-End Development Team to explore potential improvements. Since the detail page is the most frequently navigated page, we set the goal of improving its loading speed.
Previously, the Wadiz website had improved the speed of entering detail pages by adopting the SPA approach.
Here, SPA stands for Single Page Application, which loads the entire page once initially and then changes the screen by binding data via Ajax thereafter.
The app was creating a new webview and loading the URL each time a user entered a detail page, resulting in the entire page being reloaded every time. This prevented us from applying improvements made on the web. We hypothesized that if the detail page's webview in the app could operate using the SPA approach, we could improve loading speed.
How did they improve it?
On the existing app's detail page, the webview would disappear whenever the page closed—for example, when the user pressed the close or back button. This made it difficult to implement the SPA approach. To solve this problem, we explored ways to keep the webview active even after the detail page disappeared.
As a result, we designed it to maintain the web view separately as shown in the image below, allowing it to be displayed on the screen whenever needed. We validated this through a Proof of Concept (PoC).
Detailed Development Plan
When displayed on the screen
- When the app first launches, it pre-creates a reusable webview and loads a preparation page to enable SPA transitions.
- When the user enters the detail page, a new screen is displayed, and a pre-generated webview is embedded into the screen.
- When you request a web application to switch to a SPA, it loads data from the web and then displays it on the screen.
When the screen closes
- Detach the webview that was attached to the screen.
- Releases other event listeners and objects from memory besides the WebView.
Every time you enter a detail page, this process occurs, enabling us to provide a better user experience with faster loading times.
What about the callbacks previously provided in the webview?
When the page loads, Android's onPageStarted, iOS's webView(_:didCommit:)When this is called and loaded, Android's onPageFinished, iOS's webView(_:didFinish:It's being called.
However, when the page changes due to the SPA transition, the WebView-related methods mentioned above are not called. Consequently, the tasks previously handled cannot be performed.
In response, we decided to handle it as a communication interface between the web and the app.
Wadiz Web → App Event Definition
- accepted: An event that notifies the web application that it can handle an SPA request from the app using the SPA method.
- loaded: When all data on the detail page has been loaded
- rendered: When the screen is rendered on the detail page
- failed: When loading fails
What concerns did you have regarding the changed approach?
The new approach isn't all advantages. We had many concerns when adopting the changed method because unexpected side effects could arise. To prepare for this, we prepared several questions and countermeasures.
What issues arise when a webview is pre-generated?
Pre-generated web views can cause issues. For example, when a new web page is updated, changes may not be applied to the web view, and login sessions may expire. To avoid these problems, we configured the web view to reload the URL every 30 minutes instead of switching to an SPA. This ensures that whenever a new request comes in, it always maintains the latest state.
What if the web or app isn't receiving events?
When pages transition via the SPA method, events received from the web are crucial because webview callbacks cannot be received. Rather than waiting in a situation where both the web and app fail to receive events, we determined that reloading the page is the best approach. We have prepared two countermeasures.
First, we wait for the accepted event to confirm that the web environment can handle the SPA transition. If the accepted event does not arrive within 0.2 seconds, it is determined to be an unsupported environment, and the page is reloaded.
Second, check the response value for the SPA request. If the response value for the SPA request is true, it's a normal situation, and the screen transitions using the SPA method. However, if it's false or null, it's determined that the screen cannot transition using the SPA method. In this case, the page is reloaded.
Memory leak
During the development and testing of an Android app, a memory leak occurred when a reused WebView was connected to a Fragment. Memory leaks can cause the app's memory usage to continuously increase, potentially impacting overall performance.
To resolve this, we completely separated the WebView and Fragment when the detail page closes. onDestroyView, onDetach I removed the event listeners for the WebView, as well as the WebViewClient and WebChromeClient.
override fun onDestroyView() {
super.onDestroyView()
webView?.setOnKeyListener(null)
webView?.webChromeClient = null
webView?.webViewClient = WebViewClient()
}
override fun onDetach() {
super.onDetach()
webView = null
}
After fixing the memory leak, we confirmed that it operates normally.
Handling Outages Using RemoteConfig and A/B Testing
Since the page we wanted to improve was the most frequently accessed detail page, handling outages was critical. To prepare for potential disruptions, we considered two approaches.
This approach allowed us to improve the user experience while also proactively addressing system failures.
Improvement Monitoring
We added a new attribute using Firebase Performance to monitor the improved loading speed.
We were able to identify improvement areas by categorizing cases into success, failure, and unsupported scenarios, observing trends within users' environments. During monitoring, we confirmed that the conversion rate to SPA reached approximately 60%. This indicates that users are experiencing faster and more efficient navigation between pages.
As shown in the graph below, we could confirm that the loading speed improved after the enhancement.
In closing
This project presented some challenges due to its hybrid nature. It required significant communication between web and app teams, such as tracing root causes when issues arose. I want to express my gratitude to the FE development team and QA team for their consistently positive and enthusiastic collaboration. It was because we worked together that we could wrap up the project with a sense of accomplishment.
Moving forward, the Client Development Team will collaborate with various teams to advance the Wadiz service and provide users with an even better experience. We look forward to discovering new ideas and innovations as we grow together.
Still have questions? 👀
Curious about how the FE Development Team improved web detail page speed using the SPA approach? 👉 Click
App Development Team's Compose Multiplatform Adoption Story 👉 Click
