SSR大家肯定都不陌生，通过服务端渲染，可以优化SEO抓取，提升首页加载速度等，我在学习SSR的时候，看过很多文章，有些对我有很大的启发作用，有些就只是照搬官网文档。通过几天的学习，我对SSR有了一些了解，也从头开始完整的配置出了SSR的开发环境，所以想通过这篇文章，总结一些经验，同时希望能够对学习SSR的朋友起到一点帮助。

我会通过五个步骤，一步步带你完成SSR的配置：

如果你现在对于我上面说的还不太了解，没有关系，跟着我一步步向下走，最终你也可以独立配置一个SSR开发项目，所有源码我会放到github上，大家可以作为参考。

这个配置相信大家都会，就是基于weback + vue的一个常规开发配置，这里我会放一些关键代码，完整代码可以去github查看。

最终效果截图：

完整代码查看github

服务端渲染SSR，类似于同构，最终要让一份代码既可以在服务端运行，也可以在客户端运行。如果说在SSR的过程中出现问题，还可以回滚到纯浏览器渲染，保证用户正常看到页面。

那么，顺着这个思路，肯定就会有两个webpack的入口文件，一个用于浏览器端渲染weboack.client.config.js，一个用于服务端渲染webpack.server.config.js，将它们的公有部分抽出来作为webpack.base.cofig.js，后续通过webpack-merge进行合并。同时，也要有一个server来提供http服务，我这里用的是koa。

我们来看一下新的目录结构：

在纯客户端应用程序(client-only app)中，每个用户会在他们各自的浏览器中使用新的应用程序实例。对于服务器端渲染，我们也希望如此：每个请求应该都是全新的、独立的应用程序实例，以便不会有交叉请求造成的状态污染(cross-request state pollution)。

所以，我们要对app.js做修改，将其包装为一个工厂函数，每次调用都会生成一个全新的根组件。

app.js

在浏览器端，我们直接新建一个根组件，然后将其挂载就可以了。

entry-client.js

在服务器端，我们就要返回一个函数，该函数的作用是接收一个context参数，同时每次都返回一个新的根组件。这个context在这里我们还不会用到，后续的步骤会用到它。

entry-server.js

然后再来看一下index.ssr.html

index.ssr.html

的作用是作为一个占位符，后续通过vue-server-renderer插件，将服务器解析出的组件html字符串插入到这里。

是为了将webpack通过webpack.client.config.js打包出的文件放到这里（这里是为了简单演示，后续会有别的办法来做这个事情）。

因为服务端吐出来的就是一个html字符串，后续的Vue相关的响应式、事件响应等等，都需要浏览器端来接管，所以就需要将为浏览器端渲染打包的文件在这里引入。

用官方的词来说，叫客户端激活（client-side hydration）。

所谓客户端激活，指的是 Vue 在浏览器端接管由服务端发送的静态 HTML，使其变为由 Vue 管理的动态 DOM 的过程。

在 entry-client.js 中，我们用下面这行挂载(mount)应用程序：

由于服务器已经渲染好了 HTML，我们显然无需将其丢弃再重新创建所有的 DOM 元素。相反，我们需要"激活"这些静态的 HTML，然后使他们成为动态的（能够响应后续的数据变化）。

如果你检查服务器渲染的输出结果，你会注意到应用程序的根元素上添加了一个特殊的属性：

Vue在浏览器端就依靠这个属性将服务器吐出来的html进行激活，我们一会自己构建一下就可以看到了。

接下来我们看一下webpack相关的配置：

webpack.base.config.js

webpack.client.config.js

注意，这里的入口文件变成了entry-client.js，将其打包出的client.bundle.js插入到index.html中。

webpack.server.config.js

这里有几个点需要注意一下：

这里关于HtmlWebpackPlugin配置的意思是，不要在index.ssr.html中引入打包出的server.bundle.js，要引为浏览器打包的client.bundle.js，原因前面说过了，是为了让Vue可以将服务器吐出来的html进行激活，从而接管后续响应。

那么打包出的server.bundle.js在哪用呢？接着往下看就知道啦~~

package.json

接下来我们看server端关于http服务的代码：

server/server.js

这里对两个端口进行监听，3000端口是服务端渲染，3001端口是直接输出index.html，然后会在浏览器端走Vue的那一套，主要是为了和服务端渲染做对比使用。

