Server‑Side Rendering (SSR) Optimization: Use Cases, Performance Gains, and Implementation

BBC discovered that each additional second of page load time causes a 10% drop in users. To improve the page‑first‑paint rate, we started exploring server‑side rendering (SSR) beyond browser‑only optimizations.

Which business scenarios are suitable for SSR?

What performance improvements does SSR bring?

What are the costs of adopting SSR?

SSR moves the rendering process to the server, allowing low‑end devices or poor networks to receive a fully rendered HTML without waiting for JavaScript execution. It also enables first‑screen API aggregation on the Node layer, providing a smoother, flicker‑free experience.

Advantages

Beneficial for first‑screen rendering.

Improves SEO.

Significant performance boost on mid‑ and low‑end devices.

Disadvantages

Longer white‑screen time before the page becomes interactive.

Higher server CPU load.

Higher development learning curve.

Based on the page characteristics (multi‑channel acquisition, high proportion of low‑end devices), we chose SSR for optimization.

Performance Comparison (CSR vs SSR)

Render Mode

Low‑end

Mid‑end

High‑end

CSR

1648.02 ms

1543.64 ms

1257.86 ms (-211 ms)

SSR

1545.39 ms (-103 ms)

1531.11 ms

1468.47 ms

TMQ First‑Screen Time

Render Mode

Low‑end (vivo Y67)

High‑end (Realme X50)

CSR

2510 ms

1640 ms

SSR

1420 ms (-1090 ms, -43%)

880 ms (-760 ms, -46%)

Observations: low‑end devices see performance gains, while high‑end devices may regress because client‑side performance already exceeds server processing.

SSR Solution Selection

We compared Rax and ICE 3.0:

Rax : integrated engineering, front‑back‑end co‑location, low ops cost, automatic downgrade, stable and mature.

ICE 3.0 : richer React ecosystem, streaming rendering, but requires migration of existing Rax components.

Given stability and time constraints, we adopted the Rax solution, leveraging Serverless for gray‑release, rollback, and monitoring, and using its automatic downgrade when SSR fails.

Development Cost

. 
├── build.json
├── f.yml                                    # Function platform config
├── jest.config.js
├── midway.config.ts
├── package.json
├── src
│   ├── apis                                 # Function source
│   │   ├── configuration.ts
│   │   ├── lambda                           # API handlers
│   │   │   ├── index.test.ts
│   │   │   └── index.ts
│   │   ├── render                           # SSR entry
│   │   │   └── index.ts
│   │   └── typings
│   │       └── context.d.ts
│   ├── app.json
│   ├── app.ts
│   ├── components/
│   ├── document/
│   ├── pages/
│   └── typings.d.ts
└── tsconfig.json

The migration from CSR to SSR mainly involves adding an apis directory for render functions and ensuring page code can run in a Node environment.

Key guidelines:

Avoid asynchronous data updates that affect the initial render.

Simulate browser globals (e.g., location , navigator ) on the server.

Remember that lifecycle methods and hooks are not executed during server rendering.

In summary, SSR is not a universal solution; it should be applied selectively based on device distribution and page complexity. Best practices include selective rendering, streaming HTML to reduce white‑screen time, and using static SSR with CDN caching for non‑personalized pages.