当前，SPA越来越无法满足业务对页面响应速度的要求。随着工程不断变大，打包文件不断增长，页面的整体刷新加载速度慢慢成为瓶颈。
越来越多的应用开始使用SSR来提高响应速度。本文下面会对Vue SSR框架NUXT的处理流程，进行描述和说明。
一，SSR与SPA的区别
在谈NUXT前，我们得先了解一下什么是SSR。
SSR是英文server side render的缩写，即服务端描画。
之前在SPA单页的时候，mouted元素部分，都是先去服务端拉取js脚本，然后客户端解析成html。而在SSR下，mouted部分是服务端描画好后，直接发送到客户端，客户端不用进行html的重新组合，只需要激活即可。
红色字体部分可以看到，只是响应了主体，而真正的内容部分需要去下载js，然后客户端绘制出来再展示，哪这样会有什么问题呢？对！白屏时间过长。虽然现在有骨架技术，也就是在响应的html主体中，填充静态内容，但也是治标不治本。
我们再看一下SSR的方式：
从图上可以看到，服务端返回的是完整的解析内容可以直接呈现在用户面前。但这都是静态的，要动态化，就需要有一步激活的操作。
这就是SPA与SSR两者的区别。哪Nuxt.js是什么呢？
二，Nuxt.js
Nuxt.js 是一个基于 Vue.js 的通用应用框架。
通过对客户端/服务端基础架构的抽象组织，Nuxt.js 主要关注的是应用的UI渲染。
它既支持预渲染也支持SSR。SPA不是本文重点，今天我们重点说一下Nuxt的SSR部分。
相关部分的命令分2个
npm run dev（开发环境）
npm run build + npm run start（生产环境）
我们先看一张流程图：
从图上我们可以看到，开发和生产环境比，多了一步文件修改的监听。这也是为什么我们在开发过程中，修改代码后，页面可以立即产生变化。当然监听到文件变化后，还会有一系列的操作。
三，编译与启动
先看编译的过程，如下图
首先先加载nuxt.config.js，
然后初始化nuxt，builder，开始执行构建。
准备模板使用的参数，然后根据模板生成真正的webpack编译的js
分别执行客户端编译和服务端编译，生成最终的js脚本
编译成功后，就需要启动服务，监听端口，这个是在npm run start中实现的。如下图
启动后，加载配置文件
初始化Nuxt
对端口进行监听。
如果有请求进来，第一次会加载拦截器，然后拦截器会对请求进行区分拦截。
比如：如果是访问的静态文件，那么会有staticServer来处理。
如果是路由匹配的请求，那么nuxtMiddleware会进行接受，然后通过VUE的SSR插件，去绘制响应的html
四,SSR的使用场景以及缺点
SSR的优点无非两个，一个是对SEO友好，二就是更快的内容到达时间。
所以在使用SSR的第一个场景，必然是对响应速度有较高的要求
但同时也会有更高的瓶颈点和风险。主要有下面几个：
更长的链路，之前是浏览器+nginx+后台服务，而现在就变成浏览器+nginx+nodejs+后台服务。
nodejs中的阻塞型请求，容易成为性能的瓶颈。
一套api，要考虑前后端的兼容性
对业务开发人员来说，曲线变长，需要能明确代码在前后端的执行位置
结语
本文简单介绍了SSR以及NUXT的处理流程，希望对刚开始接触SSR的前端，能有所帮助。里面都是个人见解，如有不准确，欢迎批评指正。
