性能優(yōu)化，這是面試中經(jīng)常會聊到的話題。我覺得性能優(yōu)化應(yīng)該因具體場景而異，因不同項(xiàng)目而異，不同的手段不同的方案并不一定適合所有項(xiàng)目，當(dāng)然這其中不乏一些普適的方案，比如耳熟能詳?shù)奈募嚎s，文件緩存，CDN，DNS 預(yù)解析，等等，但是我更希望聽到的是因?yàn)椴煌捻?xiàng)目不同的需求，解決不同的問題而采取的不同的優(yōu)化手段，比如 BigPipe，分段輸出頁面的各個部分，對于 SNS 網(wǎng)站是非常合適的，減少了用戶的等待時間；相對應(yīng)的還有一個 BigRender，這是一個大的延遲加載，360 導(dǎo)航首頁目前還在使用，京東淘寶首頁也是這個思路，對于一些類門戶網(wǎng)站非常適用，但是如果你的網(wǎng)頁內(nèi)容不是非常多，就沒有必要了

今天要說的是 Nuxt。Nuxt 是支持 Vue SSR 的一個框架，底層需要運(yùn)行 Node 服務(wù)。大概描述一下 Vue 的渲染過程，首先每個組件都會被編譯生成一個渲染函數(shù)（這部分基本 webpack 打包已經(jīng)做掉），然后渲染函數(shù)生成虛擬 dom，最后虛擬 dom 通過 patch 方法將真實(shí) dom 渲染到頁面上。Nuxt 其實(shí)就是將這部分放到了服務(wù)端去做，在服務(wù)端拿到渲染頁面所需要的 html，從而使得 html 能夠直出，而客戶端其實(shí)還是會運(yùn)行整個 Vue 的生命周期，這就帶來了一個問題，這部分操作放在了服務(wù)端其實(shí)是非常耗 cpu 的，創(chuàng)建組件實(shí)例和虛擬 DOM 節(jié)點(diǎn)的開銷，無法與純基于字符串拼接的模版的性能相當(dāng)，如果是不加優(yōu)化的 Nuxt 項(xiàng)目，高并發(fā)下是很脆弱的，畢竟 Node 運(yùn)行在單線程下，不適合 cpu 操作密集型的場景

使用 Nuxt 的項(xiàng)目無非看中了它的兩大優(yōu)點(diǎn)，一是服務(wù)端渲染滿足 SEO 的需求，二是首屏直出比 SPA 快，再加上如果如果公司是 Vue 系，使用 Nuxt 就更順理成章。但是不要忘了性能，高并發(fā)下 Nuxt 性能確實(shí)不樂觀，我測試了官網(wǎng)的 hackernews demo 項(xiàng)目，2 核 cpu + 4g 內(nèi)存，400 并發(fā)下它的吞吐量不超過 50，就算是最簡的 Nuxt 項(xiàng)目，吞吐量也就 300+，這就說明如果項(xiàng)目不做緩存，300+ 已經(jīng)是最大的吞吐量了，而最小 express demo 可以輕松到 3000，這就決定了高流量項(xiàng)目并不會輕易去使用 Nuxt

我們的項(xiàng)目目前其實(shí)是一個不加優(yōu)化的 Nuxt 項(xiàng)目，因?yàn)橛脩舨欢啵綍r并沒有什么問題，但是一到展會，就會有不少用戶同時訪問，反饋頁面會很卡。同條件下做了壓測后，吞吐量也是 50 上下，平均響應(yīng)時長七八秒，所以卡是正?，F(xiàn)象

看了一下項(xiàng)目代碼，發(fā)現(xiàn)了幾個問題：

項(xiàng)目沒做緩存，所以每次訪問都會經(jīng)歷所有 Nuxt 生命周期，消耗 cpu，這點(diǎn)是最致命的

