WeChat Mini Program

Flashduty WeChat Mini Program RUM Insights dashboard provides out-of-the-box visualization dashboards that automatically collect and analyze multi-dimensional data including user sessions, launch time, page rendering, and setData calls. This helps you gain comprehensive insights into your Mini Program’s real-world performance, quickly identify performance bottlenecks and issues, and continuously optimize user experience.

The Insights dashboard includes 2 core analysis dimensions: Overview and Performance Analysis

Overview — Key Metrics at a Glance

The Overview tab focuses on the core multi-dimensional metrics of your Mini Program, helping you quickly assess overall health.

Traffic and Sessions

UV: Number of unique visitors after deduplication. Combined with the trend chart, this reveals user activity patterns.
Sessions: Total number of sessions in which the Mini Program was opened. Click the card to drill into the session list.
User Access Trend: Time-series chart showing UV and Session changes over time, helping you identify traffic peaks and unusual fluctuations.

Core Metrics

error_count: Monitors the total number of error events and their time-series trend, surfacing anomaly spikes early.
Session Error Rate: Percentage of sessions that contain at least one error, reflecting overall Mini Program stability.
appLaunchTime P75: The P75 percentile of total launch time (cold start + warm start combined). Launch time directly shapes the user’s first impression.
firstRender P75: The P75 percentile of the time from page load start to first render completion, reflecting “white screen” duration.
setDataCount (avg): Average number of setData calls per page view. A high call rate increases communication overhead between the JS thread and the render thread.
setDataDuration P75: The P75 percentile of a single setData call’s duration.

Session Analysis

Average Session Duration: Total session duration divided by session count, used to assess user stickiness and engagement depth. The accompanying time-series chart helps identify behavioral shifts among active users.

Performance Analysis — Full Control over Mini Program Experience

The Performance Analysis tab provides end-to-end monitoring of the core experience metrics: launch, page rendering, and setData.

Core Performance Metrics

Five key performance metric cards are displayed at the top. Click any card to switch the trend chart and sample distribution below to that metric:

Metric	Field	Description
App Launch Time P75	`app_launch`	P75 of Mini Program launch duration
First Render P75	`first_render`	P75 of time to first render completion
Loading Time P75	`loading_time`	P75 of full page-load duration
setData Count (avg)	`setdata_count`	Average `setData` calls per page view
setData Duration P75	`setdata_duration`	P75 of a single `setData` call duration

Each card displays a health-status badge (good / warning / poor) in the top-left corner, calculated against built-in thresholds.

Trend Analysis

The trend chart below supports a Trend Mode selector that breaks down the current metric by different dimensions:

Trend Mode	Description
Overall	No grouping; displays the overall time-series trend of the current metric
By Version	Groups by application version, comparing performance across releases
By Env	Groups by environment, comparing performance across environments
By Loading Type	Groups by `view_loading_type`, comparing cold start and warm start
By OS	Groups by `os_name`, identifying system-level compatibility differences

Switch to By Version during a gradual rollout to validate release quality. Switch to By Loading Type to observe cold-start (initial_load) and warm-start (route_change) durations independently.

Sample Distribution

The sample distribution bar chart shows the count of samples falling into each time bucket for the current metric, surfacing long-tail behavior. For example, when viewing App Launch Time, the distribution clearly shows how many users launch within 1s, 1-2s, more than 2s, and so on.

Per-Page Performance Detail

A per-page table breaks down performance metrics by view name, helping you identify pages with slow loading or excessive setData calls:

Column	Description
View Name	Mini Program page route path
Count	Total view events for this page; an embedded bar shows relative traffic
App Launch Time	P75 of launch time observed during sessions on this page
First Render	P75 of first-render time for this page
Loading Time	P75 of full page-load time
setData Count	Average number of `setData` calls on this page
setData Duration	P75 of single `setData` call duration on this page
onLoad → onShow	P75 of the time between `onLoad` and `onShow`
onShow → onReady	P75 of the time between `onShow` and `onReady`

