How We Boosted Taro Mini‑Program Performance for Double‑11: Practical Optimizations

Performance Before Optimization

We measured page load time and smoothness using key timing points such as tab click, sub‑package entry, location API start/end, CMS request start/end, rendering phases, and total duration.

Cold start (first load) and hot start (after exiting WeChat) timings were recorded manually with a stopwatch, revealing slow sub‑package loading, long API response times, and heavy feeds rendering.

Problem Analysis

Slow sub‑package loading increased first‑screen time.

API request latency was excessive.

Feeds rendering took too long.

Optimization Practices

1. Switch to Skyline Rendering Engine

Skyline, provided by WeChat, offers a lightweight rendering pipeline and a dedicated rendering thread, reducing UI blocking, memory usage, and JS‑Bridge communication overhead while maintaining compatibility with the existing architecture.

During adaptation we encountered issues such as:

BackgroundPosition cannot use

calc()

; use

`center bottom -${gradientHeight}px`

instead.

position: sticky

is unsupported; replace with a custom

StickyHeader

component.

Absolute positioned child nodes require a relative parent.

Full‑corner radius may fail when setting a single border‑top‑color.

position: fixed

does not work; use

position: absolute

with relative containers.

z-index

only works within the same stacking context; consider a root‑portal component for cross‑level layering.

2. Resource Lazy Loading

Feeds layers contain many product items (15‑20 per layer). Previously all items were rendered at once, causing heavy rendering load. We limited initial rendering to six items and lazy‑loaded the rest on scroll.

<code>&lt;ScrollView ... onScrollToLower={handleScrolltolower} /&gt;</code>
<code>const handleScrolltolower = useCallback(e => { if (!loadMoreImg.current) { loadMoreImg.current = true; /* load remaining images */ } }, [loadMoreImg]);</code>

Similar lazy loading was applied to product resources in the feeds.

3. Cross‑Team Collaboration

We coordinated with product and UED teams to reduce the number of initial feed layers from 13 to 9, further decreasing rendering pressure.

4. Image Resource Optimization

Large image sizes caused slow downloads and white‑screen placeholders. We introduced a three‑size image scheme (large, medium, small) and configured the backend to deliver small images for feed and shop‑related layers, significantly cutting download time.

5. API Request Refactoring

The page originally made serial requests to the main and feeds APIs. We refactored them to run in parallel and rendered results in batches, reducing overall request latency.

Optimization Results

After applying the above changes, both total API request time and feeds rendering improved markedly, leading to a noticeable reduction in first‑screen load time.

Stopwatch measurements also confirmed a faster overall startup.

Conclusion

Performance optimization of Taro mini‑programs involves front‑end code improvements, inter‑team communication, and disciplined coding practices. Continuous, incremental enhancements are essential for delivering a smooth user experience during major promotions.