項(xiàng)目打包默認(rèn) gzip。Nuxt 項(xiàng)目打包會默認(rèn)在服務(wù)端開啟 gzip，因?yàn)槲覀兙W(wǎng)關(guān)層已經(jīng)做了 gzip，所以這里是不必要的，測試了下關(guān)掉 gzip 吞吐量和響應(yīng)時間都能提高 20% 左右。具體做法是在 nuxt.config.js 中配置（還是得看 英文文檔，會告訴你如何不設(shè)置 To disable compression, use compressor: false，中文文檔當(dāng)時三月份我寫這文的時候還沒加這個選項(xiàng)，而目前中文文檔也沒有翻譯這一句 2020-07-16）

render: {
 compressor: false
}

API 請求比較亂。很多請求并沒有很好地區(qū)分客戶端和服務(wù)端，而是都由服務(wù)端去做了，造成服務(wù)端壓力過大，其實(shí)多數(shù)和用戶有關(guān)的請求理應(yīng)放到客戶端。有的接口為了方便，一次性返回了所有內(nèi)容，也沒有做客戶端/服務(wù)端區(qū)分。另外，服務(wù)端的接口請求可以并發(fā)，用類似 Promise.all 的形式去控制

SEO。有的內(nèi)容頁面，很長，有五個部分，除了內(nèi)容外，還有猜你喜歡等其他部分，詢問了 SEO 同事，說這幾部分都是需要 SEO 的，我不是很懂 SEO，但是在我看來，ssr 只應(yīng)該渲染首屏內(nèi)容，而 UI 在設(shè)計(jì)的時候應(yīng)該把主要內(nèi)容設(shè)計(jì)到首屏，從而滿足 SEO

對此我覺得可以從兩個方向去優(yōu)化：

緩存。緩存是最重要的方案，針對 Nuxt 項(xiàng)目可以做三級緩存，頁面緩存、組件緩存以及 API 緩存。頁面緩存是最重量級的緩存方案，能不能做頁面緩存可以從以下兩個點(diǎn)判斷：

同一個 URL，對于 登錄 / 非登錄 用戶，服務(wù)端渲染的內(nèi)容是相同的（注意是服務(wù)端渲染內(nèi)容，而非前端）

同一個 URL，對于不同的登錄用戶，服務(wù)端渲染的內(nèi)容是相同的，即沒有一些個性化的渲染（常見的個性化渲染，比如針對不同用戶渲染不同的猜你喜歡內(nèi)容等）

其實(shí)也就是返回的 html 代碼相同就好，主要關(guān)注下返回的全局 store 是否一致，另外也不能做一些服務(wù)端才能做的操作，比如 set-cookie 等

控制好首屏模塊個數(shù)，對返回的結(jié)果進(jìn)行精簡，最小化，保證吐出到瀏覽器的內(nèi)容足夠小。這就是前面說的并不要對所有模塊都做 ssr，需要首屏呈現(xiàn)的/需要爬蟲爬的，我們直出，其他部分做 CSR 就行了

而我們的網(wǎng)站大部分頁面是滿足做頁面緩存條件的，測試了下如果做頁面緩存，吞吐量能到 500+，這個數(shù)據(jù)這個時候其實(shí)是和頁面大小有關(guān)系了，頁面緩存的性能是能滿足需求的。而有另一類頁面，相同的 URL 會返回不同的內(nèi)容，而且整頁都是不同內(nèi)容，它的實(shí)現(xiàn)是獲取 cookie 中的不同 city-id，渲染不同城市的內(nèi)容，很顯然這部分頁面做不了頁面緩存了，API 緩存和組件緩存理論上都是可以試試的

做緩存優(yōu)化，至少需要訪問一次，第二次才能生效，那么還有另一種情況，對于這樣的路由 /store/:id，并發(fā)打開 id 0～1000，很顯然每個頁面都是不一樣的店鋪數(shù)據(jù)，并不能命中緩存（可能命中組件緩存，暫時忽略），這個時候只能從 Nuxt 生命周期上去優(yōu)化了，那么以上方向的第二點(diǎn)，控制首屏模塊個數(shù)就能用到了。所以本文一開始我就說，不同的方案是適配不同的場景的，解決不同的問題會采取不同的手段

