Cutting our phone app's start time from 7 seconds to 3

In late September, opening the genvi app from scratch on an Android phone took about seven seconds before the home screen showed your name. Nothing was broken. The app was simply busy doing work that the first screen did not need. Three changes took the typical start time, the cold start, from 7.3 seconds down to 3.2. A cold start means the app was fully closed before you opened it.

A number only means something if you measure it the same way each time. We used the real release version of the app on Android phones. We opened it five times and took the middle result. We timed from the moment the app starts working to the moment the home screen shows your name.

The day before, we also added a way to see this for real use. The app now reports how long it takes to open and how long each main screen takes to show content. Our team has a report that shows typical times and the slowest cases. So this fix was for a number we could now watch.

The app used to load all of its code the moment it opened. That included the editors, the 3D tools, and the PDF and media tools. It took about 3.5 seconds, and during that time the app could not respond to a tap.

Now each piece of code loads the first time something needs it. For example, the 3D tools wait until you open them.

The app has five tabs along the bottom. Before, all five were set up when the app opened. Each one built its lists, asked for its data and prepared its header, even though you could only see one. On Android this kept the app busy for about 3 seconds, so your profile, your credits and every tap had to wait.

Now a tab stays empty until you open it for the first time. After that, it stays ready, so switching back is instant.

Two small details matter. The tab draws itself on the very first visit, with no blank flash. And the tabs you have already visited are not redrawn each time you switch, which would waste effort.

The app remembers your last information on the phone. Before, the home screen first appeared empty, with "Hi there", a question mark for your picture and no credits. Then it drew itself again once the saved information was ready. That first, wasted drawing kept the app busy for about a second and a half, and the saved information had to wait behind it.

Now the app keeps its opening screen up until your sign-in and saved information are ready. It waits at most 1.5 seconds, so a slow phone never gets stuck. The home screen then appears once, with your name and your credits already there.

These three changes follow one idea: when the app opens, it should only do the work that the first screen shows. Loading on demand moves work to the moment it is needed. Setting up tabs on first visit moves work to the first visit. And the short wait removes work that would be thrown away.

We did not change the editors for this. They cost something when you open them, but that is when you expect to wait.

Something similar helped on the website. In the image composer, dragging a layer used to redraw the page twice for each small mouse move. We fixed that. The average work for each move on a page with 64 layers dropped from 6 to 12 milliseconds to 3.9 milliseconds. That is a different number on a different device, so we keep it separate from the phone result.

An automatic test confirms that all three changes are still in the app. If someone removes one, the check tells them which reason they just lost.

A check like this cannot prove the app is fast. It proves the three decisions that made it fast are still there, which is what tends to wear away over time. The real speed shows up in our report, where any slowdown would be easy to see.