这里的关键代码是如何在服务端去输出html`字符串。

可以看到，server.bundle.js在这里被使用啦，因为它的入口是一个函数，接收context作为参数（非必传），输出一个根组件app。

这里我们用到了vue-server-renderer插件，它有两个方法可以做渲染，一个是createRenderer，另一个是createBundleRenderer。

createRenderer无法接收为服务端打包出的server.bundle.js文件，所以这里只能用createBundleRenderer。

serverBundle 参数可以是以下之一：

这里我们引入的是.js文件，后续会介绍如何使用.json文件以及有什么好处。

使用createRenderer和createBundleRenderer返回的renderer函数包含两个方法renderToString和renderToStream，我们这里用的是renderToString成功后直接返回一个完整的字符串，renderToStream返回的是一个Node流。

renderToString支持Promise，但是我在使用Prmoise形式的时候样式会渲染不出来，暂时还不知道原因，如果大家知道的话可以给我留言啊。

配置基本就完成了，来看一下如何运行。

最终效果展示：

访问http://localhost:3000/index

我们看到了前面提过的data-server-rendered="true"属性，同时会加载client.bundle.js文件，为了让Vue在浏览器端做后续接管。

访问http://localhost:3001/index还和第一步实现的效果一样，纯浏览器渲染，这里就不放截图了。

完整代码查看github

如果SSR需要初始化一些异步数据，那么流程就会变得复杂一些。

我们先提出几个问题：

带着问题我们向下走，希望看完这篇文章的时候上面的问题你都找到了答案。

服务器端渲染和浏览器端渲染组件经过的生命周期是有区别的，在服务器端，只会经历beforeCreate和created两个生命周期。因为SSR服务器直接吐出html字符串就好了，不会渲染DOM结构，所以不存在beforeMount和mounted的，也不会对其进行更新，所以也就不存在beforeUpdate和updated等。

我们先来想一下，在纯浏览器渲染的Vue项目中，我们是怎么获取异步数据并渲染到组件中的？一般是在created或者mounted生命周期里发起异步请求，然后在成功回调里执行this.data = xxx，Vue监听到数据发生改变，走后面的Dom Diff，打patch，做DOM更新。

那么服务端渲染可不可以也这么做呢？答案是不行的。

所以，参考一下官方文档，我们可以得到以下思路：

正常情况下，通过这几个步骤，服务端吐出来的html字符串相应组件的数据都是最新的，所以第4步并不会引起DOM更新，但如果出了某些问题，吐出来的html字符串没有相应数据，Vue也可以在浏览器端通过`Vuex注入数据，进行DOM更新。

更新后的目录结构：

先来看一下store.js:

store/store.js

如果不太了解Vuex，可以去Vuex官网先看一些基本概念。

这里fetchBar可以看成是一个异步请求，这里用setTimeout模拟。在成功回调中commit相应的mutation进行状态修改。

这里有一段关键代码：

因为store.js同样也会被打包到服务器运行的server.bundle.js中，所以运行环境不一定是浏览器，这里需要对window做判断，防止报错，同时如果有window.__INITIAL_STATE__属性，说明服务器已经把所有初始化需要的异步数据都获取完成了，要对store中的状态做一个替换，保证统一。

components/Bar.vue

这里在Bar组件的默认导出对象中增加了一个方法asyncData，在该方法中会dispatch相应的action，进行异步数据获取。

需要注意的是，我在mounted中也写了获取数据的代码，这是为什么呢？ 因为想要做到同构，代码单独在浏览器端运行，也应该是没有问题的，又由于服务器没有mounted生命周期，所以我写在这里就可以解决单独在浏览器环境使用也可以发起同样的异步请求去初始化数据。

components/Foo.vue

这里我对两个组件都添加了一个点击事件，为的是证明在服务器吐出首页html后，后续的步骤都会被浏览器端的Vue接管，可以正常执行后面的操作。

app.js

在建立根组件的时候，要把Vuex的store传进去，同时要返回，后续会用到。

最后来看一下entry-server.js，关键步骤在这里：

entry-server.js

我们通过导出的App拿到了所有它下面的components，然后遍历，找出哪些component有asyncData方法，有的话调用并传入store，该方法会返回一个Promise，我们使用Promise.all等所有的异步方法都成功返回，才resolve(app)。

context.state = store.state作用是，当使用createBundleRenderer时，如果设置了template选项，那么会把context.state的值作为window.__INITIAL_STATE__自动插入到模板html中。

这里需要大家多思考一下，弄清楚整个服务端渲染的逻辑。

如何运行：

最终效果截图：

服务端渲染：打开http://localhost:3000/index

可以看到window.__INITIAL_STATE__被自动插入了。

我们来对比一下SSR到底对加载性能有什么影响吧。

服务端渲染时performance截图：

纯浏览器端渲染时performance截图：

同样都是在fast 3G网络模式下，纯浏览器端渲染首屏加载花费时间2.9s，因为client.js加载就花费了2.27s，因为没有client.js就没有Vue，也就没有后面的东西了。

服务端渲染首屏时间花费0.8s，虽然client.js加载扔花费2.27s，但是首屏已经不需要它了，它是为了让Vue在浏览器端进行后续接管。

