成也萧何,败也萧何

你为什么要选择SPA?难道就因为交互体验比传统多页更友好嘛?是的,你说的没错。对于用户来讲,响应时间、交互体验更加友善,对于开发者来说,前后端分离的开发模式大大降低了开发成本,这已经完全可以构成放弃SSR的理由了。

如果一切顺利,本文就没有出现的必要了。你猜的没错,我要说但是了!但是,SPA有一个致命的缺陷,就是对搜索引擎不友好,不利于爬虫爬取数据。有人要问了,不利于爬虫不是好事嘛?难道你还想让别人爬你的数据嘛?你咋不上天呢?搜索引擎不爬虫鬼知道你的网站是什么,你靠什么做SEO?靠砸钱嘛?好像也可以..

用户就是爸爸,如果你拥有大量的用户,哪怕你像拼多多一样还亏着十几个亿,也照样可以申请上市!得用户者得天下!如果你不愿意花大价钱去做SEO,那么还是老老实实地想想怎么优化你的SPA吧。

那么什么对搜索引擎和爬虫友好呢?答案就是静态页面,而非浏览器渲染,这就需要服务器直接渲染,也就是所谓的SSR(Server Side Render)

壮士,干了这一杯SSR

SSR,服务器渲染,简单来说就是将每个要展示的页面运行完成后,将整个相应流传送给浏览器,所有的运算都在服务器端完成,浏览器只需要无脑解析HTMl就行。传统的SSR包含哪些?ASP?EJS?JSP?请不要再说了,我想我会永远记得被模板语言支配的恐惧。当用模板语言作为前端开发语言时,至少我是没办法静下心来去美化页面优化交互体验的,所有的精力都花在了业务逻辑上,对于页面的布局毫不关心,如果一定要用一个标准去衡量,那就是,能看就行。

那么到底该如何着手将项目改造成SSR呢?我可不想继续写恐怖的模板语言。Vue2.0中有一章是关于SSR的,可以在无须大幅修改原先代码的情况下做到SSR,又不失单页应用良好的体验。听上去是不是很酷,我们来看看怎么实现吧。

SSR架构

一个普通的单页应用通常通过webpack把源代码打包后插入到html中,当页面请求时,返回html再加载打包后的js文件,也就是下图的Application Code、Webpack build和browser三个部分。

SSR架构图简介:将 Source(源码)通过 webpack 打包出两个 bundle,其中 Server Bundle 是给服务端用的,服务端通过渲染器 bundleRenderer 将 bundle 生成 html 给浏览器用;另一个 Client Bundle 是给浏览器用的,别忘了服务端只是生成前期首屏页面所需的 html ,后期的交互和数据处理还是需要能支持浏览器脚本的 Client Bundle 来完成。

image

server entry & client entry

Server entry 和 Client entry对应的是webpack.config中的entry,即打包入口文件,也就是分别代表服务器端所运行代码的入口和浏览器端所运行代码的入口文件。

1
2
server entry: 根据路由状态,返回渲染完成后相应的组件
client entry: 将应用直接挂在到DOM上
Webpack build

既然有了不同的entry,打包自然也就需要两套配置。client端的配置文件本来就有,也并不需要修改。唯一需要增加的,就是server端的配置文件。而server端的配置文件,也可以照抄客户端的配置,改改entry和output就可以了。但是一定要注意,把target属性设置为node。收工完成,得到了server bundle和client bundle。

bundle renderer

到这里需要用到vue为支持ssr所依赖的库:vue-server-renderer。通过vue-server-renderer提供的api很容易地根据url生成对应的目录树,然后将它返回给客户端。因为用的是webpack,所以只能用createBundleRenderer而不能用createRenderer来创建randerer。

老师,我要看DEMO

DEMO Time:https://juejin.im/post/5a9ca40b6fb9a028b77a4aac