補(bǔ)充知識：Nuxt實(shí)現(xiàn)的SSR頁面性能優(yōu)化的進(jìn)一步探索與實(shí)踐

前言

本文之前，先簡單介紹以下幾個概念:

SSR指服務(wù)端渲染，即頁面是通過服務(wù)端渲染生成后返回給客戶端的，SSR主要為了提高頁面加載速度，改善用戶體驗(yàn)，也可用于SEO搜索引擎優(yōu)化。

Nuxt.js 官方定義： Nuxt.js 是一個基于 Vue 的通用應(yīng)用框架。 通過對客戶端/服務(wù)端基礎(chǔ)架構(gòu)的抽象組織，Nuxt.js 主要關(guān)注的是應(yīng)用的 UI渲染。我們的目標(biāo)是創(chuàng)建一個靈活的應(yīng)用框架，你可以基于它初始化新項(xiàng)目的基礎(chǔ)結(jié)構(gòu)代碼，或者在已有 Node.js 項(xiàng)目中使用 Nuxt.js。

個人理解：Nuxt.js 就是預(yù)設(shè)了開發(fā)服務(wù)端渲染應(yīng)用所需要的各種配置, 使用 Webpack 和 Node.js 進(jìn)行封裝的基于Vue的SSR框架。

背景

我們部門從事的都是面對用戶的業(yè)務(wù)需求開發(fā)，面對用戶，意味著對頁面的體驗(yàn)要求會更高，最直觀體驗(yàn)是頁面首屏的加載速度，加載速度優(yōu)化是我們體驗(yàn)優(yōu)化的長期、重要的一部分；本文的起源正是首屏加載速度優(yōu)化。

頁面加載速度優(yōu)化的核心包括三點(diǎn)：減少資源文件的請求數(shù)量；減小每個資源文件的大??；提高每個資源的加載速度；

諸如合并API訪問，壓縮混淆文件，支持webp圖片，資源cdn緩存等等常用辦法，都是以上面三個核心為出發(fā)點(diǎn)的； 這些常用辦法基本都可以通過webpack配置，公司基礎(chǔ)服務(wù)，代碼較小的變更完成。

我們負(fù)責(zé)的各主流量入口頁面，已基本做過以上常用的優(yōu)化，但由于主入口頁面資源量較大的原因，優(yōu)化后并不能達(dá)到預(yù)期的效果，我們需要探索其它優(yōu)化方案。 我們快速想到了用SSR的方案進(jìn)一步解決加載速度問題，從零開始的搭建服務(wù)端渲染應(yīng)用相當(dāng)復(fù)雜，肯定會涉及到服務(wù)端的開發(fā)，作為獨(dú)立的前端團(tuán)隊(duì)，成本較高昂； 我們決定嘗試是否能找到一種成本較低的現(xiàn)有SSR框架，以達(dá)到目的；

因主入口頁面技術(shù)棧為vue，方案調(diào)研中自然而然的看到了Nuxt.js此種基于Vue的SSR框架； Nuxt.js和項(xiàng)目技術(shù)棧匹配度急高，學(xué)習(xí)成本極低，自然成為我們的第一選擇；

我們引入Nuxt.js，最初只是利用了服務(wù)端異步獲取API接口數(shù)據(jù)和服務(wù)端渲染兩項(xiàng)功能，去重構(gòu)了我們的項(xiàng)目，重構(gòu)后效果基本達(dá)到我們的預(yù)期，正常網(wǎng)絡(luò)狀態(tài)下，基本可以達(dá)到秒開； 入口頁面，團(tuán)隊(duì)是作為一個長期的項(xiàng)目進(jìn)行不定期優(yōu)化的，我們逐步圍繞Nuxt.js框架，對項(xiàng)目做了進(jìn)一步優(yōu)化升級，本文主要介紹我們Nuxt.js頁面優(yōu)化的進(jìn)一步探索與實(shí)踐； 至于如何搭建初步的Nuxt項(xiàng)目，需要感興趣的各位自行查看官方文檔及自我實(shí)踐了，本文不做贅述。

