Inside Kuaishou’s Low‑Code ‘Jimu’ Platform: Solving Large‑Scale Event Page Challenges

Kuaishou’s low‑code building platform “Jimu” underpins more than 90% of the company’s activity pages. Using the 2025 CNY campaign as a case study, this article outlines the platform’s architecture, performance bottlenecks, and system integration strategies.

1. Technical challenges of large‑scale events

Efficiency : Need to satisfy requirements without code whenever possible.

Quality : Ensure smooth video and live‑stream playback and visual fidelity across devices.

The platform faces four major challenges:

Inherent conflict between reuse and innovation.

Page complexity leading to performance bottlenecks.

Concurrent rendering of dozens of video players.

Responsive layout adaptation for tablets and foldable screens.

2. Balancing reuse and innovation

We adopt a “90% build + 10% custom” hybrid model. Components are atomized and containerized, allowing flexible composition while keeping a stable core library of 300+ components.

2.1 Component atomization & containerization

Small atomic components (e.g., button, image, video) are combined inside containers (e.g., spotlight container) to create complex UI without breaking reuse.

2.2 Master‑template synchronization

A master template propagates property and event changes to all child instances. Overrides on a child stop further synchronization.

2.3 Logic orchestration

Visual logic flows link component actions, such as triggering a lottery after a user successfully books a live‑room.

2.4 Custom development

Three capabilities are provided: extensible component APIs, white‑box component forking, and lightweight external development with on‑the‑fly code compilation.

3. High‑performance rendering architecture

3.1 Static Site Generation (SSG)

Pages are pre‑rendered at build time, moving most calculations out of the runtime. Only the first‑screen content is rendered initially; the rest loads lazily.

3.2 Component rendering optimization

Component tiered rendering : First‑screen components load synchronously with inline styles; secondary components load asynchronously; on‑demand components (e.g., hidden tabs, drawers) load only when needed.

Async script loading : Public dependencies use defer, component scripts use async. Scripts are emitted as type="text/plain" and switched to text/javascript when executed.

Preload / prefetch : First‑screen scripts are preloaded, others are prefetched.

First‑screen style merging : Critical CSS is inlined into the HTML to avoid reflow/repaint.

Component size reduction : Migration from Webpack to Rspack and on‑demand polyfills cut bundle size by ~66% (gzip ~68%).

3.3 Multi‑player scheduling engine

A single‑instance player model preserves playback state when switching. The engine collects all players, sorts by viewport position, prefers fully visible elements, and respects user clicks. It also handles overlay components, animation end events, and delayed switching to avoid flicker.

3.4 Multi‑device layout adaptation

We replace vw‑based scaling with a CSS‑calc solution using a custom variable --jimu-responsive-ratio and an offset for fixed‑position elements, enabling consistent max‑width constraints on tablets and foldable screens.

4. Conclusion and outlook

The case study demonstrates how “Jimu” balances rapid low‑code construction with the flexibility needed for innovative large‑scale activities. Future work will deepen AI integration to further automate component generation and customization, expanding the platform’s capability frontier.