記一次 VUE 專案優化實踐
愛康體檢寶 PC(www.tijianbao.com/) 算是一個“老”專案,為什麼說“老”呢,因為在前端技術日新月異,每天都有新知識、新概念,甚至新框架的今天,它還是基於vue-cli 2.x、webpack 3.x構建,顯然有些老了。其次,在早期開始這個專案的時候,由於倉促上線,也沒有過多的考慮效能及載入問題,目前網站上使用的圖片未經過裁切,所有的庫都打包到一個 vendor 裡,首屏載入時間太長,等等這些問題使網站的使用者體驗不是太好,基於各方面的原因,決定對它進行一次優化,主要從以下幾個方面:
使用 https 及 升級成 http/2 協議
https 主要帶來安全性方面的提升,而且 http/2 依賴於 https,只有使用 https 協議的站點可以升級 http/2 協議。
http/2 帶來了一系列的改動和優化,主要如下:
- 每個伺服器只用一個連線。HTTP/2 對每個伺服器只使用一個連線,而不是每個檔案一個連線。這樣,就省掉了多次建立連線的時間,這個時間對 TLS 尤其明顯,因為 TLS 連線費時間。
- 加速 TLS 交付。HTTP/2 只需一次耗時的 TLS 握手,並且通過一個連線上的多路利用實現最佳效能。HTTP/2 還會壓縮首部資料,省掉 HTTP/1.x 時代所需的一些優化工作,比如拼接檔案,從而提高快取利用率。
- 簡化 Web 應用。使用 HTTP/2 可以讓 Web 開發者省很多事,因為不用再做那些針對 HTTP/1.x 的優化工作了。
- 適合內容混雜的頁面。HTTP/2 特別適合混合了 HTML、CSS、JavaScript、圖片和有限多媒體的傳統頁面。瀏覽器可以優先安排那些重要的檔案請求,讓頁面的關鍵部分先出現,快出現。
- 更安全。通過減少 TLS 的效能損失,可以讓更多應用使用 TLS,從而讓使用者資訊更安全。
這裡有一篇來自 google 的HTTP/2 簡介 更為全面和權威。
配置主要是在編譯 nginx 時加上 with-http_ssl_module 模組和 with-http_v2_module模組
./configure --with-http_v2_module --with-http_ssl_module 複製程式碼
配置伺服器 conf 檔案
server { listen 443 ssl http2 default_server; ssl_certificate server.crt; ssl_certificate_key server.key; ... } 複製程式碼
然後重啟伺服器,完成升級
合理控制快取
快取對於 web 應用程式至關重要,合理控制快取可以有效提升 web 效能,我們之前有些域下未做明確的快取管理,雖然瀏覽器有預設的快取機制,但是由於預設的機制未必能滿足我們的要求,而且各瀏覽器的預設機制不同,可能造成 web 程式的表現也不同,所以很有必要對各資源的快取進行精細控制。
關於瀏覽器快取,我寫過一篇文章 做了詳細介紹,這裡只說具體的實施細節:
- 開啟 gzip (伺服器優化的一總分,不屬於快取範疇)
- 開啟 etag
- 對 html 型別的檔案設定過期時間為 80s
- 對 api 請求設定無快取
- 對靜態資源設定一個較長時間的快取
具體 nginx 配置如下:
# 配置 gzip gzip on; gzip_min_length 0k; gzip_comp_level 1; gzip_types text/plain application/json application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png; gzip_vary on; gzip_disable "MSIE [1-6]\."; # 開啟 etag etag off; # 不快取介面 location ~* \.(?:manifest|appcache|xml|json)$ { add_header Cache-Control "no-cache"; } # 設定 html 過期時間為 80s location ~* \.(?:html)$ { add_header Cache-Control "max-age=80"; } # 給靜態資源設定一個長期快取 location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ { expires 1M; access_log off; add_header Cache-Control "public"; } # CSS and Javascript location ~* \.(?:css|js)$ { expires 1y; access_log off; add_header Cache-Control "public"; } 複製程式碼
因為 html 型別的頁面檔案可能實時發版,不能設定較長時間的快取,否則可能造成發版後不更新的現象。
靜態資源都設定成較長快取時間,由於發版後,如果靜態資源有更新,都會產生新的 hash 值,從而使老的資源過期。
api 請求由於要實現獲請最新內容,所以不設定瀏覽器快取,期望的結果是能通過 etag 優化傳輸,但在實踐中通過 nginx 設定 api 無效,具體過程還在探索中。
通過以上方式,對 web 程式的快取進行了較精細的控制。
合理使用圖片
網站本身使用的圖片有兩個來源,分別是 又拍雲 和 我們自己的 idc(通過阿里雲加速),在使用的過程中都沒有裁切,導致整體載入的圖片資源比較大,做了如下優化:
針對來自又拍雲的圖片資源
又拍雲提供了動態裁切的功能,可以特別方便的控制圖片資源。
例如對於某個圖片資源,我們需要的是一個寬為 200px 的圖片,以前我們是直接引用這個資源:ofollow,noindex">domain.url/commodity/9… ,這是一個原始資源,可能是一個很大的圖片,直接引用會造成浪費
通過自動裁切,我們可以引用指定寬度的圖片:domain.url/commodity/9… ,通過在 url 後加 !/fw/200,可以引用寬度為 200px 的圖片,最大限度上節省資源
對於支援 webp 的瀏覽器,還可以讓其輸出 webp 版本:domain.url/commodity/9… ,通過關鍵字 /format/webp 指定輸出的資源格式為 webp
總的來說,又拍雲提供方便靈活的資源控制方法,更多細節見官方文件:help.upyun.com/knowledge-b…
針對來自 idc 的圖片資源
來自 idc 的圖片相對較難處理,由於沒有云儲存提供的功能,idc 只是單純的做為檔案儲存伺服器,所以沒有辦法動態裁切。
不過天無絕人之路,可以通過 nginx 的一個模組來實現類似的功能,這個模組就是:ngx_http_image_filter_module,通過這個模組可以對指定的資源按條件進行裁切,當 CDN 回源的時候給他裁切好的圖片就可以了,部分實現了雲端儲存的功能,具體實施如下:
一、編譯 nginx 時加上 --with-http_image_filter_module
二、配置 nginx
location ~* /images/(.+)$ { set $width -; #圖片寬度預設值 set $height -; #圖片高度預設值 if ($arg_width != "") { set $width $arg_width; } if ($arg_height != "") { set $height $arg_height; } #image_filter_jpeg_quality 85; image_filter resize $width $height; #設定圖片寬高 image_filter_buffer 10M;#設定Nginx讀取圖片的最大buffer。 image_filter_interlace on; #是否開啟圖片影象隔行掃描 if ($arg_info = "yes") { #image_filter size; } error_page 415 = 415.png; #圖片處理錯誤提示圖,例如縮放參數不是數字 } 複製程式碼
通過以上配置,當我們想訪問某個資源時可能通過:domain.url/images/img.… 得到寬為 200px 的圖片。
由於大規模部署,運維需要做更詳細的測試,所以當這次優化上線時,這個功能還沒有上線。當測試完成後,運維就會將這個功能部署到線上。
這個模組的官方文件是:nginx.org/en/docs/htt…
使用圖片懶載入 和 webp
使用圖片懶載入 主要依賴 Vue-Lazyload 這個 npm 模組,具體使用方法見:www.npmjs.com/package/vue…
這裡主要說一下其中的兩個功能 progressive 和 webp:
Vue.use(VueLazyload,{ observer: true, attempt: 10, filter: { progressive (listener, options) { const is_upyun_CDN = /upyunimages\./ if (is_upyun_CDN.test(listener.src)) { listener.el.setAttribute('lazy-progressive', 'true') listener.loading = listener.src.replace(/fw.+/, 'fw/10') } }, webp (listener, options) { if (!options.supportWebp) return const is_upyun_CDN = /upyunimages\./ if (is_upyun_CDN.test(listener.src)) { listener.src += '/format/webp' } } } }) 複製程式碼
通過 filter 整體對所有懶載入資源進行過濾控制:
progressive:允許在載入大圖見,先載入一個小圖,會有一個很好的使用者體驗
webp: 對支援 webp 的瀏覽器,載入資源的 webp 版本,有效降低檔案大小
通過這一系列操作,可以更進一種降低不必要的資源載入量。
升級至 webpack4
按說 webpack 3 用的好好的,為什麼要升級到 4 呢,原因還是因為新版本給我們帶來了諸多好片,而且目前已經是穩定版本,主要有以下內容:
- 更快的編譯速度,網上有說提高了 98%,我雖然沒有驗證資料,但直觀上快了,而且快了很多
- 零配置模組打包,雖然沒辦法做到“零” ,但是更多更合理的預設配置,使工程構建更加方便
- 拋棄了 CommonChunksPlugin,使用更為先進的 SplitChunksPlugin 提取公共資源
- 使用 Tree Shaking ,有效減少業務程式碼體積
- 引入 mode 屬性,可以定義為 development 和 production,不用再為生產和開發環境編寫過多的配置程式
- 等等其他未提及的 以及 預設的優化
升級過程中可能會遇到種種問題,好在有個官方升級指南 可以幫我們覆蓋掉一部分,但這會指南過於簡明扼要,具體到專案中還會有很多坑,好在通過錯誤提示結合偉大的google,最終都能找到答案(如果你用 baidu ,很有可能最終爬不上來 :< ...),也可以結合網上其他一些升級方面的文章,都會很有幫助,我這裡就不細述了。
總在來說升級 wp 4 會花一些時間,但帶來的效率和效能提升絕對值得。
優化首屏載入
對於 web 單頁面應用而言,一個非常大的痛點就是在首次載入時載入的資源量過大,導致使用者在第一次訪問時出現在白屏時間較長,如何優化這個體驗是整體優化中的重中之重,所以放在最後來說。
前面已經說了,通過減少圖片大小、升級 webpack 4、優化公共資源包等等手段,都是為了這個服務(當然了,也不全是:>),這些手段都是對資源進行操作。當對這所有的資源進行了操作,如何合理處理這些資源,就到了瀏覽器的渲染機制,如何通過優化渲染過程,提高首屏渲染速度,是我們下一步要考慮的。
瀏覽器渲染頁面的過程,主要分為五步(略過請求部分,只討論請求到資源後瀏覽器如何處理):
- 處理 HTML 標記並構建 DOM 樹。
- 處理 CSS 標記並構建 CSSOM 樹。
- 將 DOM 與 CSSOM 合併成一個渲染樹。
- 根據渲染樹來佈局,以計算每個節點的幾何資訊。
- 將各個節點繪製到螢幕上。
從上面可知,瀏覽器只要載入到 html 結構和 css,就可以渲染出頁面。
針對上面得到的結構,有3種可選方案來實現:
- 服務端渲染
- 利用 prerender-spa-plugin 做預渲染
- HTML 內實現 Loading
先揭曉答案,最終我選擇了第 3 種,至於為什麼選擇,接下來挨個來看
服務端渲染
什麼是服務端渲染?來自官網 的解釋是:將元件渲染為伺服器端的 HTML 字串,將它們直接傳送到瀏覽器,最後將這些靜態標記"啟用"為客戶端上完全可互動的應用程式。
伺服器端渲染(SSR)的優勢主要在於:
- 更好的 SEO,由於搜尋引擎爬蟲抓取工具可以直接檢視完全渲染的頁面。
- 更快的內容到達時間(time-to-content),特別是對於緩慢的網路情況或執行緩慢的裝置。無需等待所有的 JavaScript 都完成下載並執行,才顯示伺服器渲染的標記,所以你的使用者將會更快速地看到完整渲染的頁面。
我之前寫過一篇文章,詳細討論了如何實現一個服務端渲染專案 。
但是這樣一個看似美好的方案,同樣存在需要權衡的地方:
- 開發條件所限。瀏覽器特定的程式碼,只能在某些生命週期鉤子函式(lifecycle hook)中使用;一些外部擴充套件庫(external library)可能需要特殊處理,才能在伺服器渲染應用程式中執行。
- 涉及構建設定和部署的更多要求。與可以部署在任何靜態檔案伺服器上的完全靜態單頁面應用程式(SPA)不同,伺服器渲染應用程式,需要處於 Node.js server 執行環境。
- 更多的伺服器端負載。在 Node.js 中渲染完整的應用程式,顯然會比僅僅提供靜態檔案的 server 更加大量佔用 CPU 資源(CPU-intensive - CPU 密集),因此如果你預料在高流量環境(high traffic)下使用,請準備相應的伺服器負載,並明智地採用快取策略。
同時還有一個不得不考慮的問題是,由於服務端渲染模糊了前後端的界限,需要更多的伺服器方面的知識,在專案落地時要全面考慮運維、後期專案交接等等,最後放棄這個方案~
利用 prerender-spa-plugin 做預渲染
預渲染 可以達到和 SSR 類似的目的,它在編譯階段,將指定的頁面編譯成 html,當有請求時直接將 html 內容傳送給客戶端,但是他也存在問題:
- 它是在編譯階段完成的,只能編譯有限的頁面(例如 /, /about, /contact 等),沒有辦法將所有內容靜態化,而且如果內容有更新,之前編譯過的頁面也不會得到更新。
- 頁面抖動,例如我們首次訪問的是一個動態內容 /article/id-1234 ,由於這個動態內容之前沒有編譯成 html,這個請求會落在 /index.html 上,index.html 會被先渲染,當動態介面有內容後會更新整個頁面,渲染成目標頁,這會對用記造成困惑。
事實上這是一個不錯的方案,VUE 官方也推薦這個方案,在實踐的過程中遇到了一些問題,我也做了一些記錄 ,但是綜合考慮還是放棄了這個方案。
HTML 內實現 Loading
這是我們最終選擇的方案,這個方案從原理到實現都相對簡單,它藉助 html-webpack-plugin 將一段指定的 html 和 css 插入到模板中,在 js 和 api 請求未返回之前,以最快的速度給使用者一個 loading 提示,告知使用者得到了響應。
具體做法如下:
將 loading 效果的 html 拆分成loading.html
和loading.css
,分別放在 /src/preLoad/loading.html 和 /src/preLoad/loading.css
在 webpack 的 config 檔案裡讀取這兩個檔案:
module.exports = { loading: { html: fs.readFileSync(path.join(__dirname, '../src/preLoad/loading.html')), css: '<style>' + fs.readFileSync(path.join(__dirname, '../src/preLoad/loading.css')) + '</style>' } // ... } 複製程式碼
在 build 的配置檔案裡引入:
module.exports = { plugins: [ new HtmlWebpackPlugin({ loading: config.loading // ... }) // ... ] // ... } 複製程式碼
在模板檔案中插入變數:
<!DOCTYPE html> <html> <head> <!-- ... --> <%= htmlWebpackPlugin.options.loading.css %> </head> <body> <div id="app"> <%= htmlWebpackPlugin.options.loading.html %> </div> </body> </html> 複製程式碼
通過這種方法,可以將一個動態的 loading 效果插入到頁面中。
由於 css 會阻塞渲染,所以當我們看到這個 loading 之前,儘量的少載入其他的 css 和 js,採用的方案是不提取 css,由於 vue-cli 預設的設定是提取,所以需要手動修改一下:
// vue-loader.conf.js module.exports = { loaders: utils.cssLoaders({ sourceMap: sourceMapEnabled, extract: false // 不提取 }), // ... } 複製程式碼
這樣 css 就會被編譯進 js 裡,通過 js 進行輸出,在 loading 效果出來之前,不會阻塞頁面。
最後還有一個問題需要解決,由於程式依賴各種第三方包,這些包都會打包到 vendor.js 中,使這個檔案特別大,甚至超過了 1M,需要對這塊進行優化,思路就是告訴 webpack 要打包不,不要將某些包打到 vendor.js裡,然後我們手動在 html 裡引入這些檔案。
由於現在第三方 CDN 提供了穩定的資源訪問,而且藉助 http/2 的多種利用特性,使的這些第三方資源載入特別快,具體做法如下:
在 webpack 的 config 定義將要從第三方引入的資源:
在 webpack 的基礎配置檔案裡定義那些包不需要打包到 vendor.js裡:
// webpack.base.conf.js module.exports = { externals: { 'vue': 'Vue', 'vuex': 'Vuex', 'iview': 'iview' } //... } 複製程式碼
在 webpack 的 config 檔案裡批明第三方資源:
module.exports = { loading: { html: fs.readFileSync(path.join(__dirname, '../src/preLoad/loading.html')), css: '<style>' + fs.readFileSync(path.join(__dirname, '../src/preLoad/loading.css')) + '</style>' }, css: [ 'https://cdn.jsdelivr.net/npm/[email protected]/dist/styles/iview.css' ], js: [ 'https://cdn.jsdelivr.net/npm/[email protected]/dist/vue.min.js', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/vuex.min.js', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/iview.min.js' ] // ... } 複製程式碼
和 loading 類似,在 build 的配置檔案裡引入:
module.exports = { plugins: [ new HtmlWebpackPlugin({ loading: config.loading, externals_js: config.js, // 引入 js externals_css: config.css, // 引入 css // ... }) // ... ] // ... } 複製程式碼
在模板檔案中插入變數:
<!DOCTYPE html> <html> <head> <!-- ... --> <%= htmlWebpackPlugin.options.loading.css %> <% for (var i in htmlWebpackPlugin.options.externals_css) { %> <link href="<%= htmlWebpackPlugin.options.externals_css[i] %>" rel="stylesheet"> <% } %> </head> <body> <div id="app"> <%= htmlWebpackPlugin.options.loading.html %> </div> <% for (var i in htmlWebpackPlugin.options.externals_js) { %> <script src="<%= htmlWebpackPlugin.options.externals_js[i] %>"></script> <% } %> </body> </html> 複製程式碼
通過這種方法,將比較大的包從 vendor.js 裡剔除,通過第三方 CDN 引入。