nuxt 是基于 vue 的 ssr 解决方案，可以是使用vue语法完成前后端的同构。
然而在与传统纯字符串拼接的 ssr 方案相比，性能就没那么好了， nuxt 需要在服务端生成虚拟 dom ，然后再序列化出HTML字符串，我们常说 nodejs 的高性能指的是异步IO操作频繁的场景而非CPU操作密集的场景，毕竟 nodejs 是运行在单线程下的，在涉及到高并发的场景下，性能就会有所下降，可以考虑采用合理的缓存策略
nuxt 的缓存可以分为 组件级别缓存 , API级别缓存 以及 页面级别缓存
组件级别的缓存
配置项
nuxt.config.js 的配置大概长这样子:
const LRU = require('lru-cache')
module.exports = {
render: {
bundleRenderer: {
cache: LRU({
max: 1000, // 最大的缓存个数
maxAge: 1000 * 60 * 15 // 缓存15分钟
})
}
}
}
并不是说配了该项就实现了组件级别的缓存，还需要在需做缓存的 vue 组件上增加
name 以及
serverCacheKey 字段，以确定缓存的唯一键值，比如：
export default {
name: 'AppHeader',
props: ['type'],
serverCacheKey: props => props.type
}
上述组件会根据父组件传下来的 type 值去做缓存，键值是：
AppHeader::${props.type} ，由此，新的请求到来时，只要父组件传下来的 type 属性之前处理过，就可以复用之前的渲染缓存结果，以增进性能从该例子可以看出，如果该组件除了依赖父组件的
type 属性，还依赖于别的属性，
serverCacheKey 这里也要做出相应的改变，因此，如果组件依赖于很多的全局状态，或者，依赖的状态取值非常多，意味需要缓存会被频繁被设置而导致溢出，其实就没有多大意义了，在
lru-cache 的配置中，设置的最大缓存个数是1000，超出部分就会被清掉其次，不应该缓存可能对渲染上下文产生副作用的子组件，比如，组件的
created 与
beforeCreated 的钩子在服务端也会走，组件被缓存后就不会执行了，这些可能影响到渲染上下文的地方也要小心，更多内容请参考：组件级别缓存一般来说，比较适合的场景是 v-for 大量数据的渲染，因为循环操作比较耗cpu
API级别的缓存
在服务端渲染的场景中，往往会将请求放在服务端去做，渲染完页面再返回给浏览器，而有些接口是可以去做缓存的，比如，不依赖登录态且不依赖过多参数的接口或者是单纯获取配置数据的接口等，接口的处理也是需要时间的，对接口的缓存可以加快每个请求的处理速度，更快地释放掉请求，从而增进性能
