iOS Performance Optimization Series 05｜Effective practices for iOS startup optimization

Startup optimization is a topic that can easily be turned into a “collection of bits and pieces”.

People usually remember many experiences:

• Do less initialization
• Lazy loading
• Make the first screen simple
• Don’t make too many requests at startup

Of course, these suggestions are all correct, but if the core judgment is not grasped, it often ends up becoming “We seem to have changed a lot of things, but the startup is still not significantly faster.”

The real key to startup optimization is a very simple question:

Which tasks really belong to the critical path that must be completed before the user sees the first screen, and which tasks are just conveniently squeezed into the startup phase because of convenience?

1. The root cause of slow startup is usually that the critical path is getting fatter.

Many projects are not slow to start initially. The real slowdown is usually because as the functionality increases, more and more logic is crammed into “do it as soon as the app starts” by default:

• Configuration initialization
• Buried point initialization
• Network environment preparation
• User status restoration
• Home page request
• Local cache reading
• Various SDK registrations

Everything seems reasonable on its own, but the problem is that when they are stacked together into the startup phase, the critical path becomes increasingly heavy.

So the most common real problems with startup optimization are: **The work that should not have been squeezed into this moment has been piled up at this moment for a long time. **

2. First distinguish between cold start, hot start and the “available time” that users truly perceive.

If this layer is not clearly distinguished, subsequent optimization will easily be biased.

Because the “slow startup” mentioned by users may refer to different things:

• There is no screen for a long time after clicking the icon
• The home page comes out, but it is not operational yet.
• The homepage frame came out first, and it took a long time to complete the content.

These actually correspond to different stages of slowness.

From an engineering point of view, at least we should distinguish:

• Cold start: process from scratch
• Warm start: the process has been resumed in memory
• The moment when the user is truly available: the point in time when the user can see and start interacting

To start optimization, you need to know exactly where you are losing time.

3. The most worthwhile first step is to layer the work in the startup phase.

I usually divide the work in the startup phase into three categories:

1. Must be completed before the first screen

For example:

• The most basic interface skeleton
• Core dependency initialization
• Key user status that must be known immediately after startup

2. Completed as soon as possible after the first screen appears

For example:

• Secondary data prefetching
• Some configuration refreshes
• Non-critical UI supplementary content

3. It can be delayed or backgrounded

For example:

• Preparation for certain burial points
• Does not affect cache cleaning of the current page
• Secondary page resource warm-up

This step is more valuable than any one-point trick because it leads directly to seeing: It turns out that a lot of the slowness is because “we shouldn’t be doing it now.”

4. The reason why many startup optimizations have no benefits is that they only write local code faster but do not change the critical path.

This is a very common misunderstanding.

For example, optimizing a certain initialization period from 40ms to 10ms sounds good. But if this initialization should not appear on the critical path, then the most effective optimization may be “don’t do it here at all.”

So to judge whether a startup optimization is worth doing, what I most often look at is:

• Is it work on the critical path?
• Can it be moved out of the critical path?
• Is it something that users must currently rely on?

This is more important than simply watching the function take time.

5. Home page content loading often slows down the startup experience

Many apps seem to start slowly, not necessarily because the process is really slow, but because the available content on the first screen appears too late.

For example:

• The homepage skeleton has been rendered
• But you have to wait for multiple requests to come back before it is like “really available”
• Some modules wait for each other
• The local cache is not loaded first

The slowness experienced by users at this time is actually closer to a “first-screen content strategy issue” rather than just a startup technical issue.

Therefore, startup optimization is often bound to the first screen strategy:

• Which modules must appear simultaneously
• Which modules can be used as skeleton screens?
• Which content can display cached results first?

Many so-called slow startups are actually caused by unreasonable organization of the content on the first screen.

6. A judgment closer to actual combat: what is currently slow is “initialization” or “first screen assembly”

The two often get mixed up.

Slow initialization

The question is more biased:

-SDK

• Global services
• Configuration reading
• Dependency injection

First screen assembly is slow

The question is more biased:

• The home page module is too heavy
• Doing too much work as soon as the page appears
• The first screen data dependency chain is too long

The optimization in these two directions is completely different. The former requires dismantling initialization and delayed execution, while the latter requires re-examining the page structure and content strategy.

7. Conclusion: The premise for starting optimization to be truly profitable is to first draw the critical path.

To put it in shorter form, I would say:

Startup optimization is really profitable. On the surface, it seems that there are many skills. In fact, it is closer to distinguishing first: which tasks belong to the critical path that must be completed before the first screen, and which ones are just burdens that have been conveniently inserted into the startup phase for a long time.

Once the critical path is unclear, optimization can easily turn into partial diligence. Once the critical path is clear, many optimization directions will be very clear.