How Google made their Android app start faster

Added: 2026-05-13

[00:00:00]Hi everyone. I'm here to talk about a user centric redesign of Android Google apps initialization otherwise known as how we made our app startup faster. My name is Rifa Stralnikov and I am a software engineer on the Android Google apps performance team. I am hoping that this talk will help with reducing app startup latency for your apps. So it might be useful to first go through how our app starts and is used.

[00:00:26]Let's start by going through a typical user search journey. First, you click on the quick search box widget. Then start typing and select a suggestions result.

[00:00:38]You'll end up on the SER, otherwise known as the search results page. If you click on a link like that one there, you'll go to the web page. However, this isn't actually in Chrome, but in something called Chrome custom tabs.

[00:00:53]Since we'll be focusing on ending up on that SER, let's define a few terms. This is the activity fragment boxed in yellow. An Android activity takes care of creating a window in which we place our UI, the content from our app. And this takes up most of the screen. The part of the screen in the red box is a web fragment. This is a very important part of our app. This is where the search results are displayed. And now let's go through a short story. In late 2024, which is now over a year ago, we were looking into possible search latency improvements and we noticed that we were initializing this very important web fragment at the point at which we were submitting a search query and this sparked some concern. This seemed awfully late for initializing something so critical. And so I ran a study trying to move it into earlier points in the code path. And one was especially exciting looking. Our launch experiment showed that we'd be saving a very considerable amount on search latency with this change.

[00:01:59]However, we couldn't launch it. After a whole lot of time spent looking at various slices and trying and seeing if we could salvage any entry point, we came to the conclusion that we really couldn't. The startup interactive latency shot way up by five times the amount we'd saved on search latency. And just to clarify, this is how long it takes to go from clicking to start the app to when a user can actually start interacting with it. And in addition, there was a considerable uptick in sessions with ANRS. This is when the app freezes. As it turns out, by looking just at search latency as the metric to improve, we forgot something.

[00:02:44]We had moved that web fragment initialization from out of the search latency time right into a highly contested startup latency block of work.

[00:02:54]Oops.

[00:02:56]And so we learned one, we need to pay attention to both search and startup latency. Two, we cut a lot of search latency if we could somehow move the web fragment initialization earlier.

[00:03:13]Three, the Android Google apps initialization is a very long and complicated process, which begs the question, are there improvements we can make within that initialization stage?

[00:03:26]And if we could do that, can we use any freed processing capacity to do at least some of that web fragment initialization before we get to the query submission? A good place to start here would be with ironing out the startup flow in the quick searchbox critical user journey.

[00:03:43]This is the quick search box. The QSB critical user journey makes up roughly a third of AGA's visits. And here is a trace of a typical QSB startup and initial search from early 2025. As you can see, there are a lot of densely packed spans going on. And let's highlight when various steps are taking place. Here the activity begins as in our app starts in a window that pops up on the screen. Next, the Chrome custom tabs are pre-warmed. Wait, why? The CCT or Chrome custom tabs is what you're looking at when it looks like you're in Chrome after you click on a blue SER link. So, let's put the out of order boxes in red. Next, the suggestions are displayed. The secondary UI is drawn like the header and bottom navigation bar. Then the keyboard comes up. At this point, the search box is interactive.

[00:04:42]Next, we seem to have several seconds when nothing happens on the main / UI thread. And please note the giant red arrow. Next, we seem to have a locked web view initialization. And here is where the user starts interacting with the app via key press. And now here is where AGA initializes the web view instance. Huh, that seems awfully late, especially since web view is the component that renders the SER, the search results page, and handles all its events like the clicks, scrolls, navigation, etc., which we need before we could initialize our web fragment.

[00:05:21]Then it seems like the user picks one of the suggestions and clicks on it. After that, within the red box, we begin tracking our SER/arch latency where we still have our web fragment initialization and most of our web view initialization.

[00:05:37]Taking a second look without the trace distracting us, we can look at that several second gap as an area of opportunity.

[00:05:45]And here's a good analogy for our situation. The chef is preparing dessert, the secondary UI, while the customer is yet to receive their main course. That's the interactive UI to start typing and clicking. And while the chef guarantees rapid dessert service, that does not translate into customer satisfaction. A cold main course due to delays risks customer rejection. And this is a parallel to AJ's unfortunately high cancellation rate. And so we decided to tackle our nonoptimal flow.

