Halve Shopping Cart Load Time with Auto Paging, Scroll Fixes, and Caching

Preface

As a core flow of JD shopping mini‑program, the cart page contains many marketing features, making the node tree large and performance optimization challenging. After reaching the limit of pure technical optimization, we began business‑driven performance improvements.

Part 1: Minefield – Analyzing Performance Issues

Key Optimization Metrics

First‑screen time: time from page open to first‑screen content display.

Render time: time spent on first data render or structural changes.

Request latency: longer requests increase user wait.

CPU utilization: saturation can cause white‑screen or crashes.

Network request count: too many concurrent requests hit mini‑program limits.

Analysis Tools

1. Performance Monitor

Built‑in visual monitor in the mini‑program dev tools that records system resource usage at the OS level.

It helps track CPU and memory fluctuations, quickly locate modules causing jank or overheating, and guide optimizations.

2. Test Devices

Because mini‑program performance tools are limited and differ from real devices, we use low‑end phones such as Oppo R11 and iPhone 6s Plus for initial investigation, then verify on low, medium, and high‑end devices representing the user base.

3. Monitoring System

Frontend collects and reports speed data, which is analyzed by a monitoring system to assess page load health and provide valuable references for optimization.

Before launch, testing devices can verify optimizations, but they cannot reflect real user conditions. For a content‑rich page like the cart, monitoring is essential.

ps: All subsequent speed data comes from the monitoring system.

Analysis Process

1. Business Analysis of the Cart

High product information complexity – a single item may occupy a quarter to a full screen.

Complex grouping – besides store grouping, JD also groups by promotion activities.

2. Speed Data Analysis

Given the cart’s data complexity, we focused on the relationship between total product count and first‑screen render time:

First‑screen render time increases with product count; we suspect the paging granularity should be at the product level rather than promotion level.

When product count exceeds 10, render time rises sharply. Experiments show that with ≤5 items, first‑screen time is similar to an empty cart; beyond 5 items, time jumps to a higher tier.

Conclusion: Reduce the number of products rendered on the first screen.

Part 2: Practice – Performance Optimization Journey

Automatic Pagination Rendering

Background

Initially, to shorten white‑screen time, the cart used split‑screen rendering, separating data into first‑screen and non‑first‑screen parts, rendering the latter after the former completed. The main issue was that large non‑first‑screen data caused long render times, leading to prolonged waiting or even page freeze. As business grew, this impact became more evident, prompting a switch to pagination.

1. Technology Selection

Challenges:

Complex business – cannot implement server‑side paging quickly, so only front‑end paging is feasible.

Large data – each product may include gifts, exchange items, etc.

Dynamic list order – promotions can move items, requiring repositioning after changes.

After evaluating options, we chose automatic pagination rendering.

2. Core Idea

Request all data at once.

Divide data into pages, render one page at a time.

After a page finishes, automatically render the next page.

3. Comparison of Loop Rendering Approaches

Recursive setData – keeps UI thread busy, slowing user interaction.

setTimeout – delays next page but timing is uncontrolled.

Time slicing with requestAnimationFrame (raf) – aligns with 60 fps frame interval (~16.6 ms) for smoother rendering.

Experiments led us to adopt the time‑slicing mode.

4. Example

Demo: https://developers.weixin.qq.com/s/XJEDb3mP7Kex

Principle: replace timer with raf; after each setData, delay ~16.6 ms before rendering the next page.

Implementation: trigger a wxs event listener after setData, call raf inside, and render the next page in the raf callback.

Flow diagram:

5. Effect Comparison

Side‑by‑side screenshots show that automatic pagination reduces operation time by over 50% compared with split‑screen rendering.

Removing scroll-view

The scroll‑view component provides scroll‑into‑view functionality but consumes more memory and CPU than a plain view, degrades scrolling experience, and can cause frame drops or white screens on low‑end devices.

To improve scrolling, we removed scroll‑view and replaced it with wx.pageScrollTo (available from base library 2.7.3) or custom code for earlier versions.

Example code:

_pageScrollTo ({ partten }) {
    if (this.createSelectorQuery && wx.pageScrollTo) {
        const query = this.createSelectorQuery()
        query.selectViewport().scrollOffset()
        query.select(partten).fields({ rect: true })
        query.exec(function (res) {
            if (res) {
                const windowHeight = (wx.getSystemInfoSync() || {}).windowHeight || 619
                const offsetY = windowHeight * 0.35 // target offset from top
                const _scrollTop = res[0].scrollTop // current scroll position
                const _top = res[1].top // target element top
                const scrollTop = _scrollTop + _top - offsetY
                wx.pageScrollTo({ scrollTop, duration: 0 })
            }
        })
    }
}

Disabling scroll animation further reduces white‑screen risk on low‑end devices.

Effect Comparison

After removing scroll‑view, scrolling shows almost no white‑screen artifacts.

Data Preloading

Preloading fetches data before the page becomes visible, reducing white‑screen time.

1. Types

Preload on navigation: request data during the transition to the target page.

Predictive preload: anticipate likely navigation from page A to B and request B’s data while still on A.

2. Navigation‑time Preload

Goal: shorten white‑screen by using idle time between navigation trigger and onLoad.

3. Predictive Preload

Goal: large reduction of target page white‑screen time by loading data in advance.

Drawbacks: not suitable for highly time‑sensitive data; may waste resources if user never visits the preloaded page.

4. Effect Comparison

Predictive preload reduces first‑screen time by 40%; navigation‑time preload by 27% compared with no preload.

Leveraging Cache

Caching can cut request count and improve performance, especially for stable data like images, fonts, and config files. Even for frequently changing cart data, a cache layer can help.

Implementation

We keep a cache of key cart data; each API call updates the cache. When reopening the cart, if conditions allow, we render from cache directly.

Effect Comparison

Cache mode is 44% faster than regular onLoad loading and 23% faster than preloading.

Logic Relocation

Moving part of the front‑end business logic to the backend reduces front‑end code size, aids multi‑platform consistency, lowers development effort, and improves project controllability.

Benefits

Smaller front‑end bundle, crucial for mini‑program size limits.

Unified implementation across platforms, avoiding divergent UI.

Reduced manpower by centralizing logic.

Easier emergency fixes since back‑end changes deploy faster.

Goal: front‑end develops once; subsequent iterations are handled by back‑end.

Refactoring Process

Guidelines:

Use backend for static text display.

Consolidate identical status fields.

When a field serves both display and logic, consider backend delivery of key data and simple front‑end concatenation.

Summary

In practice, the cart page employs a combination of strategies—cache mode, automatic pagination, preloading, and fallback conventional rendering—selected dynamically based on device and scenario to ensure essential functionality while delivering an optimal experience.

The article focuses on the performance optimization process and ideas rather than deep implementation details, hoping readers gain new insights.