Baidu Live R&D's New SSR Strategy: Enabling Server‑Side Rendering for Web Applications with Minimal CSR Changes

The article begins by describing the motivation behind moving from pure client‑side rendering (CSR) and static site generation (SSG) toward server‑side rendering (SSR) to improve page load experience, SEO, and overall web application quality.

It outlines four primary objectives: achieving isomorphic SSR with 100% code reuse and minimal JavaScript overhead, enabling near‑zero integration effort within existing CSR directories, providing a seamless development experience that aligns with NoOps principles, and ensuring performance guarantees such as faster first‑meaningful‑paint and SEO friendliness.

To meet these goals, the authors propose a Function‑as‑a‑Service (FaaS) based SSR framework that leverages a PaaS environment offering pre‑warming, elastic scaling, container isolation, and low operational cost. The core SSR library is lightweight, modular, and framework‑agnostic, allowing components to run on Node.js servers while reusing the same code on the client.

The SSR pipeline consists of several resources: a page template (the original CSR HTML), a Webpack‑generated bundle for server execution, an SSR compute function (FC) that runs in a sandbox, and backend‑as‑a‑service (BaaS) data fetched via server‑to‑server calls. Routing metadata (manifest.json, module info, router Lambda) directs requests to the appropriate resources.

Component response is achieved by rendering contentful HTML on the server and then hydrating it on the client, enabling full interactivity with minimal changes. Interface descriptions use a JSON‑Scheme language to define API endpoints, parameters, headers, and authentication, allowing the FaaS layer to translate browser requests into backend calls efficiently.

During the build phase, the system produces module manifests, page bundles, and SSR compute functions, automating the deployment pipeline for large‑scale rollout.

For developers, the solution offers a local‑first workflow: developers can see SSR results instantly without needing deep DevOps knowledge, thanks to FaaS SDK plugins that integrate with existing tooling.

Risk control is addressed through a “two‑cache one‑fallback” strategy: proxy‑layer cache, FaaS‑layer cache, and a graceful degradation to CSR when caches miss, improving overall service resilience.

Finally, the article looks ahead, emphasizing that the SSR upgrade lowers system entry barriers, promotes engineering best practices, and can be extended to many modules, positioning the approach as a flexible, future‑proof foundation for web application development.