weapp-vite-wevu-performance-best-practices

Purpose

weapp-vite + wevu

setData

Trigger Signals

• Users report page lag, scroll frame drops, and interaction delays.
• Users report slow page switching, slow first screen load, and occasional white screens.
• Users mention frequent

  setData

  calls, large payloads, and debug log alerts.
• Users mention that images cause lag/memory increase.
• Users mention iOS memory alerts, process recycling by the system, and crashes.
• Users request "a set of performance optimization solutions/Checklist/baseline and regression mechanism".

Scope Boundary

• It is mainly an engineering architecture/subpackage/build orchestration issue. Use

  weapp-vite-best-practices

  .
• It is mainly a

  .vue

  macro and template compatibility issue. Use

  weapp-vite-vue-sfc-best-practices

  .
• It is mainly lifecycle/store/event semantic refactoring. Use

  wevu-best-practices

  .
• It is mainly a migration solution from native to wevu. Use

  native-to-weapp-vite-wevu-migration

  .

Quick Start

1. Establish a baseline: clarify whether the bottleneck is

   setData

   , rendering, switching, resources, or memory.
2. Enable low-risk optimizations first:

   weapp.wevu.preset: 'performance'

   + enable

   autoSetDataPick

   for pages.
3. Converge item by item according to five types of scenarios:

   setData -> rendering -> switching -> resources -> memory

   .
4. Only change one type of variable at a time, and attach the minimum verification command and regression signal.

Execution Protocol

1. Baseline first

• Collect key link data: page switching time, first screen rendering time, scroll duration link, timing of memory alerts.
• Distinguish between "occasional jitter" and "stable reproduction" scenarios, prioritize reproducing stable issues.

1. setData path (highest priority)

• First enable/confirm

  setData

  strategies:

  patch

  ,

  suspendWhenHidden

  ,

  highFrequencyWarning

  .
• Use

  autoSetDataPick

  to reduce unused template fields from entering the snapshot.
• Avoid direct high-frequency

  setData

  in high-frequency callbacks (especially

  onPageScroll

  ).

1. Render path

• Do not listen to

  onPageScroll

  unless necessary.
• Prioritize using

  useIntersectionObserver()

  for element exposure and visibility logic.
• Prioritize CSS / platform animations for animations, do not use continuous

  setData

  to drive full-page animations.

1. Navigation path

• Control the time-consuming logic of the previous page's

  onHide/onUnload

  , postpone execution if necessary.
• Request data in advance for the "window period before jumping to onLoad" of subpackage pages.
• Combine subpackages and

  lazyCodeLoading

  to reduce injection and blocking during switching.

1. Resource + Memory path

• Provide images according to the display size, avoid large images and unrestrained

  widthFix/heightFix

  .
• Release caches, listeners, timers and long-lifecycle objects in the

  onMemoryWarning()

  callback.
• Ensure the closed loop of side effect cleanup (listeners, timers, long task callbacks) when pages/components are unmounted.

1. Verify narrowly

• Provide "expected benefit + observable signal + rollback switch" for each round of changes.
• Prioritize running targeted verification before deciding whether to expand the verification scope.

Guardrails

• Do not modify "build strategy + runtime strategy + business logic" at the same time.
• Do not only look at the average value, observe at least the slow links (P95/P99) or worst frame performance.
• Do not take "alert disappearance" as the only basis for "performance has reached the standard".
• Do not carry out large-scale refactoring without establishing a baseline.

Output Contract

• Performance problem classification (setData/render/nav/resource/memory).
• File-level minimum change suggestions (by priority).
• Corresponding verification commands and acceptance signals.
• Risks, rollback points and subsequent observation items.

Completion Checklist

• There is a clear baseline comparison before and after optimization.

• setData

  high-frequency paths have been converged (frequency/range/payload).
• Scroll and exposure logic does not rely on high-frequency

  onPageScroll + setData

  polling.
• There is no obvious

  onHide/onUnload

  blocking in the page switching link.
• The resource policy has constraints on image size and layout jitter.
• Memory alert and unmount cleanup mechanisms have covered key pages.

References

• references/runtime-perf-matrix.md

• references/tuning-recipes.md