How Youku Revamped Its Frontend: From PHP to React SSR and Serverless

At the end of 2017, Youku only used Node.js on a few Passport and Tudou pages, while most PC and H5 core pages were rendered with PHP templates. Over the next two years, leveraging Alibaba's technology stack, the team rebuilt PC and H5 front‑ends with Node.js and introduced React Server‑Side Rendering (SSR), which successfully handled the 2019 Double 11 traffic.

Key Changes

1) All C‑end core pages were rewritten in Node.js, completing the migration from PHP and allowing the front‑end team to support business without PHP developers.

2) The rendering stack moved from Bigpipe + jQuery to React SSR, reducing PC first‑paint time to 150 ms, cutting player start‑up time from 4.6 s to 2 s, and tripling H5 performance.

Bigpipe + jQuery Era

The original architecture used Bigpipe with Nunjucks templates to compile HTML on the server, then streamed chunked HTML to the browser. Its two main advantages were compatibility with legacy browsers (e.g., IE6) and the ability to aggregate heterogeneous back‑end APIs (PHP, Java, HTTP) on the server, ensuring rapid iteration and stable performance.

Render layout first.

Render the critical first screen (player and episode list on the playback page).

Lazy‑load invisible parts.

Adopting React SSR

React SSR was introduced after stabilizing Bigpipe. It offered better compatibility, easier team growth, and a clearer upgrade path. The team evaluated next.js and easywebpack; next.js provided a cleaner API and fit well with the existing Biglet abstraction, leading to a next.js‑style implementation.

Simple and elegant implementation.

Seamless SSR/CSR switching.

Full JSX support.

Integration with Alibaba ecosystem.

Both server‑side and client‑side code can run the same bundle, enabling graceful degradation: when server rendering is under pressure, the page falls back to client rendering, and CDN data can be used as a fallback for API failures.

Component Refactoring

The playback page components (first‑screen, distribution area, danmaku, player, comments, etc.) were refactored; danmaku and comments have already been rolled out with the new version.

Server‑Side JS Bundle Publishing

A configuration‑driven workflow was created so that server‑side bundles can be updated without redeploying the application, ensuring consistent build and release processes and immediate effect.

Performance Comparison

In pre‑release tests, the PC playback page achieved a 150 ms first‑paint with a 37 KB document size, while the H5 playback page saw a three‑fold performance boost.

Future: Serverless SSR

The roadmap points toward a serverless rendering layer built on Functions‑as‑a‑Service (FaaS). By using next.js/egg‑react‑ssr or Umi SSR, the same codebase can serve both CSR and SSR, with the server‑side bundle packaged as Page.server.js and deployed to a serverless environment, eliminating the need to manage webpack or egg.js in production.

Architecture Stages

CSR: developers manage React and webpack.

SSR: developers manage React, webpack, and egg.js.

Umi SSR: developers manage React and egg.js; webpack is hidden.

Serverless SSR: developers only need to care about React.

These experiences have distilled a simpler, more efficient front‑end development model that the team aims to extend in the serverless era.