> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# WeChat Mini Program

> Learn about the Flashduty WeChat Mini Program RUM Insights dashboard core features for mini program performance monitoring, setData tuning, and launch time analysis

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.

<Info>
  The Insights dashboard includes 2 core analysis dimensions: **Overview** and **Performance Analysis**
</Info>

## 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   |

<Tip>
  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.
</Tip>

#### 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.

<Info>
  **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.
</Info>

## FAQ

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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

    <Tip>
      **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
    </Tip>
  </Accordion>

  <Accordion title="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 |

    <Tip>
      **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
    </Tip>
  </Accordion>

  <Accordion title="How can I reduce Mini Program launch time?">
    <Steps>
      <Step title="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.
      </Step>

      <Step title="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.
      </Step>

      <Step title="Defer non-critical initialization">
        Defer third-party SDK initialization, analytics reporting, and remote config fetching until after the first render.
      </Step>

      <Step title="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
      </Step>

      <Step title="Watch for version regressions">
        Switch the trend mode to **By Version** to compare launch time across releases and catch regressions early.
      </Step>
    </Steps>
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="What is the data ingestion delay?">
    <Info>
      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.
    </Info>
  </Accordion>
</AccordionGroup>

## Further Reading

<CardGroup cols={2}>
  <Card title="WeChat Mini Program SDK Integration" icon="rocket" href="/en/rum/sdk/wechat-miniprogram/sdk-integration">
    Learn how to integrate the RUM SDK into your WeChat Mini Program
  </Card>

  <Card title="WeChat Mini Program Data Collection" icon="database" href="/en/rum/sdk/wechat-miniprogram/data-collection">
    Learn which event types and view fields the SDK collects automatically
  </Card>

  <Card title="WeChat Mini Program Advanced Configuration" icon="sliders" href="/en/rum/sdk/wechat-miniprogram/advanced-config">
    Configure proxying, distributed tracing, sampling, and manual reporting
  </Card>

  <Card title="WeChat Mini Program Compatibility" icon="shield-check" href="/en/rum/sdk/wechat-miniprogram/compatible">
    Review supported base library versions and required platform APIs
  </Card>
</CardGroup>