[00:06:16]The first step was to prioritize the keyboard. It didn't seem reasonable to make a user wait for secondary UI to be drawn before giving them the keyboard.

[00:06:25]So, let's put it earlier and move it over for space. Now, there was a slight search latency regression and we hypothesized that this was mainly on zero prefix suggestions clicks. These were probably users who tapped on suggestions before web view was done initializing and we also hypothesize that no one was actually getting to the SER later. However, our other performance metrics were much improved.

[00:06:49]In particular, startup interactive latency was greatly reduced. Also, this keyboard launch greatly reduced quick cancellations for text searches, the zero prefix slice especially. Even more excitedly, this drove growth. This launch was actually the largest growth drive for at least the AGA latency team for the year and was the most significant growth for all of AGA in Q2.

[00:07:13]We also discovered that we were pre-warming Chrome custom tabs, the same Chrome custom tabs that aren't used until a user clicks on a link in the SER before suggestions were even displayed.

[00:07:24]Moving that to just before the secondary UI draws gave a small search latency improvement, but more importantly a considerable improvement in the time to interactive.

[00:07:35]Next, we figured out a way to start tackling the giant web fragment initialization. Thanks to the web view team, we were able to call both a web view startup and profile pre-warming. We realized that we could do this pre-warming once the suggestions and keyboard were available to the user. We had already been doing some pre-warming, but adding in the web view profile alleviated some of the work from within the later web fragment initialization.

[00:08:00]We saw a modest search latency reduction at this change as we had freed up some space after the user input by moving the pre-warm web view into the area of opportunity. We found that we could attach an independent web fragment. Not our particular instance, but it did a lot of the same initialization we needed once the user starts typing. This actually gave us a considerable win in search latency. Once we finished placing the startup and profile pre-warming, we found a place for the majority of the rest of that web fragment initialization. By pre-warming the web view instance right after the web view profile, we were able to cut off a lot of time from search latency. And outside of Google, you'd use the web view compat startup web view here. And so we came to our updated quick search box critical user journey by mid 2025. activity start suggestions displayed keyboard up at which point the search box is interactive and as you see no more gap instead we pre-warm web view profile web view instance CCT secondary UI draws then the user starts typing and we attach that independent web fragment the user clicks the suggestion and off we go into SER latency with a much smaller job of web fragment initialization as for next steps we have plenty more ideas as this approach of rearranging pieces of our initialization into their correct order has shown to have quite a bit of headroom. In short, our strategy of intentional initialization is delete things we don't actually need. You might be shocked at how much unused code dependency injection we've been initializing.

[00:09:44]We move blocks of code earlier or later depending on by when they're actually needed.

[00:09:50]optimize. Sometimes we're using slow methodology and sometimes we need to break up big initialization into smaller, more easily placeable chunks.

[00:10:00]And as blocks are made shorter or removed, we can leverage the newly found gaps as new homes for initialization chunk placement. And we all love recursion.

[00:10:11]And we can apply this concept to other flows such as home screen to suggest and notifications and even more keyboard initialization. As an example, our current iteration is working on the keyboard. Again, though considerable improvements have already been made to the keyboard startup latency, it's still been frustratingly slow, especially in comparison to Google Go's performance.

[00:10:34]And we have been looking into whether it's possible to make it faster. Looking at this trace, we can see where the activity starts, where the suggestions fragment is initialized, followed by the searchbox fragment. Then we get the window focus on the search box, then the suggestions are displayed, and then the keyboard finally comes up. There's a lot of work that goes on in other threads, but the call for the keyboard cannot go out until we have focus on the search box.

[00:11:03]So something we've been exploring is can we change up this order and delay the suggestions fragment initialization so that we could initialize the search box first.

[00:11:14]What you can see here is a trace from a prototype we've been working on. Here we explore initialization of the suggestions only once we get to focus on the search box and call the keyboard. In playing around with a polished version of this change, the keyboard feels like it comes up considerably faster. And so we've noticed quite a bit of improvement to the user experience. Hopefully our theory of applying intentional initialization here will bring a positive change to everyone soon. And so our main takeaways, intentional initialization, leverage great web view resources, handy link here, and apply it everywhere.

[00:11:55]For more Android conference talks, check out the documentation. And thank you.

[00:12:00][music]