How Vue‑SSR Solved SEO and Performance Challenges at Haodafu Online

This article analyzes the adoption of Vue Server‑Side Rendering at Haodafu Online, detailing its advantages for SEO and fast content delivery, the architectural integration with an existing Express/Node stack, performance testing results, degradation strategies, remaining issues, and future improvement plans.

HaoDF Tech Team
HaoDF Tech Team
HaoDF Tech Team
How Vue‑SSR Solved SEO and Performance Challenges at Haodafu Online

Introduction

For front‑end developers familiar with Vue, Vue‑SSR (Server‑Side Rendering) is a technique where the server renders Vue components into HTML strings and sends them to the browser, enabling “isomorphic” applications that run on both server and client.

What is Vue‑SSR?

SSR stands for Server‑Side Rendering. The server parses Vue components, renders them to HTML, and delivers the HTML to the client, where the page is hydrated and normal DOM operations continue. Because the application runs on both server and client, it is also called “universal” or “isomorphic”.

Advantages

Better SEO : The server‑generated page contains full HTML, which is friendly to search‑engine crawlers.

Faster Time‑to‑Content : Users see page content without waiting for the entire JavaScript bundle to download and execute, which is especially helpful on slow networks or devices.

Cross‑Platform Isomorphism : Most Vue code can run on both the server and the client, allowing shared logic and components.

Disadvantages

Development Constraints : Developers must separate code that runs on the server (no window, document) from client‑only code; external libraries may need special handling to work in a server environment.

Increased Server Load : Rendering the whole application on Node is CPU‑intensive, requiring careful capacity planning and caching strategies for high‑traffic scenarios.

Background & Current Situation

Haodafu Online originally used an Express + Handlebars stack to render HTML on the server. While this solved SEO, the approach suffered from frequent DOM manipulation, complex state management, and difficulty integrating Vue for reactive UI.

Existing Approaches

1. Express + Vue SPA – suitable for pages without SEO requirements but not for fast content delivery.

2. The team needed a solution that provides SEO, fast content arrival, and shared view‑layer code.

Vue‑SSR Implementation

After evaluating Nuxt.js and finding integration and maintenance costs high, the team chose the official Vue‑SSR API and built a custom solution that fits the existing Node architecture.

Request flow: the browser request reaches the Node layer, passes through middleware, is routed to a controller, which fetches business data, renders the selected template, and sends the HTML response.

Two Design Options

Option 1 : Run a separate Node service that uses Vue’s server renderer and fetches data via Axios. Rejected because service‑to‑service data is not publicly exposed, it would add an extra Node layer, and it does not fit the existing development workflow.

Option 2 : Integrate Vue SSR directly into the existing Node project.

Use @hnpm/h-ssr-action to match route rules, call asyncData, render server‑side HTML, and fall back to client‑side rendering when needed.

Set a custom request header x-hdf-ssr to distinguish server and client requests.

Unified request library @hnpm/h-ssr-fetch routes server‑side calls directly to actions, while client‑side calls go through Axios.

Helper @hnpm/h-ssr-server handles routing logic, loading indicators, server‑side degradation, and global guards.

Tooling Integration

skit ssr -i

– initialize a Vue SSR project. skit ssr -b – build the Vue SSR project. @hnpm/setup-dev-server – enable hot‑module replacement in development.

Performance Test & Degradation Strategy

A stress test on an 8‑core, 8‑process Node instance rendering 1,000 static items achieved roughly 2,200–2,300 QPS. The existing Node cluster can handle current traffic, but SSR adds noticeable CPU load.

Degradation mechanisms:

Configure rendering mode via Apollo; under high‑traffic alerts the whole cluster switches to client‑side rendering.

CPU‑threshold fallback: when a node’s CPU usage reaches a predefined limit, it automatically degrades to client rendering.

Per‑request fallback: if server‑side rendering fails for a single request, the system serves a template without data and lets the client fetch data asynchronously.

Remaining Issues

Data is still obtained from Vuex; for simple display data this adds unnecessary complexity.

Handlebars renders static data 20‑30% faster than Vue SSR in current benchmarks.

Future Plans

Synchronise asyncData results into component data (similar to Nuxt) to simplify data access during development.

Introduce effective caching strategies and further optimise Vue SSR rendering efficiency.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

performanceNode.jsSSRVueFrontend ArchitectureServer-side Rendering
HaoDF Tech Team
Written by

HaoDF Tech Team

HaoDF Online tech practice and sharing—join us to discuss and help create quality healthcare through technology.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.