探索與實(shí)踐

我們主要的探索與實(shí)踐可行方向主要有兩個：

一、Nuxt.js特性合理應(yīng)用

應(yīng)用到的特性主要包括asyncData異步獲取數(shù)據(jù)、mounted不支持服務(wù)端渲染、no-ssr組件不在服務(wù)端渲染中呈現(xiàn)；

通過相關(guān)特性做到API數(shù)據(jù)和頁面結(jié)構(gòu)合理拆分，首屏所需數(shù)據(jù)和結(jié)構(gòu)通過服務(wù)端獲取并渲染，非首屏數(shù)據(jù)和結(jié)構(gòu)通過客戶端獲取并渲染。

示例代碼：

no-ssr結(jié)構(gòu)拆分

<template> 
 <div> 
 <!-- 頂部banner --> 
 <banner :banner="banner" /> 
 <!-- 非首屏所需結(jié)構(gòu)，通過no-ssr組件達(dá)到不在服務(wù)端渲染目的--> 
 <no-ssr> 
  <!-- 商品列表 --> 
  <prod-list :listData="listData"/> 
 </no-ssr> 
 </div> 
</template>

API數(shù)據(jù)拆分

export default { 
 async asyncData({ app, query }) { 
 try { 
  // 獲取頁面頂部輪播圖信息 
  const getBanner = () => { 
  return app.$axios.$get('zz/zy/banner') 
  } 
  // 獲取底部配置信息 
  const getFooter = () => { 
  return app.$axios.$get('zz/zy/footer', { 
   params: { 
   smark: query.smark 
   } 
  }) 
  } 
  // 并發(fā)獲取首屏數(shù)據(jù)，服務(wù)端獲取 
  const [banner, footer] = await Promise.all([getBanner(), getFooter()]) 
  return {banner: banner, footer: footer} 
 } catch (e) { 
  console.log('interface timeout or format error => ', e) 
  return {} 
 } 
 }, 
 mounted() { 
 // 非首屏使用的數(shù)據(jù), 客戶端獲取 
 this.loadListData() 
 }, 
 methods: { 
 loadListData() { 
  this.$axios.$get('zz/zy/list').then(() => { 
  // 數(shù)據(jù)處理邏輯 
  }) 
 } 
 } 
}

二、服務(wù)端引入緩存

服務(wù)端開發(fā)意味著緩存可作為性能優(yōu)化的最直接法門，Nuxt.js作為一種服務(wù)端渲染框架，也不例外；針對不同的頁面，不同的數(shù)據(jù)狀態(tài)，可主要區(qū)分為下面三類緩存：

1、API接口數(shù)據(jù)緩存

將服務(wù)端獲取的數(shù)據(jù)，全部緩存到node進(jìn)程內(nèi)存中，定時刷新，有效期內(nèi)請求都通過緩存獲取API接口數(shù)據(jù)，減小數(shù)據(jù)獲取時間；

此種緩存適用于緩存的部分API數(shù)據(jù)，基本保持不變，變更不頻繁，與用戶個人數(shù)據(jù)無關(guān)。

示例代碼：

 import LRU from 'lru-cache' 
 const CACHED = new LRU({ 
 max: 100, // 緩存隊(duì)列長度 
 maxAge: 1000 * 60 // 緩存時間 
 }) 
 export default { 
 async asyncData({ app, query }) { 
  try { 
  let banner, footer 
  if (CACHED.has('baseData')) { 
   // 存在緩存，使用緩存數(shù)據(jù) 
   let data = CACHED.get('baseData') 
   data = JSON.parse(data) 
   banner = data.banner 
   footer = data.footer 
  } else { 
   // 獲取頁面頂部輪播圖信息 
   const getBanner = () => { 
   return app.$axios.$get('zz/zy/banner') 
   } 
   // 獲取底部配置信息 
   const getFooter = () => { 
   return app.$axios.$get('zz/zy/footer', { 
    params: { 
    smark: query.smark 
    } 
   }) 
   } 
   [banner, footer] = await Promise.all([getBanner(), getFooter()]) 
   // 將數(shù)據(jù)寫入緩存 
   CACHED.set('baseData', JSON.stringify({ banner: banner, footer: footer})) 
  } 
  return {mods: mods, footer: footer} 
  } catch (e) { 
  console.log('interface timeout or format error => ', e) 
  return {} 
  } 
 } 
 }

