How Server‑Side Rendering Supercharged Double‑11 Page Performance

Background

The Double‑11 event page is a key traffic driver, and its user experience is constantly scrutinized. In 2020, without changing the existing architecture or business logic, we introduced SSR and raised the page‑open rate to 82.6% while achieving up to a 5% increase in UV click‑through rates.

Core Performance Metrics

We adopt a simplified evaluation system based on Web.dev, focusing on TTFB, FP, FCP, FSP (≈FCP/LCP), LCP, and TTI. These metrics help us quantify the perceived speed of the page.

Current CSR Architecture

The original client‑side rendering (CSR) pipeline consists of three parts: the client (mobile Taobao/Alipay apps), the document service delivering the HTML skeleton, and the data service providing module data. The page is built from a layout HTML and a set of floor modules, each with its own JS/CSS assets.

Problems with CSR

Slow experience on low‑end Android devices and poor network conditions.

External app launches add extra initialization time, making the page feel slower than native‑inside experiences.

Cache expiration leads to repeated rendering and visual jitter.

Offline analysis showed a long gap between FP and FCP (mostly background color) and between FCP and LCP (waiting for images), indicating limited optimization space.

Why Switch to SSR?

SSR directly addresses the FP‑to‑FCP gap by rendering the first screen on the server, reducing the perceived blank time. A simple demo using Rax Server Renderer (renderToString) is straightforward, but a production‑grade solution must consider stability, cacheability, and security.

Data‑SSR Architecture

We designed a “data SSR” approach where the document service still returns a static HTML skeleton, while a separate SSR FaaS function receives the module list and data, loads the required modules on the server, and injects the rendered HTML into the root container. This preserves existing client‑side caches and data‑preload mechanisms.

Smooth CSR/SSR Switch

If the data response contains SSR HTML, the client hydrates it; otherwise it falls back to the original CSR flow. This low‑risk fallback can be controlled by a short server‑side timeout (e.g., 80 ms) and allows gradual traffic rollout via hash‑based bucketing.

Making Modules SSR‑Ready

Most existing modules work without changes. We disabled Webpack’s Node polyfills (e.g.,

process.env

) and provided shims for

window

,

document

,

navigator

, etc., so server‑side execution behaves like the browser. A VSCode SSR plugin and a Webpack preview plugin help developers catch SSR‑incompatible code early.

<code>/**
  示例的 CMD 规范显式依赖关系（seed）
**/
{
  "packages": {
    "@ali/pcom-alienv": {
      "path": "//g.alicdn.com/code/npm/@ali/pcom-alienv/1.0.2/",
      "version": "1.0.2"
    }
  },
  "modules": {
    "./index": ["@ali/pcom-alienv/index"]
  }
}
</code>

Server‑Side Performance

Server parsing time is reduced by caching compiled

vm.Script

instances, and the high‑end server hardware makes rendering cheap (average 40 ms). The extra HTML payload adds ~10 KB, increasing network time by 30‑100 ms, but overall first‑screen time drops from ~1500 ms (CSR) to ~660 ms (SSR), a gain of about 800 ms.

Evaluation

We measured both performance (FCP, TTI) and business impact (UV click‑through). Using AA/AB experiments with hash‑based buckets, we observed a 30%‑114% increase in the proportion of users reaching the first screen within 1 s on Android, and a 5% uplift in UV click‑through rates.

Future Directions

Unify e‑commerce performance metrics across Web, Native, and Hybrid.

Leverage Webpack 5’s browser‑like target and custom browserslist for better cross‑platform builds.

Improve static code checks to catch SSR‑unsafe patterns.

Combine ServiceWorker snapshots with SSR for repeat visitors.

Explore edge‑computing and streaming SSR to further reduce TTFB while preserving fallback safety.

Conclusion

Continuous refinement of the rendering architecture enables us to adapt to fragmented devices, complex networks, and evolving business needs. While the ultimate goal is a world where performance optimizations become unnecessary, today SSR delivers tangible user‑experience gains and measurable business value for Double‑11.