UniApp Mini Program JavaScript SDK Performance Issue Analysis¶
This document describes the page performance fields collected by @cloudcare/rum-uniapp version 2.2.21 and above, and how to use them to identify candidate white screen issues such as slow first render and pages that exit before rendering.
This document applies to the UniApp Mini Program JavaScript SDK, not to the
GCUniPlugin-*native modules. All duration fields are reported to Guance in nanoseconds (ns).
Collection Scope¶
The SDK can collect the following performance signals:
- Page load,
onReady, first render, FP, FCP, and LCP; - Whether
onReadyor the platform's first render signal has been triggered before the page exits; setDatacount, cumulative duration, maximum duration, queuing duration, update duration, and merge count;- Launch attempt, native launch, script execution, and code package download;
- Resource and Error data associated with slow pages.
The SDK does not capture screenshots, nor can it determine whether core content beneath a business skeleton screen is available. Therefore, the absence of any performance field does not directly indicate a white screen.
Platform Performance Data¶
The SDK prefers to use the Performance API provided by the Mini Program platform. When the Observer is successfully subscribed, performance_supported=true; when the platform also provides a usable first render signal, first_render_supported=true.
WeChat and Compatible Platforms¶
Entries in WeChat format 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 based on route, pageId, and the latest navigationStart; paint entries arriving before navigation are temporarily stored 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 metric:
| Douyin entry | Unified metric |
|---|---|
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 a WeChat firstRender entry, so the SDK uses first-paint - navigationStart of the current page as the first render signal for this platform. This metric is not equivalent to FCP or business content availability.
View Performance Fields¶
Capability and Lifecycle Attributes¶
| Field | Type | Description |
|---|---|---|
performance_supported |
boolean | Whether the Performance Observer subscription succeeded on the current platform |
first_render_supported |
boolean | Whether there is a first render signal available to the SDK on the current platform |
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 page lifecycle has reached onReady |
first_render_reached |
boolean | Whether the page has received the platform's first render signal |
ended_before_ready |
boolean | Whether the page_load View ended before reaching onReady |
ended_before_render |
boolean | When the first render signal is supported, whether the 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; for 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 |
Data receiving time minus sending time for first render initialization data |
first_render_wait_time |
Waiting time from data reception completion to start of view layer rendering |
first_render_view_layer_time |
First render duration 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 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 duration from queue entry to update start |
view_setdata_update_duration |
Cumulative execution duration from update start to end |
view_setdata_merged_count |
Number of updates merged by the platform |
The SDK records the page to which the listener belongs at installation time. Delayed callbacks from hidden pages or old components are not counted in the current View; monitoring stops after page unload or component detachment.
Launch Phase Metrics¶
The launch phase is reported as action data:
action_type |
Description |
|---|---|
launch_attempt |
First App.onLaunch arrival, one per SDK instance; no duration, with app_launch_attempt=true 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 depend on platform Performance entries. It is recommended to use the launch / launch_attempt ratio to observe the coverage of native launch metrics; do not treat missing entries as zero duration.
White Screen Candidate Statistics¶
It is recommended to split white screen analysis into three categories: coverage, slow rendering, and premature exit.
Sample Selection¶
First filter:
Platforms that do not support the first render signal should have their coverage counted separately and should not be included in the denominator of ended_before_render.
Recommended Metrics¶
| Issue | Recommended Condition | Description |
|---|---|---|
| Slow first render | first_render_time exceeds business threshold |
Suitable for P75, P95, and threshold exceedance ratio |
| Exit before first render | ended_before_render=true |
High-confidence white screen candidate, but user-initiated quick return can also trigger it |
| Long time not ready | page_ready_time exceeds threshold |
Reflects page lifecycle or initialization blocking, not equivalent to visual white screen |
| Exit before ready | ended_before_ready=true |
Needs to be combined with view_end_reason and dwell time to exclude quick departures |
| Slow FCP/LCP | page_fcp or page_lcp exceeds threshold |
Closer to content appearance and main content stable time |
A recommended dashboard should include at least:
- Coverage of Performance and first render signals;
- P50, P75, P95 of FP, FCP, LCP, firstRender;
- Proportion of
ended_before_renderandended_before_ready; - Distribution of Error, failed Resource,
5xx, and TTFB for slow Views; - Trends broken down by app version, platform, OS, and device model.
Known Limitations¶
- The SDK does not have a
markViewReady()API for business use and cannot confirm that core business content is available; - Fatal errors occurring before Page
onLoadmay not have a View Context; - Currently, Long Tasks, FPS, page freeze, and screenshots are not collected;
- Platform Performance API, base library, and system version differences can affect field coverage;
- When data transmission failure has no retry or local persistence, weak network environments may underestimate the problem ratio.