2、組件級別緩存

將渲染后的組件DOM結(jié)構(gòu)存入緩存，定時刷新，有效期通過緩存獲取組件DOM結(jié)構(gòu)，減小生成DOM結(jié)構(gòu)所需時間；

適用于渲染后結(jié)構(gòu)不變或只有幾種變換、并不影響上下文的組件。

示例代碼：

nuxt.config.js配置項(xiàng)修改

const LRU = require('lru-cache') 
module.exports = { 
 render: { 
 bundleRenderer: { 
  cache: LRU({ 
  max: 1000, // 緩存隊(duì)列長度 
  maxAge: 1000 * 60 // 緩存1分鐘 
  }) 
 } 
 } 
}

需要做緩存的 vue 組件， 需增加 name 以及 serverCacheKey 字段，以確定緩存的唯一鍵值。

export default { 
 name: 'zzZyHome', 
 props: ['type'], 
 serverCacheKey: props => props.type 
}

如果組件依賴于很多的全局狀態(tài)，或者狀態(tài)取值非常多，緩存會因頻繁被設(shè)置而導(dǎo)致溢出，這樣的組件做緩存就沒有多大意義了；

另外組件緩存，只是緩存了dom結(jié)構(gòu)，如created等鉤子中的代碼邏輯并不會被緩存，如果其中邏輯會影響上下邊變更，是不會再執(zhí)行的，此種組件也不適合緩存。

3、頁面整體緩存

當(dāng)整個頁面與用戶數(shù)據(jù)無關(guān)，依賴的數(shù)據(jù)基本不變的情況下，可以對整個頁面做緩存，減小頁面獲取時間;

頁面整體緩存前提是在使用Nuxt.js腳手架工具create-nuxt-app初始化項(xiàng)目時，必須選擇集成服務(wù)器框架，如express、koa，只有這樣才具有服務(wù)端中間件擴(kuò)展的功能。

示例代碼：

服務(wù)端中間件middleware/page-cache.js

const LRU = require('lru-cache') 
let cachePage = new LRU({ 
 max: 100, // 緩存隊(duì)列長度 
 maxAge: 1000 * 60 // 緩存1分鐘 
}) 
export default function(req, res, next){ 
 let url = req._parsedOriginalUrl 
 let pathname = url.pathname 
 // 通過路由判斷，只有首頁才進(jìn)行緩存 
 if (['/home'].indexOf(pathname) > -1) { 
 const existsHtml = cachePage.get('homeData') 
 if (existsHtml) { 
  return res.end(existsHtml.html, 'utf-8') 
 } else { 
  res.original_end = res.end 
  // 重寫res.end 
  res.end = function (data) { 
  if (res.statusCode === 200) { 
   // 設(shè)置緩存 
   cachePage.set('homeData', { html: data}) 
  } 
  // 最終返回結(jié)果 
  res.original_end(data, 'utf-8') 
  } 
 } 
 } 
 next() 
}

nuxt.config.js配置項(xiàng)修改，引入服務(wù)端中間件

//針對home路由做緩存 
serverMiddleware: [ 
 { path: '/home', handler: '~/middleware/page-cache.js' }, 
]

總結(jié)

本文主要是針對Nuxt.js框架實(shí)現(xiàn)的頁面，性能優(yōu)化方案進(jìn)一步探索和實(shí)踐的總結(jié)，匯總一些思路與方向；期望各位小伙伴在其它SSR相關(guān)頁面優(yōu)化過程中，能起到一定的啟發(fā)作用。

以上這篇Nuxt 項(xiàng)目性能優(yōu)化調(diào)研分析就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。