Nuxt頁面級(jí)緩存的實(shí)現(xiàn)
雖然 Vue 的服務(wù)器端渲染 (SSR) 相當(dāng)快速,但是由于需要為每次請(qǐng)求為了避免交叉請(qǐng)求狀態(tài)污染,都創(chuàng)建一個(gè)新的根Vue實(shí)例,創(chuàng)建組件實(shí)例和虛擬 DOM 節(jié)點(diǎn)的開銷,無法與純基于字符串拼接的模板的性能相當(dāng)。在 SSR 性能至關(guān)重要的情況下,明智地利用緩存策略,可以極大改善響應(yīng)時(shí)間并減少服務(wù)器負(fù)載。同時(shí)還可以大大減少后端接口服務(wù)器的負(fù)載。
在 vue SSR指南 中,緩存有兩種,分為頁面級(jí)緩存和組件級(jí)緩存。本次講的是頁面緩存,如果內(nèi)容不是用戶特定的并且在相對(duì)較短時(shí)間內(nèi),頁面內(nèi)容不需要更新。我們就可以使用頁面緩存。對(duì)于頁面級(jí)緩存我們可以通過這段koa服務(wù)器的代碼大概知道緩存的思路:
const microCache = LRU({ max: 100, maxAge: 1000 // 重要提示:條目在 1 秒后過期。 }) const isCacheable = req => { // 實(shí)現(xiàn)邏輯為,檢查請(qǐng)求是否是用戶特定(user-specific)。 // 只有非用戶特定 (non-user-specific) 頁面才會(huì)緩存 } server.get('*', (req, res) => { const cacheable = isCacheable(req) if (cacheable) { const hit = microCache.get(req.url) if (hit) { return res.end(hit) } } renderer.renderToString((err, html) => { res.end(html) if (cacheable) { microCache.set(req.url, html) } }) })
流程圖如下:
上面的代碼為vue的ssr渲染提供了方案,但是對(duì)于使用nuxt框架的同學(xué)而言,用腳手架初始化完,框架對(duì)于vue服務(wù)端渲染的res.end()函數(shù)做了高度封裝,從下圖nuxt在接收到請(qǐng)求后進(jìn)行渲染的流程可以看出,nuxt主要是通過nuxtMiddleware調(diào)用renderRoute()來進(jìn)行渲染的:
那么我們是否可以通過重寫renderRoute()這個(gè)api攔截其內(nèi)部渲染邏輯,在渲染之前加上緩存呢? nuxt-ssr-cache 插件已經(jīng)這樣做了。我們來看一下這個(gè)nuxt模塊核心部分的源碼:
const renderer = nuxt.renderer; const renderRoute = renderer.renderRoute.bind(renderer); renderer.renderRoute = function(route, context) { // hopefully cache reset is finished up to this point. tryStoreVersion(cache, currentVersion); const cacheKey = (config.cache.key || defaultCacheKeyBuilder)(route, context); if (!cacheKey) return renderRoute(route, context); function renderSetCache(){ return renderRoute(route, context) .then(function(result) { if (!result.error) { cache.setAsync(cacheKey, serialize(result)); } return result; }); } return cache.getAsync(cacheKey) .then(function (cachedResult) { if (cachedResult) { return deserialize(cachedResult); } return renderSetCache(); }) .catch(renderSetCache); };
在這段代碼中,先保存了renderer原來的renderRoute代碼,之后又重寫了renderRoute代碼,返回了一個(gè)通過cache緩存來獲取緩存內(nèi)容的邏輯。cache返回了一個(gè)promise,如果是resolve的,并且有緩存的內(nèi)容,就直接返回緩存內(nèi)容。如果沒有緩存內(nèi)容或者reject,就執(zhí)行renderSetCache()。而renderSetCache()中,返回了原來最初的renderRoute()處理邏輯,同樣如果renderRoute()返回的promise被resolve了,那么就通過cache的setAsync方法來進(jìn)行緩存,之后返回渲染結(jié)果。
使用方法大家自行參考git中的readme文檔,這里就不說了。
下面我們真正來仿真一下,看看這個(gè)模塊的功效到底如何。我們通過ab命令
ab -n 4000 -c 50 -s 120 -r http://localhost:3000/
來進(jìn)行壓測(cè):
第一種情況,沒有添加頁面緩存,大約持續(xù)請(qǐng)求了10秒鐘,執(zhí)行到3600個(gè)請(qǐng)求的時(shí)候,發(fā)生錯(cuò)誤,不再繼續(xù)請(qǐng)求了:
我們來通過日志看下是什么錯(cuò)誤:
可以看到FATAL ERROR這一句,JavaScript heap out of memory。堆內(nèi)存已經(jīng)沒有辦法再進(jìn)行分配,所以進(jìn)程終止了。
我們?cè)诮K止之前通過進(jìn)程監(jiān)視器可以看到node進(jìn)程已經(jīng)彪到了1.7GB的內(nèi)存。
第二種情況,我們添加了頁面緩存,通過server端的日志,我們可以看出,只請(qǐng)求了一次后端的api數(shù)據(jù)接口,說明緩存已經(jīng)成功攔截了頁面請(qǐng)求。請(qǐng)求數(shù)據(jù)如下:
在2秒鐘之內(nèi),就順利結(jié)束了4000個(gè)請(qǐng)求,內(nèi)存沒有任何明顯波動(dòng),優(yōu)化效果顯而易見。
到此這篇關(guān)于Nuxt頁面級(jí)緩存的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)Nuxt 頁面級(jí)緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
解決vue做詳情頁跳轉(zhuǎn)的時(shí)候使用created方法 數(shù)據(jù)不會(huì)更新問題
這篇文章主要介紹了解決vue做詳情頁跳轉(zhuǎn)的時(shí)候使用created方法 數(shù)據(jù)不會(huì)更新問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-07-07VUE element上傳動(dòng)態(tài)設(shè)置action路徑和參數(shù)的坑及解決
這篇文章主要介紹了VUE element上傳動(dòng)態(tài)設(shè)置action路徑和參數(shù)的坑及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-07-07vue+tsc+noEmit導(dǎo)致打包報(bào)TS類型錯(cuò)誤問題及解決方法
當(dāng)我們新建vue3項(xiàng)目,package.json文件會(huì)自動(dòng)給我添加一些配置選項(xiàng),這寫選項(xiàng)基本沒有問題,但是在實(shí)際操作過程中,當(dāng)項(xiàng)目越來越復(fù)雜就會(huì)出現(xiàn)問題,本文給大家分享vue+tsc+noEmit導(dǎo)致打包報(bào)TS類型錯(cuò)誤問題及解決方法,感興趣的朋友一起看看吧2023-10-10Vue3.0中的monorepo管理模式的實(shí)現(xiàn)
這篇文章主要介紹了Vue3.0中的monorepo管理模式的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-10-10Mixin混入分發(fā)Vue組件可復(fù)用功能基礎(chǔ)示例
這篇文章主要為大家介紹了Mixin混入分發(fā)Vue組件可復(fù)用功能基礎(chǔ)示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-06-06