## 为什么要做 ssr

- 有利于 seo
- 秒开首屏
- 提高用户体验
- 降低代码复杂度？

### seo 优化方案

1. SSR 服务器渲染
2. 静态化
3. 预渲染 prerender-spa-plugin
4. 使用 Phantomjs 针对爬虫做处理

## 理解

webapck 配置、路由、项目目录结构、动态加载以及更细化的 babel、postcss 配置等，这类东西用户定制化程度高，应该将权利给予用户去做，框架不应该承担这种多样化的东西，无论是使用 next 还是北斗等，都对以上有侵入性的改变且使用起来过重，对于大型项目，这些东西不应该被限制，如果你不是一开始就使用它们，迁移成本会很高  
但其实我们想要的只是核心渲染，路由、项目结构、配置这些你可以提供但不能限制我的发挥！

### next issue 统计

截止到 2018 年 12 月 14 日，针对 next issue 相关关键字的统计分析，可以看出 webpack 和 babel 相关的 issue 占比很高，很容易明白其中的原因，这类东西用户定制化程度很高，next 提供的配置无法覆盖所有情况，真实的配置只有用户自己最清楚，且最终的配置修改权在用户手中，有时候可能用户都不知道是修改了哪行关键配置导致 next 跑不起来，也很难排查解决

| 关键词  | Open | Closed |
| ------- | ---- | ------ |
| -       | 290  | 3084   |
| webpack | 95   | 1030   |
| babel   | 60   | 870    |

## 目标

我的初衷是用最小代价的引入 ssr，让开发者无感切入，遵从一点约束，不用改动 webpbak、babel 配置，及业务代码  
且客户端能跑，服务端也能跑，即使不开启 ssr，可随时关闭 ssr，如同开关一样  
对基于 react 和 webpack 的项目做服务端渲染时提供支持

### 想法

为什么要自己撸一套 ssr，写逻辑哪有造轮子好玩？  
我就只是想访问页面时服务器端返回一下渲染好的页面，之后正常走客户端逻辑，为何要我作出这么多改变  
这个问题是什么原因啊，只有看了源码后才知道，文档竟然也没说明  
为何开发体验这么差，开发模式打包速度如此的慢

### 用户使用

用户使用我提供的 webpack 函数传入自己的 webpack 配置，这里我会更改用户 webpack 的关键配置，以支持 ssr，用户无感且无权介入  
用户通过中间的形式引入 ssr 中件间服务  
用户自由开启 webpack 和 koa 服务，我并不提供启动运行命令  
把这些自由的操作都交给用户，webpack、babel、服务、cli、文件结构等

### 资源引用

返回渲染的 html 模版来自 html-webpack-plugin 插件生成的 html 文件，我在此基础上加工  
资源通过介入的 webpack 插件打出的资源清单以分析出依赖关系，同时供服务端和客户端使用  
编写 node 端 webpack 运行时，处理 webpack 打包的 chunk 文件和模块加载，收集当前页面需要的资源，服务端 require 导入，客户端通过在生成 html 时将用到的 chunk 注入到 html 中