SSR Rendering Solution and Performance Optimization for the 360 Search Encyclopedia Mobile Project

Project Background

The SSR generic solution originated from a refactor of the 360 Search Encyclopedia mobile project, driven by an outdated tech stack (Smarty + PHP + jQuery), chaotic project structure, and the need to modernize and streamline development.

Reconstruction Technology Selection

Three options were considered: (1) keep the old stack, (2) adopt React + Next + Webpack, (3) adopt Vue + Nuxt + Webpack. After comparing learning cost, performance, and reusability, Vue + Nuxt + Webpack was chosen.

What is SSR Rendering?

SSR (Server‑Side Rendering) generates static HTML on the server, which is sent to the browser and then hydrated into a fully interactive SPA. Compared with CSR (Client‑Side Rendering), SSR reduces first‑paint time and improves SEO.

SSR Generic Solution Components

so_nuxt scaffolding based on Nuxt.js, integrated with the internal so‑cli tool.

nuxt2‑qcdn‑plugin for static asset uploading to QCDN.

CSR fallback strategy using vm‑spider for crawler access.

Comprehensive documentation of alarm configuration, stress‑test plans, and troubleshooting.

Current Architecture Design

The architecture places the Node SSR service and the frontend code in the same deployment, allowing the server to request local APIs directly and avoiding extra proxy hops.

Project Reconstruction Process

Modular extraction of common components to solib/m‑vue.

SVG icons moved to solib/icons and wrapped as Vue components.

Integration of solib/m‑vue with Nuxt.

Refactoring of page modules.

Performance optimization iterations.

Implementation of nuxt2‑qcdn‑plugin and CSR fallback.

Performance Optimization – Phase 1

Initial stress test showed average response time 1275 ms (QPS ≈ 38). Reducing DOM size and moving non‑essential parts to CSR lowered average latency below 500 ms, with peak QPS ≈ 221, but P99/P95 spikes remained.

Performance Optimization – Phase 2

CSR mode was tried with UA‑based routing and skeleton screens, improving response time and QPS, yet high‑latency spikes persisted due to backend constraints.

Performance Optimization – Phase 3

Since the bottleneck was not SSR itself, three scaling strategies were evaluated: (1) PM2 multi‑instance mode, (2) adjusting pod count and resources, (3) adding cache (redis, lru‑cache). PM2 introduced deployment complexities and errors (e.g., Docker‑runtime issues, Nuxt config path problems, environment variable overload), leading to its dismissal.

Pod Scaling Experiments

Testing 12, 14, and 20 pods showed 14 pods offered the best balance of concurrency, latency, and QPS; further scaling gave diminishing returns.

Multi‑Solution Comparison

Dynamic pod scaling outperformed PM2 and cache approaches in both performance and operational simplicity; cache was omitted from production due to lack of shared state across pods.

Post‑Launch Issues

After deploying the optimized SSR mode, latency spikes largely disappeared, but frequent P99 alarms and occasional pod restarts persisted, caused by external node failures, resource spikes, and edge‑node packet loss.

Final Conclusion

The final deployment uses nginx 2G + 2CPU, PHP 4G + 2CPU, and Node 4G + 2CPU, with 14 pods delivering stable performance comparable to the pre‑refactor baseline.

Summary

For knowledge‑product websites, SEO and fast content delivery are critical; this case study validates the feasibility of SSR rendering and provides a practical reference for frontend teams adopting modern technologies.