一個(gè)基于 Vue.js 的通用應(yīng)用框架 Nuxt.js 簡(jiǎn)介
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
當(dāng)前,SPA越來(lái)越無(wú)法滿足業(yè)務(wù)對(duì)頁(yè)面響應(yīng)速度的要求。隨著工程不斷變大,打包文件不斷增長(zhǎng),頁(yè)面的整體刷新加載速度慢慢成為瓶頸。 越來(lái)越多的應(yīng)用開始使用SSR來(lái)提高響應(yīng)速度。本文下面會(huì)對(duì)Vue SSR框架NUXT的處理流程,進(jìn)行描述和說(shuō)明。 一,SSR與SPA的區(qū)別 在談NUXT前,我們得先了解一下什么是SSR。 SSR是英文server side render的縮寫,即服務(wù)端描畫。 之前在SPA單頁(yè)的時(shí)候,mouted元素部分,都是先去服務(wù)端拉取js腳本,然后客戶端解析成html。而在SSR下,mouted部分是服務(wù)端描畫好后,直接發(fā)送到客戶端,客戶端不用進(jìn)行html的重新組合,只需要激活即可。 紅色字體部分可以看到,只是響應(yīng)了主體,而真正的內(nèi)容部分需要去下載js,然后客戶端繪制出來(lái)再展示,哪這樣會(huì)有什么問(wèn)題呢?對(duì)!白屏?xí)r間過(guò)長(zhǎng)。雖然現(xiàn)在有骨架技術(shù),也就是在響應(yīng)的html主體中,填充靜態(tài)內(nèi)容,但也是治標(biāo)不治本。 我們?cè)倏匆幌耂SR的方式: 從圖上可以看到,服務(wù)端返回的是完整的解析內(nèi)容可以直接呈現(xiàn)在用戶面前。但這都是靜態(tài)的,要?jiǎng)討B(tài)化,就需要有一步激活的操作。 這就是SPA與SSR兩者的區(qū)別。哪Nuxt.js是什么呢? 二,Nuxt.js Nuxt.js 是一個(gè)基于 Vue.js 的通用應(yīng)用框架。 通過(guò)對(duì)客戶端/服務(wù)端基礎(chǔ)架構(gòu)的抽象組織,Nuxt.js 主要關(guān)注的是應(yīng)用的UI渲染。 它既支持預(yù)渲染也支持SSR。SPA不是本文重點(diǎn),今天我們重點(diǎn)說(shuō)一下Nuxt的SSR部分。 相關(guān)部分的命令分2個(gè) npm run dev(開發(fā)環(huán)境) npm run build + npm run start(生產(chǎn)環(huán)境) 我們先看一張流程圖: 從圖上我們可以看到,開發(fā)和生產(chǎn)環(huán)境比,多了一步文件修改的監(jiān)聽。這也是為什么我們?cè)陂_發(fā)過(guò)程中,修改代碼后,頁(yè)面可以立即產(chǎn)生變化。當(dāng)然監(jiān)聽到文件變化后,還會(huì)有一系列的操作。 三,編譯與啟動(dòng) 先看編譯的過(guò)程,如下圖 首先先加載nuxt.config.js, 然后初始化nuxt,builder,開始執(zhí)行構(gòu)建。 準(zhǔn)備模板使用的參數(shù),然后根據(jù)模板生成真正的webpack編譯的js 分別執(zhí)行客戶端編譯和服務(wù)端編譯,生成最終的js腳本 編譯成功后,就需要啟動(dòng)服務(wù),監(jiān)聽端口,這個(gè)是在npm run start中實(shí)現(xiàn)的。如下圖 啟動(dòng)后,加載配置文件 初始化Nuxt 對(duì)端口進(jìn)行監(jiān)聽。 如果有請(qǐng)求進(jìn)來(lái),第一次會(huì)加載攔截器,然后攔截器會(huì)對(duì)請(qǐng)求進(jìn)行區(qū)分?jǐn)r截。 比如:如果是訪問(wèn)的靜態(tài)文件,那么會(huì)有staticServer來(lái)處理。 如果是路由匹配的請(qǐng)求,那么nuxtMiddleware會(huì)進(jìn)行接受,然后通過(guò)VUE的SSR插件,去繪制響應(yīng)的html 四,SSR的使用場(chǎng)景以及缺點(diǎn) SSR的優(yōu)點(diǎn)無(wú)非兩個(gè),一個(gè)是對(duì)SEO友好,二就是更快的內(nèi)容到達(dá)時(shí)間。 所以在使用SSR的第一個(gè)場(chǎng)景,必然是對(duì)響應(yīng)速度有較高的要求 但同時(shí)也會(huì)有更高的瓶頸點(diǎn)和風(fēng)險(xiǎn)。主要有下面幾個(gè): 更長(zhǎng)的鏈路,之前是瀏覽器+nginx+后臺(tái)服務(wù),而現(xiàn)在就變成瀏覽器+nginx+nodejs+后臺(tái)服務(wù)。 nodejs中的阻塞型請(qǐng)求,容易成為性能的瓶頸。 一套api,要考慮前后端的兼容性 對(duì)業(yè)務(wù)開發(fā)人員來(lái)說(shuō),曲線變長(zhǎng),需要能明確代碼在前后端的執(zhí)行位置 結(jié)語(yǔ) 本文簡(jiǎn)單介紹了SSR以及NUXT的處理流程,希望對(duì)剛開始接觸SSR的前端,能有所幫助。 該文章在 2024/8/19 9:40:05 編輯過(guò) |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |