How Youku Revamped Its Frontend: From PHP to Node.js and React SSR

Evolution Path

Youku’s front‑end team built on earlier PC homepage and channel page rewrites to create a reusable React server‑side rendering (SSR) framework, which has been open‑sourced on GitHub (https://github.com/ykfe/egg-react-ssr) and earned 657 stars by January 2020.

1. First Version: Bigpipe + jQuery

The initial implementation used Bigpipe combined with Nunjucks template compilation. Templates and data were compiled into HTML fragments, which were streamed to the browser in chunks during the request lifecycle.

Bigpipe offered two main advantages: compatibility with legacy browsers such as IE6, and the ability to aggregate heterogeneous back‑end services (PHP, Java, HTTP) into a unified Node.js‑driven rendering pipeline.

Page rendering was staged: first render the layout, then the first‑screen content (especially the player and episode list on the video page), and finally load non‑visible parts lazily.

2. Current Version: React SSR

React SSR was adopted after stabilizing the Bigpipe foundation. The team evaluated next.js and easywebpack, ultimately choosing a next.js‑style approach for its clean API and compatibility with the existing Biglet concept.

Advantages of the new solution: simple and elegant implementation, seamless SSR/CSR switching, full JSX support, and deep integration with Alibaba’s ecosystem.

Both server‑side and client‑side code can run the same bundle, enabling automatic fallback to client rendering when server load is high or when backend services fail, with CDN‑based data fallback for resilience.

3. Component‑Level Isomorphism: One‑Click CSR/SSR Switch

The video page now consists of multiple components (first‑screen, distribution area, danmaku, player, comments, etc.). During the upgrade, components such as danmaku and comments were refactored and gradually rolled out.

4. Server‑Side JS Bundle Publishing: Decoupled Deployment

A configuration‑driven workflow was created to publish server‑side and client‑side bundles without requiring a full application release. Benefits include consistent build and release processes, instant effect of bundle updates, and reduced operational overhead.

5. Performance Comparison

Testing the pre‑release video page in Chrome incognito mode showed:

PC page first‑screen render time: 150 ms, document size 37 KB, time‑to‑first‑byte ~120 ms.

H5 page performance improved threefold compared to the legacy implementation.

6. Future Direction: Serverless SSR

With the rise of Function‑as‑a‑Service (FaaS), the team envisions a serverless rendering layer that:

Uses next.js/egg‑react‑ssr syntax to unify CSR and SSR.

Leverages Umi SSR to generate a standalone umi.server.js for rendering.

Encapsulates webpack and React, simplifying development and allowing graceful degradation via CDN.

Integrates FaaS APIs for rendering.

The core ctx.ssrRender method loads Page.server.js from the dist directory and returns the rendered HTML.

7. Standards and Implementation

The minimal example defines render (required) and getInitialProps (optional). In SSR mode, data can be fetched using a simple or Bigpipe‑style pattern.

8. Ecosystem

Alibaba’s front‑end ecosystem, including React component libraries, multi‑platform frameworks, and Node.js web frameworks, is widely adopted. The team expects more serverless‑friendly solutions to join the ecosystem, further accelerating front‑end development.

Overall, the article outlines a four‑stage architectural evolution—from pure CSR, through SSR, to full isomorphic development, and finally to serverless rendering—highlighting the increasing demands on developers and the continuous pursuit of simplicity and efficiency in front‑end engineering.