1. nuxt 部署上线
参考文章链接 ：
next.js、nuxt.js等服务端渲染框架构建的项目部署到服务器，并用PM2守护程序 - 每天一探 - SegmentFault 思否
1.安装NGINX
2.node
3.npm
4.pm2
5.将完成好的nuxt项目打包（npm run build）
.nuxt
static(可以不传)
nuxt.config.js
package.json
上传到服务器对应的文件夹下
运行npm install 安装package里的依赖
运行npm start 就可以运行起来nuxt的服务渲染了
6.配置NGINX
#nuxt config
upstream nodenuxt {
server 127.0.0.1:3000; #nuxt
keepalive 64;
}
server {
listen 3001 ;
server_name ****;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Nginx-Proxy true;
proxy_cache_bypass $http_upgrade;
proxy_pass http://nodenuxt; #
}
}
7.开启守护进程
2. nuxt - nuxtServerInit & 页面渲染前的store处理 & context
状态书文件中指定了nuxtServerInit方法，Nuxt,js调用它的时候会将页面的context上下文对象作为第2个参数传给它（服务端调用）[与fetch一样，不包括context.redirect和context.error方法]，当我们想要将服务端的一些数据传到客户端，可以通过这个获取保存在状态中，客户端再从状态里取
vue-cil 项目中通过localstorage或者cookie使vuex的状态持久化，因为vuex刷新后数据会丢失。
nuxt 项目中created钩子中不存在window对象（localstorage或者cookie的设置需要window对象），比如想要获取登录状态即判断是否存在token时，只能在mounted中进行操作，但这样又会引发一个问题，就是进页面的一瞬间还是无法得知登录状态，体验上会有影响，会存在显示用户名等组件显示隐藏延迟。
！！！ 这时候nuxt提供的fetch钩子和nuxtServerInit（均运行在服务端）起作用了，都能帮助我们在页面渲染（组件加载 ）前快速操作store。
3. NUXT项目打包优化策略
用nuxt开发完项目之后，开开心心打包扔上服务器准备收工，却没多久，测试童鞋遗憾的告诉我，压测50并发未通过。what？好吧。咱们再接下来老老实实的研究怎么压缩打包优化性能。
性能优化，无外乎那几个方案：文件压缩，文件缓存，CDN，DNS 预解析。。。
这里我们首先看一下不加任何优化的项目，打包后的分布：
这里能看到element-ui占了绝大部分的打包空间，是因为全局引入了element-ui，所以即使我们只使用了一部分的elemnt组件，但仍然把整个element给打包进来了。
所以这里有一个可以优化的点： 只引入element使用的组件，这样在打包的时候只需要打包使用的组件，体积就会减小很多 。
我们再来看看这么处理之后，我们打包出来的效果：
可以看出，我们减少了将近 400kb 的体积，效果十分显着。
好了，我又自信满满的把包丢到服务器上，准备金盆洗手。😎
然鹅没过多久，运维童鞋发过来一张图把我打回原点。
我看了一下vendor.app.js，足有501kb，难怪会阻塞🤷♀️好吧，这里应该使用上文件压缩这杆大枪了。
nuxt本身就是基于webpack的，正好安装compression-webpack-plugin来对文件进行压缩。
首先安装npm install compression-webpack-plugin
然后在nuxt.config.js中：
const CompressionPlugin = require('compression-webpack-plugin');
mole.exports={
build: {
plugins: [
new CompressionPlugin({
test: /\.js$|\.html$|\.css/, // 匹配文件名
threshold: 10240, // 对超过10kb的数据进行压缩
deleteOriginalAssets: false // 是否删除原文件
})
],
}
}
这样打包出来的大小虽然没变，但是点击.nuxt-dist-client中你会发现
观察发现gz打包后，较原来的文件减少了3/4的体积。有了这些gz后缀的文件，再配合nginx打开gzip服务。我想这回应该可以冲过50并发了吧，说不定200并发都没问题🤩🤩🤩
好了，我这回真的自信满满的把包丢到服务器上，通知测试童鞋再次压测，果不其然，测试童鞋过了一会回复：50并发跑5次无异常。😎😎我大气说，上100！我翘着得意的二郎腿，等着好消息再次到来。过了一会，果不其然！测试童鞋告诉我，100并发阻塞。原因同上，出在了vendor.app.js上😭
这里我说一下vendor.app.js打包之后的体积是144kb。然鹅在高并发下，表现还是不理想，于是乎我只能上网去到处搜索解决方案，毕竟po主的webpack知识也就那么一勺水的深度🤷♀️🤷♀️
这里还真让我找到了一个台湾的网站，可见参考链接第三条。
splitChunks: 设定 Chunks 的最大和最小 size。
在nuxt.config.js中加入：
mole.exports={
build: {
optimization: {
splitChunks: {
minSize: 10000,
maxSize: 250000
}
},
}
}
打包，观察打包结果：
可以看到虽然包体积虽然没变，但是像vendor.app.js这种单个体积大的被拆分成n个体积小的文件了。
这回终于是可以突破100并发5次无异常，达成并发要求了🎉🎊🎉🎊
总结一下，其实po主也不是什么webpack大神，也是摸爬滚打整出来的，大家如果能有什么更好的优化建议或者指教，请多多交流，不对之处我会改正！
参考：
Nuxt 项目性能优化调研
NUXT项目的性能优化
SplitChunks & Lodash & Vuetify tree shaking
4. nuxt 如何预加载大图片
图片预加载的主要思路就是把稍后需要用到的图片悄悄的提前加载到本地，因为浏览器有缓存的原因，如果稍后用到这个url的图片了，浏览器会优先从本地缓存找该url对应的图片，如果图片没过期的话，就使用这个图如下是摘录具体的实现思路《javascript图片预加载详解》图片的加载速度往往影响着网站整体的用户体验，尤其对于包含大量图片的网站。对图片进行预加载，不失为一个高效的解决方案。如何实现预加载？本文将例举利用CSS、JavaScript及ajax实现图片预加载的三大方法。
Perishable Press网站近日发表了一篇文章《3 Ways to Preload Images with CSS, JavaScript, or Ajax》，分享了利用CSS、JavaScript及Ajax实现图片预加载的三大方法。下面为译文。
预加载图片是提高用户体验的一个很好方法。图片预先加载到浏览器中，访问者便可顺利地在你的网站上冲浪，并享受到极快的加载速度。这对图片画廊及图片占据很大比例的网站来说十分有利，它保证了图片快速、无缝地发布，也可帮助用户在浏览你网站内容时获得更好的用户体验。本文将分享三个不同的预加载技术，来增强网站的性能与可用性。
方法一：用CSS和JavaScript实现预加载
实现预加载图片有很多方法，包括使用CSS、JavaScript及两者的各种组合。这些技术可根据不同设计场景设计出相应的解决方案，十分高效。
将这三个ID选择器应用到(X)html元素中，我们便可通过CSS的background属性将图片预加载到屏幕外的背景上。只要这些图片的路径保持不变，当它们在web页面的其他地方被调用时，浏览器就会在渲染过程中使用预加载（缓存）的图片。简单、高效，不需要任何JavaScript。
该方法虽然高效，但仍有改进余地。使用该法加载的图片会同页面的其他内容一起加载，增加了页面的整体加载时间。
在该脚本的第一部分，我们获取使用类选择器的元素，并为其设置了background属性，以预加载不同的图片。
该脚本的第二部分，我们使用addLoadEvent()函数来延迟preloader()函数的加载时间，直到页面加载完毕。如果JavaScript无法在用户的浏览器中正常运行，会发生什么？