How Native Image Snapshots Eliminate White Screens and Enable Instant Interaction in Mini‑Programs

Problem: White Screen in Mini‑Program Startup

During container loading and asynchronous rendering, mini‑programs often show a white screen or loading page; if the first‑screen delay exceeds 3 seconds, more than half of users abandon the page.

Existing HTML Snapshot Approach

Alipay and Taobao cache the homepage HTML and render it together with data on the next launch, reducing white‑screen time but still leaving a non‑interactive snapshot that must wait for JavaScript to become ready.

New Native Image Snapshot Technique

A fully native image‑level snapshot captures the homepage as a bitmap, displays it instantly on the next start, and becomes interactive once the real page is ready.

Step 1: After the mini‑program starts, capture the homepage as an image (snapshot).

Step 2: On the next launch, show the saved snapshot before starting the mini‑program.

Step 3: When the program is ready, hide the snapshot, display the real homepage, and save a new snapshot for the next launch.

Effectiveness

In DingTalk’s new schedule page, the snapshot reduced first‑screen rendering from about 1700 ms to under 300 ms, achieving a perceived “instant” load.

Suitable Scenarios and Timing

Snapshots work best when the first screen is relatively fixed and contains no user‑privacy data. Timing options include capturing in onReady with a delay, after remote data is fetched, or before any user interaction.

Fixed UI on first screen.

No personal or sensitive data in the snapshot.

Hiding the Snapshot

The snapshot is hidden at the moment of generation, usually with a 200 ms fade‑out animation to avoid visual flicker.

Interactive Snapshot

When the user clicks the snapshot, the click event is temporarily stored and dispatched to the real page after the snapshot is hidden, ensuring seamless interaction.

[{ "area": { "left":100, "top":100, "width":100, "height":100 }, "action": { "type":"openLink", "params":{ "url":"http://xxx" } } }]

Storage and Security

Snapshots are sensitive data and are stored only locally with encryption (using the enterprise wireless‑guard method). They must not contain user‑privacy data, and a cleanup strategy is required when storage limits are reached, the app updates, or the user logs out.

Accuracy Measurement

Perceptual hash (pHash) is used to compare the current snapshot with the previous one, producing a difference index; a lower index indicates higher similarity. Experiments show a difference index of 1 for minor character changes and 6 for overall layout shifts.

Handling Incorrect Snapshots

When a snapshot’s accuracy is poor, the DOM tree of the snapshot (with sensitive data removed) is compared to the real page’s DOM to locate differences and improve timing.

Partial and Multi‑Screen Snapshots

For pages with both stable and dynamic sections, only the stable part is snapshot (partial snapshot). When the homepage is scrollable, an over‑screen snapshot can be used, with scroll offset recorded to keep the real page aligned.

Performance

Typical snapshot size is ~110 KB, memory usage under 2 MB, and overall page load time around 280 ms. Extreme snapshots (5.2 MB) increase memory to ~3.2 MB and cause a brief delay, but normal usage remains smooth.

Conclusion

The native image‑snapshot technique provides instant, interactive first‑screen rendering for mini‑programs, eliminating white screens and loading delays. It is a pure native solution that can be extended to other asynchronous rendering scenarios, though it requires careful selection of suitable pages, timing, and security handling.