Optimizing Startup Performance

1. Overview

Improving minigame startup has significant value for retaining new users. To improve minigame startup speed, we first need to understand the minigame startup sequence.

2. Minigame Startup Sequence

The startup process is divided into two stages: code package loading and first-screen rendering. From the moment a player taps the game to when they see the game screen, a series of loading actions take place, including the preparation of the minigame framework itself and the developer's initial business logic.

3. Optimization Approaches

To optimize minigame startup performance, it is clear that we need to reduce the time spent on each step in the startup sequence. Next, we discuss the optimization techniques commonly used by developers.

1. Trim the Main Package Resources

Currently, the total size of all subpackages of a minigame is limited to no more than 30M, and the main package size is limited to no more than 4M. Trimming the main package is the most important means of minigame startup, because its size obviously affects the download duration and has the greatest impact on players during the first cold start. Therefore, we need to trim its contents:

• Reduce resource usage through resource compression and file merging (merging small files, texture atlases, etc.).
• Reduce unnecessary resources, typically keeping only the small amount of resources that the first screen depends on.

2. Use Subpackage Loading Sensibly

For projects with an excessive amount of code, subpackaging is required on the one hand due to the minigame package size limit, and on the other hand, sensible subpackaging is also very meaningful for startup. This is because it allows developers to reduce the content that needs to be downloaded at startup, whether ordinary resources or code.

3. Parallel Download Capability

For minigames that use the code subpackage capability, you can consider using network I/O during the startup process to download the subpackage resources required by the game in advance. This reduces the time users subsequently wait for subpackage resources to download and shortens the time it takes for users to reach the game's core gameplay.

4. Reduce the Resources Required for First-Screen Rendering

Developers should reduce the complexity of the first screen, including both the initial business code logic and resources. We have found that the reason many minigames start too slowly is that the initial resources are too complex. For example, if the initial screen's resources need to be fetched from a remote CDN, players with poor network conditions will experience obvious black-screen flickering, resulting in a very poor experience. Therefore, a common practice is to reduce the complexity of first-screen resources and place resources within the main package as much as possible.

5. Render as Early as Possible

Rendering as early as possible refers to shortening the time from the completion of business code injection to the first-screen rendering instruction. Therefore, in addition to the optimization techniques mentioned above, you can also:

• Reduce the initial code size to reduce code injection time
• Simplify first-screen logic, for example by performing lightweight rendering without relying on a third-party engine