How Serverless SSR Boosted Mobile H5 Performance for Alibaba's Feizhu Event

Background

During the PC era, template‑based synchronous rendering was standard, but mobile networks and device variability made page load times unpredictable. To reduce page size, support offline capabilities, and align with front‑back separation, static resource separation and asynchronous rendering became the default for mobile H5 pages.

Under weak 2G/3G conditions, offline static resources allow pages to remain usable, providing a fallback page when the network is unavailable. Offline capability has been a core part of the mobile H5 stack for the past five years.

With the rollout of 4G and the arrival of 5G, network latency has dropped to single‑digit milliseconds, prompting a re‑evaluation of front‑end rendering strategies for future networks and devices.

Problems in the Current Marketing System

The existing Feizhu marketing page rendering chain is serial: after the API response, the page must fetch module caches before rendering, resulting in long and unstable latency.

First‑screen module load times are 500‑600 ms on Android and 400‑500 ms on iOS, with total first‑screen times around 1.5‑2 seconds, causing user abandonment.

Local HTML caching of the first screen reduces repeat load time, but it only works after a user has visited the page once and fails if the cache is cleared.

The cache cannot help first‑time visitors.

Personalized data may become inconsistent with cached HTML, causing re‑rendering and visual flicker.

SSR Solution Design

To address these issues, we explored combining Serverless Faas with React/Rax SSR. Node Faas SSR enables isomorphic code execution, reducing CPU load on servers and providing elastic scaling.

Client‑side rendering speed varies with device capability; moving rendering to the server mitigates this.

Server‑side rendering eliminates the ~300 ms module load time on the client.

We adopted an asynchronous SSR approach that injects the first‑screen HTML returned by MTOP directly into the page, allowing offline and prefetch mechanisms to accelerate page display.

MTOP: Alibaba’s internal mobile API gateway.

Implementation Details

We injected a placeholder titlebar DOM with a default height on the SSR side, then replaced it with the actual height after the HTML is inserted on the client.

function renderTitlebarP(type, stickyPaddingTop) {
  return (
    <Fragment>
      {type === 1 ? <View className="ssr-title-bar-main" style={{position: 'fixed', top:0, height: 0, left: 0}} /> : null}
      <View className="title-bar ssr-title-bar" style={{width: '750rpx', height: stickyPaddingTop + 'rpx', position: 'relative'}} />
    </Fragment>
  )
}

// web render
if (html) {
  const pageContent = document.getElementsByClassName('mui-zebra-page-content')[0];
  pageContent.innerHTML = html;
  // Adjust titlebar height after injection
  ssrTitlebar.style.height = `${stickyPaddingTop}px`;
}

Challenges Encountered

Image Flicker

Rax’s native picture component adds a .webp suffix based on device support. In SSR, the device check returns false, causing images to lose the .webp suffix and flicker.

Solution: Replace the native component with a custom one that ensures consistent suffix handling in both SSR and client rendering.

Immersive Titlebar Support

During SSR, the server cannot query the native container for the titlebar height, leading to mismatched heights.

Solution 1 (discarded): Pass titlebar height via MTOP before SSR, but prefetch may bypass this step.

Solution 2: After SSR HTML injection, retrieve the actual titlebar height from the client and adjust the placeholder DOM accordingly.

Offline Package Integration

The Feizhu offline package renders a unified HTML page. SSR acts as a switch: when the offline package is hit, the SSR‑generated HTML is used.

We added a whitelist for SSR URLs to ensure only designated pages go through the SSR path.

Page Effects

Before and after SSR screenshots demonstrate the reduction in visual flicker and faster content display.

Performance Results

Online data shows that pages with SSR become visible in under 1 second, a significant improvement over traditional first‑screen times.

In Wi‑Fi experiments, SSR increased MTOP response size but reduced overall page‑visible time, keeping most pages under the 1‑second threshold.

Average first‑screen MTOP time with SSR: ~514 ms.

Average first‑screen total time with SSR: ~1.05 s.

Without SSR, total times exceed 1.3 s on both iOS and Android.

Server‑Side Performance and Stability

SSR service latency averages 30‑40 ms in stress tests and around 49 ms in production.

SSR is CPU‑intensive; we allocate more machines than typical functions and use elastic scaling.

A 60 ms timeout is configured: requests exceeding this fallback to client‑side rendering.

We also have a global SSR disable switch for emergency degradation.

Future Plans

Explore synchronous SSR to further reduce first‑screen time, especially for external scenarios where API latency dominates.

Implement AB testing to compare SSR‑enabled and SSR‑disabled experiences on the same page.

Standardize SSR capabilities to reduce manual whitelist configuration.

Continue optimizing server‑side execution speed and migrate functions to Function Compute for better elasticity.

Conclusion

In a multi‑device front‑end ecosystem, client‑side pre‑rendering, Weex, and Flutter struggle to achieve universal instant page loads. Embracing native HTML rendering with Serverless SSR offers a forward‑looking solution for varying network conditions, representing a practical cloud‑plus‑edge approach in the current Serverless era.