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無法在用戶的瀏覽器中正常運行，會發生什麼？