从这我们可以真正的看到，服务端渲染对于提升首屏的响应速度是很有作用的。

当然有的同学可能会问，在服务端渲染获取初始ajax数据时，我们还延时了1s，在这个时间用户也是看不到页面的。没错，接口的时间我们无法避免，就算是纯浏览器渲染，首页该调接口还是得调，如果接口响应慢，那么纯浏览器渲染看到完整页面的时间会更慢。

完整代码查看github

前面我们创建服务端renderer的方法是：

serverBundle我们用的是打包出的server.bundle.js文件。这样做的话，在每次编辑过应用程序源代码之后，都必须停止并重启服务。这在开发过程中会影响开发效率。此外，Node.js 本身不支持 source map。

vue-server-renderer 提供一个名为 createBundleRenderer 的 API，用于处理此问题，通过使用 webpack 的自定义插件，server bundle 将生成为可传递到 bundle renderer 的特殊 JSON 文件。所创建的 bundle renderer，用法和普通 renderer 相同，但是 bundle renderer 提供以下优点：

preload和prefetch有不了解的话可以自行查一下它们的作用哈。

那么我们来修改webpack配置：

webpack.client.config.js

webpack.server.config.js

因为是服务端引用模块，所以不需要打包node_modules中的依赖，直接在代码中require引用就好，所以配置externals: [nodeExternals()]。

两个配置文件会分别生成vue-ssr-client-manifest.json和vue-ssr-server-bundle.json。作为createBundleRenderer的参数。

来看server.js

server.js

效果和第三步就是一样的啦，就不截图了，完整代码查看github。

这里和第四步不一样的是引入了vue-router，更接近于实际开发项目。

在src下新增router目录。

router/index.js

这里我们把Foo组件作为一个异步组件引入，做成按需加载。

在app.js中引入router，并导出：

app.js

修改App.vue引入路由组件：

App.vue

最重要的修改在entry-server.js中，

entry-server.js

这里前面提到的context就起了大作用，它将用户访问的url地址传进来，供vue-router使用。因为有异步组件，所以在router.onReady的成功回调中，去找该url路由所匹配到的组件，获取异步数据那一套还和前面的一样。

于是，我们就完成了一个基本完整的基于Vue + VueRouter + VuexSSR配置，完成代码查看github。

最终效果演示：

访问http://localhost:3000/bar：

完整代码查看github

上面我们通过五个步骤，完成了从纯浏览器渲染到完整服务端渲染的同构，代码既可以运行在浏览器端，也可以运行在服务器端。那么，回过头来我们在看一下是否有优化的空间，又或者有哪些扩展的思考。

返回的值是 Node.js stream：

在流式渲染模式下，当 renderer 遍历虚拟 DOM 树(virtual DOM tree)时，会尽快发送数据。这意味着我们可以尽快获得"第一个 chunk"，并开始更快地将其发送给客户端。

然而，当第一个数据 chunk 被发出时，子组件甚至可能不被实例化，它们的生命周期钩子也不会被调用。这意味着，如果子组件需要在其生命周期钩子函数中，将数据附加到渲染上下文(render context)，当流(stream)启动时，这些数据将不可用。这是因为，大量上下文信息(context information)（如头信息(head information)或内联关键 CSS(inline critical CSS)）需要在应用程序标记(markup)之前出现，我们基本上必须等待流(stream)完成后，才能开始使用这些上下文数据。

因此，如果你依赖由组件生命周期钩子函数填充的上下文数据，则不建议使用流式传输模式。

webpack优化又是一个大的话题了，这里不展开讨论，感兴趣的同学可以自行查找一些资料，后续我也可能会专门写一篇文章来讲webpack优化。

答案是不用。Vuex只是为了帮助你实现一套数据存储、更新、获取的机制，入股你不用Vuex，那么你就必须自己想一套方案可以将异步获取到的数据存起来，并且在适当的时机将它注入到组件内，有一些文章提出了一些方案，我会放到参考文章里，大家可以阅读一下。

这个也是不一定的，任何技术都有使用场景。SSR可以帮助你提升首页加载速度，优化搜索引擎SEO，但同时由于它需要在node中渲染整套Vue的模板，会占用服务器负载，同时只会执行beforeCreate和created两个生命周期，对于一些外部扩展库需要做一定处理才可以在SSR中运行等等。

本文通过五个步骤，从纯浏览器端渲染开始，到配置一个完整的基于Vue + vue-router + Vuex的SSR环境，介绍了很多新的概念，也许你看完一遍不太理解，那么结合着源码，去自己手敲几遍，然后再来看几遍文章，相信你一定可以掌握SSR。

最后，本文所有源代码都放在我的github上，如果对你有帮助的话，就来点一个赞吧~~