Click any row to drill into the detailed analysis view for that page.

Loading Type Trends

Two charts at the bottom compare cold start (initial_load) and warm start (route_change):

Loading Type Count Trend: Time series of cold-start vs warm-start counts, revealing changes in traffic composition.
Loading Type Duration Trend: Time-series comparison of cold-start and warm-start durations. Cold start is typically significantly longer than warm start; an unusual change in the gap often indicates a change in the launch logic.

Cold start vs warm start

Cold start (initial_load): The user opens the Mini Program for the first time, or WeChat has reclaimed it and is re-launching it. The full runtime must initialize and the first page must load.
Warm start (route_change): The Mini Program is resumed from background after a brief period. The runtime is already initialized, so duration is significantly shorter.

FAQ

What is the difference between App Launch Time and First Render?

App Launch Time (app_launch): The total time from when the user taps the Mini Program icon or entry point to when App.onLaunch finishes. It includes runtime initialization, first-page code package download, and App.onLaunch execution.
First Render (first_render): The time from when a page begins loading to when it first completes rendering, reflecting the “white screen” duration.
A typical cold start ≈ App Launch Time + First Render of the home page. The two metrics measure launch experience from different angles.

What happens when setData is called too often?

setData is the primary API used by the logic layer to communicate with the render layer. Each call triggers cross-thread communication and diff computation. Common pitfalls:

High call frequency: Calling setData inside a loop or hot event path keeps the render thread busy
Oversized payload: A single setData carries too much data, making cross-thread serialization slow
Updating unrelated data: Passing the entire data object to setData instead of only the fields that actually changed

Optimization tips:

Coalesce multiple setData calls and pass a partial object
Use path expressions to update nested fields, e.g. this.setData({ 'list[0].name': value })
Avoid calling setData directly inside high-frequency events (scroll, input); throttle or debounce instead
Pay attention to pages with unusually high setData Count or setData Duration values in the per-page table — fix those first

What do P75, P50, and P90 mean?

Percentiles are an essential statistical measure of data distribution:

Percentile	Meaning
P50 (Median)	50% of users experience better than this value, 50% worse
P75	75% of users experience better than this value, 25% worse
P90	90% of users experience better than this value, 10% worse

Why use P75 instead of the average?

The average is easily skewed by outliers and may not reflect the typical user experience
P75 represents the experience of the majority of users and is the industry standard for performance evaluation

How can I reduce Mini Program launch time?

Analyze launch data

Focus on App Launch Time P75 and use the sample distribution to identify long-tail behavior. Switch the trend mode to By Loading Type to observe cold-start performance in isolation.

Slim down the code package

Reduce the size of the first package. Use subpackages and subpackage preload to avoid loading every page’s code at once.

Defer non-critical initialization

Defer third-party SDK initialization, analytics reporting, and remote config fetching until after the first render.

Optimize first-page rendering

Reduce the number of network requests required for the first screen; coalesce APIs
Use local cache or skeleton screens to avoid long white-screen periods
Keep the payload size of the first setData small

Watch for version regressions

Switch the trend mode to By Version to compare launch time across releases and catch regressions early.

What are onLoad → onShow and onShow → onReady useful for?

These metrics measure the duration between phases of the Mini Program page lifecycle and help pinpoint exactly where rendering is slow:

onLoad → onShow: Time from onLoad to onShow. Mostly reflects the cost of synchronous logic inside onLoad (parameter parsing, first-screen data preprocessing, and so on).
onShow → onReady: Time from onShow to onReady. Reflects the time required for the first render to complete, including template compilation and the first batch of setData.

If First Render is consistently slow, use these two segment metrics to decide whether it’s logic blocking inside onLoad or the rendering itself that needs optimization.

What is the data ingestion delay?

Flashduty RUM typically completes ingestion and visualization within 1-3 minutes after the data is generated. Under good network conditions, most data is available in near real time.