How to Optimize Shop Frontend Performance with Micro‑Frontend Architecture

Background

Shop pages are a crucial part of the guide, handling billions of visits from product detail pages, main venues, and search. Because the shop is a high‑traffic, complex, and highly stable scenario, performance optimization is challenging and requires collaboration across container, server, and frontend teams.

Shop Architecture Overview

The shop serves millions of merchants, each with different operational needs and brand personalization requirements, resulting in multiple pages per shop that support custom decoration.

To meet these personalization demands, a micro‑frontend architecture with two‑layer dynamism was designed:

Micro‑frontend architecture: shop framework + multiple embedded pages

Shop framework: renders basic shop information and manages tabs

Embedded pages: home, product, category, etc.

Two‑layer dynamism: page‑level + component‑level

Page‑level: merchants can configure which pages appear

Component‑level: each page consists of modules that merchants can decorate

The final technical architecture is shown below:

Embedded pages are provided by official, third‑party, and ISV modules, allowing merchants to customize decoration and personalize recommendations based on algorithmic data. This article focuses on how the complex shop architecture is optimized for performance.

Performance Collection

We treat the user click to first‑screen visibility as a full‑link trace, divided into client‑side and business‑logic stages.

Traditional performance points focus only on the frontend, but our program runs on a mini‑program container. The container stage (startup, resource loading, environment creation) is also critical. We defined a unified performance reporting schema that merges client and business custom points into a single log. Frontend only needs to emit a point before and after a stage; the duration is computed from the two timestamps.

my.call('markPerformance', {
  name,
  time: Date.now()
});

The example shows name as a business‑defined marker (e.g., request start) and time as the timestamp. The collected logs are processed into visual dashboards that can be filtered by device, OS, or experiment bucket.

Device view (Android, iOS)

Device tier (low‑end, mid‑end, high‑end)

Bucket (AB test)

With stage durations identified, targeted optimizations can be applied and their impact verified through data.

Performance Optimization

The diagram below shows the main stages from click to first‑screen render from the container perspective.

The stage consists of:

Container time : URL interception, container creation, metadata loading, framework (appx) download

Engine time : environment creation, context initialization, loading required HTML, CSS, JS

Network I/O and WebView/JS engine initialization dominate this phase. Optimizations include pre‑loading the appx framework, local assembly of metadata, static plugin pre‑loading, worker and render pre‑start, and caching of JS APIs.

Interface Optimization

Pre‑loading and caching are common tactics. The routing and shop APIs were optimized in three layers:

CDN cache : static decoration APIs are pushed to CDN and refreshed only on merchant changes.

Local cache : routing and shop APIs are cached locally to reduce serial request time.

Interface pre‑load : routing API supplies parameters for the shop API, enabling its pre‑loading.

Despite caching, some APIs remain serially dependent, such as the algorithm API that requires decoration data. To decouple, we added a special flag to the first‑screen algorithm module, moved the algorithm computation to the server, and allowed parallel loading of decoration and algorithm data.

Further, we leveraged client‑side pre‑fetch for four key APIs (shop, decoration data, downgrade API). The downgrade API, having no parameter dependencies, was turned into a local‑storage‑plus‑async‑update pattern, converting network latency into cache latency.

Parallel Rendering

Originally, the shop framework loads first, then each embedded page loads sequentially. We restructured to render the framework and embedded page in parallel by delivering the embedded page URL with the shop API and allowing the container to render both simultaneously.

Parallel rendering yields a large performance gain because rendering time and API latency differ in magnitude.

Snapshot Rendering

Between user click and business‑logic execution, the container stage can cause a white screen. Traditional snapshot files are impractical for millions of shops. We introduced template‑based snapshot rendering: a template file combined with real data produces a real snapshot. After pre‑fetching the shop framework data, the container invokes a frontend method that returns the DOM structure, which is rendered directly as a snapshot.

Traditional snapshot : data may be stale, high disk usage, low hit rate, unsuitable for long‑tail merchants.

Template‑based snapshot : data is fresh, high hit rate, low disk usage, applicable to most shops.

Optimization Results

Overall Data

After optimization, the average first‑screen interactive time across all devices is about 1.8 seconds.

Low‑End Device Data

For a Vivo Y67, first‑screen time improved from 8.5 s to 4.78 s.

Summary and Reflection

We refined full‑link stage analysis, unified performance collection, performed targeted optimizations, and continuously validated improvements. This systematic approach can be reused for other business scenarios. Although the first phase yielded significant gains, achieving sub‑second experiences remains a long‑term goal.