Skip to content

Mini Program Performance Issue Analysis

This article describes the page performance fields collected by @cloudcare/rum-miniapp version 2.2.18 and above, and how to identify white-screen candidate issues such as slow initial rendering and unrendered pages before exit. All duration fields are reported to Guance and normalized to nanoseconds (ns).

Collection Scope

The SDK can collect the following performance signals:

  • Page load, onReady, first render, FP, FCP, and LCP;
  • Whether onReady or the platform's first render signal has been triggered before page exit;
  • setData count, cumulative duration, maximum duration, queuing duration, update duration, and merge count;
  • Launch attempt, native launch, script execution, and package download;
  • Resource and Error data associated with slow pages.

The SDK does not collect screenshots, nor can it determine whether the core content after the business skeleton screen is usable. Therefore, the absence of any performance field cannot directly equate to a white screen.

Platform Performance Data

The SDK prioritizes the Performance API provided by the mini program platform. After the Observer subscribes successfully, performance_supported=true; when the platform also provides a usable first render signal, first_render_supported=true.

WeChat Mini Program

WeChat format entries are directly mapped to the following metrics:

Performance entry RUM field
navigation.duration loading_time
render:firstRender.duration first_render_time
render:firstPaint.startTime - navigationStart page_fp
render:firstContentfulPaint.startTime - navigationStart page_fcp
render:largestContentfulPaint.startTime - navigationStart page_lcp

Both cold-start appLaunch and normal route navigation can establish the identity of the first screen page. The SDK selects the current page instance by route, pageId, and the latest navigationStart; paints arriving before navigation are temporarily cached to avoid misinterpreting the absolute startTime of the entry as a duration.

Douyin Mini Program

Douyin uses paint, evaluate, navigation, resource, and launch entries. The SDK first converts them to a unified format:

Douyin entry Unified format
paint:first-paint page_fp, first_render_time
paint:first-contentful-paint page_fcp
paint:largest-contentful-paint page_lcp
evaluate:app-service action_type=script_insert
resource:miniprogram-package action_type=package_download

Douyin does not have the WeChat firstRender entry, so the SDK uses the current page's first-paint - navigationStart as the first render signal for this platform. This metric is not equivalent to FCP or the availability of business content.

View Performance Fields

Capability and Lifecycle Attributes

Field Type Description
performance_supported boolean Whether the Performance Observer was successfully subscribed on the current platform
first_render_supported boolean Whether the current platform provides a first render signal usable by the SDK
view_start_reason string page_load, page_show, or session_renewal
view_end_reason string onHide, onUnload, or session_renewal
ready_reached boolean Whether the current page lifecycle has reached onReady
first_render_reached boolean Whether the current page has received the platform's first render signal
ended_before_ready boolean Whether a page_load View ended before reaching onReady
ended_before_render boolean When first render signal is supported, whether a page_load View ended before the first render
view_is_active boolean Whether the View is still active

ended_before_render is only statistically meaningful when first_render_supported=true. Session renewal only splits the RUM View and does not represent a page reload, so it does not generate a conclusion of premature page exit.

Rendering Duration

Field Description
loading_time Maximum load duration observed from page navigation and lifecycle
page_ready_time Duration from View start to onReady
first_render_time WeChat: firstRender.duration; Douyin: first-paint - navigationStart
page_fp Duration of FP relative to the current page's navigationStart
page_fcp Duration of FCP relative to the current page's navigationStart
page_lcp Duration of the most recent LCP relative to the current page's navigationStart
first_render_data_transfer_time First render initialization data receive time minus send time
first_render_wait_time Waiting time from data reception completion to the start of view layer rendering
first_render_view_layer_time Time taken for the first render of the view layer

first_paint_time and first_render_time are compatibility fields, both representing the first render signal selected by the SDK; use page_fp when analyzing the actual FP.

setData Duration

Field Description
view_setdata_count Number of valid setData update samples
view_setdata_duration Cumulative duration of all valid updates
view_setdata_max_duration Maximum duration of a single update
view_setdata_pending_duration Cumulative waiting time from entering the queue to the start of update
view_setdata_update_duration Cumulative execution time from the start of update to the end
view_setdata_merged_count Number of updates merged by the platform

The SDK records the page to which the listener belongs at the time of installation. Delayed callbacks from hidden pages or old components are not counted toward the current View; listeners are stopped after the page is unloaded or the component is detached.

Launch Stage Metrics

The launch stage is reported as action data:

action_type Description
launch_attempt First App.onLaunch arrival, once per SDK instance; duration is not written, and app_launch_attempt=true is used as a valid field
launch Platform appLaunch navigation duration
script_insert Script execution duration
package_download Mini program code package download duration

The last three items depend on the platform's Performance entry. It is recommended to use the launch / launch_attempt ratio to observe the coverage of native launch metrics, and not to treat missing entries as zero duration.

White Screen Candidate Statistics

It is recommended to break down white screen analysis into three categories: coverage, slow rendering, and premature exit.

Statistical Sample

First filter:

view_start_reason = page_load
performance_supported = true
first_render_supported = true

Platforms that do not support the first render signal should have their coverage calculated separately and should not be included in the denominator of ended_before_render.

Issue Recommended Condition Description
Slow first render first_render_time > business threshold Suitable for calculating P75, P95, and the proportion exceeding the threshold
No first render before exit ended_before_render=true High-confidence white screen candidate, but can also be triggered by users quickly returning
Long time not ready page_ready_time > threshold Reflects page lifecycle or initialization blocking, not equivalent to visual white screen
Not ready before exit ended_before_ready=true Needs to be combined with view_end_reason and dwell time to exclude quick exits
Slow FCP/LCP page_fcp or page_lcp > threshold Closer to the time of content appearance and main content stabilization

The recommended dashboard should include at least:

  1. Performance and first render signal coverage;
  2. P50, P75, P95 of FP, FCP, LCP, firstRender;
  3. Proportion of ended_before_render and ended_before_ready;
  4. Error, failed Resource, 5xx, and TTFB distribution for slow Views;
  5. Trends broken down by app version, platform, OS, and device model.

Known Limitations

  • The SDK does not have a business markViewReady() API and cannot confirm that core business content is available;
  • Fatal errors occurring before the page onLoad may not have a View Context;
  • Long Tasks, FPS, page freezing, and screenshots are not currently collected;
  • Platform Performance API, base library, and OS version differences can affect field coverage;
  • Data sending failures without retry or local persistence may underestimate the problem ratio in weak network environments.

Official References

Feedback

Is this page helpful?