服务端渲染(SSR) 通用技术解决方案

项目背景

服务端渲染(SSR) 通用技术解决方案的诞生来源于对 360搜索百科移动端项目的一次重构实践。而当时决定重构该项目的主要原因有以下几点：

1.  技术栈陈旧，熟悉、开发以及维护成本都较高

项目重构前的开发技术栈是 smarty + php + jQuery 的模式。在前端技术发展迅速的今天，vue 与 react 裹挟下的组件化开发模式愈发盛行，模块化语法开发模式也是层出不穷，这使得 smarty 开发模式对新人来说理解起来比较生涩难懂。

2. 项目结构管理混乱

项目重构之前存在2个代码库并存的状况。之前的同学为了项目开发的模式更加与时俱进，对项目的图册页进行了单独的抽离，采用了当时最新的 esNext 语法 和 webpack 的模块化开发模式进行了一次重构。但项目的开发流程很复杂：

    - 首先两个分离的项目需要并存在同一个开发环境下。

    - 其次需要对图册页的 webpack 进行自定义的配置，才能使得图册页项目的开发代码被构建到另一个整体代码项目中，这需要对 webpack 有一定的了解。

    - 最后编译到整体代码中的 css 文件中还需要手动删除多余的 js 文件避免内部编译的报错。

3. 重构的目标

除去上述两种原因外，由于该项目的周期已经非常久远，随着开发维护的不断变更，很多项目模块、代码文件也已经变的非常臃肿。所以本次的重构，除了要统一所有的页面技术栈，通过 eslint、commitlint、stylelint 等工具来统一开发规范外，重新梳理组织项目文件和目录结构以及相关业务模块也是重中之重。

重构技术选型

 对于该项目的重构，最初我们构想了三种方案：

1. 保持当前的技术栈 smarty + php + jQuery 模式，对现有的模块及目录结构进行重新梳理和调整。

2. 采用 React + Next + Webpack 的技术栈做 SSR 渲染。

3. 采用 Vue + Nuxt + Webpack 的技术栈做 SSR 渲染

首先，无论从技术发展的角度，或是从后期项目的维护与开发效率来看，方案一都失去了重构本来的初衷。毕竟，拥抱前沿技术，提高开发效率的重构才更有意义。

其次，我们对 React + Next 和 Vue + Nuxt 的技术栈做了调研对比：

1. 在相同吞吐量的情况下，两者的平均响应时间几乎是相同的，都比 smarty 模式要慢但在可接受范围内。

2. 从学习成本来说 vue 的技术栈更为大家熟悉和容易接受，这在一定程度上可以减少学习和开发时间。

3. 鉴于同期开展的 solib/m-vue 项目，可以在本次采用 vue 技术栈重构的同时，将可公用的模块进行组件化抽离到 solib/m-vue 中，形成一个既支持 SSR 又支持 CSR 模式的组件库，为后续其他移动端项目的重构提升开发效率。

4. 团队的星座项目就采用了 vue + nuxt + webpack 的技术栈，有可以借鉴的案例。
   

鉴于上述的对比和考虑，我们决定采用 Vue + Nuxt + Webpack 的技术栈进行 SSR 渲染模式的方案。

什么是 SSR 渲染？

在技术选型上，无论是采用 React 或是 Vue 我们都提到了一个关键字 —— SSR渲染。

什么是 SSR 渲染模式，以及为什么要使用 SSR 渲染呢？我们以 Vue 的 SSR 渲染模式为例。

CSR 模式

先从 CSR 模式说起，CSR 又称 "客户端渲染"(Client Side Render)，它还有另一个常见的称呼 ——"单页应用" (SPA)。

SPA的请求流程大概如下：

SPA 模式的请求执行顺序至少包含两个来回（空的 html 页面和数据的获取渲染），它有两个痛点：

1. 首屏内容到达时间较长，也就是常说的白屏时间较长。毕竟先渲染的是一个空白的 html 结构，然后再发送请求获取相关的页面数据信息进行渲染。

2. SEO不够友好，搜索引擎爬虫抓取工具需要直接查看完全渲染的页面。

   爬虫可以很好的对同步 JavaScript 应用程序进行索引，同步是关键。如果应用程序初始展示 loading 状态，然后通过 Ajax 获取内容，抓取工具并不会等待这个异步的过程。所以，如果 SEO 对站点至关重要，而页面又是异步获取内容，CSR显然不能满足需求。

于是，便有了 SSR 渲染模式。

SSR 模式

SSR 被称为"服务端渲染"(Server Side Render)。

Vue.js 是构建客户端应⽤程序的框架。默认情况下