繼之前的一篇《記前端項(xiàng)目首屏加載優(yōu)化（打包篇）》之后，這次來講一講我的首屏加載在網(wǎng)絡(luò)方面的優(yōu)化?。

寫在前面

資源加載是一個(gè)網(wǎng)站的展示在用戶瀏覽器的必經(jīng)之路，資源的請求次數(shù)和響應(yīng)時(shí)間決定了網(wǎng)站的加載體驗(yàn)。本篇主要針對請求次數(shù)和響應(yīng)時(shí)間聊一聊優(yōu)化過程。

網(wǎng)站分析與測試環(huán)境

有很多工具可以檢測網(wǎng)站的網(wǎng)絡(luò)請求：比如WebPage Speed Test，Instant Website Test，這些工具可以分析網(wǎng)站的加載速度、安全性、可靠性等很多方面。而我是希望能夠在本地開發(fā)過程中分析并優(yōu)化，所以我還是選擇Chrome Devtool 里的Network panel 進(jìn)行分析。

本地開發(fā)環(huán)境的資源跟線上是有所不同的，本地的資源一般沒有壓縮，而線上有壓縮，這樣就會造成測試環(huán)境不真實(shí)，所以需要在本地模擬線上的打包環(huán)境，編譯出跟線上環(huán)境一樣的包來加載，這樣分析出來的結(jié)果才有意義。

在上一篇《記前端項(xiàng)目首屏加載優(yōu)化（打包篇）》有寫到過在本地打包一個(gè)和線上環(huán)境一致的壓縮配置，在package.json加入下面的配置:

"scripts": {..."local_production": "cross-env NODE_ENV=local_production npm run build" }

然后在webpack配置里面判斷process.env.NODE_ENV === 'local_production'，便構(gòu)建出production環(huán)境的包即可。

gzip壓縮

打包出來的包大小1.7M，所有的依賴包index.xxx.js有748k這么大，所以需要開啟gzip壓縮，可以大大減小加載大小，首先安裝express 的gzip包 compression:

npm install -D compression

然后添加express中間件：

var compression = require('compression'); app.use(compression());

打包后啟動服務(wù)器，瀏覽器訪問，這時(shí)候index.xxx.js已經(jīng)壓縮到212kb?

開啟http2.0

http1.x時(shí)代的優(yōu)化折磨好長一段時(shí)間，各種奇淫技巧為了彌補(bǔ)http1的短板，影響著我們的開發(fā)專注度，好在http2已經(jīng)開始盛行，相信不久的將來可以完全替代http1。

現(xiàn)在基本主流的瀏覽器都支持http2.0了

http2.0大幅提升了加載性能，相比http1增加了多路復(fù)用、二進(jìn)制分幀、header壓縮等特性

開啟http2也很簡單，前提是開啟了https協(xié)議，只要在Nginx配置文件中找到你要開啟http2.0的域名server模塊，然后將 listen 443 ssl;改成 listen 443 ssl http2; 即可。

server {listen 443 ssl http2;server_name domain.com;ssl_certificate /path/to/public.crt;ssl_certificate_key /path/to/private.key;ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #允許的協(xié)議 ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; #加密算法(CloudFlare 推薦的加密套件組) ssl_prefer_server_ciphers on; #優(yōu)化 SSL 加密套件 ssl_session_timeout 10m; #客戶端會話緩存時(shí)間 ssl_session_cache builtin:1000 shared:SSL:10m; #SSL 會話緩存類型和大小 ssl_buffer_size 1400; # 1400 bytes to fit in one MTU

檢查請求是否已經(jīng)開啟http2，可以在chrome的network面板點(diǎn)鼠標(biāo)右鍵，選中protocol,就可以看到該請求是否開啟了http2，圖中h2就代表http2：

順便提一句，很多第三方的SDK都沒有開啟http2?

CDN加速

項(xiàng)目開發(fā)中用到的靜態(tài)資源和打包后的資源都可以傳到cdn以提高加載速度，我的項(xiàng)目是用七牛的上傳腳本，在npm run build之后執(zhí)行上傳腳本將dist目錄上傳到cdn上，注意在webpack配置里要配置publish_path對應(yīng)上傳cdn后的域名路徑。具體看七牛的上傳腳本文檔

構(gòu)建線上環(huán)境的publicPath的值可以是cdn的域名+路徑的形式，結(jié)尾要加/：
"https://cdn.xxx.com/static/

webpack的output里配置publicPath：

output: {path: DIST_PATH,publicPath: publicPath,},

webpack的圖片資源Loader應(yīng)添加相應(yīng)配置publicPath：

{test: /\.(jpg|gif|ico|png|svg|mp4|mp3)$/,use: `url-loader?limit=10&name=asset/[name]_[hash:5].[ext]&publicPath=${config.PUBLIC_PATH_ASSET}`,exclude: /(node_modules)/,},{test: /\.(woff|eot|ttf)\??.*$/i,loader: `url-loader?limit=1000&name=fonts/[name].[hash].[ext]&publicPath=${config.PUBLIC_PATH_ASSET}`,exclude: /(node_modules)/,},

無模塊化js的按需加載

有些時(shí)候我們引入的第三方插件是不能被webpack優(yōu)化按需加載，或者是沒有提供模塊化加載的（只能通過script標(biāo)簽引入的）插件，比如像tinymce富文本編輯器，由于它的加載方式是靠script標(biāo)簽引入tinymce.js，并靠tinymce.js里自身的加載機(jī)制去另外加載主題theme.js或者相關(guān)plugin.js。

這種第三方插件無法做成模塊化。這樣的話我們是不是就只能在入口index.html加script標(biāo)簽引入它，被迫在首屏加載這個(gè)暫時(shí)用不到的大文件?？

我找到了webpack-require-http來幫忙?，他可以幫我用require語句幫我加載遠(yuǎn)程js，并提供了回調(diào)?，于是我便可以控制在什么時(shí)候加載tinymce?。

我的項(xiàng)目是按路由按需加載的，首頁沒有用到富文本編輯器所以沒必要加載，而論壇頁需要用到富文本編輯器，于是我們可以在react-router路由配置里的添加onEnter鉤子，在進(jìn)入論壇頁的時(shí)候才加載tinymce。

// 在需要tinymce編輯器的路由時(shí)提前加載 const require_tinymce = (nextState, replace, cb) => {require('https://cdn.bootcss.com/tinymce/4.7.13/jquery.tinymce.min.js').then(() => {cb();}); };// router-config.js {path: 'forum/:forum_id',component: forum_route,onEnter: require_tinymce, },

這樣子如果訪問首頁的話，首屏就少加載了這個(gè)big guy，經(jīng)測試，在模擬1M/s 的網(wǎng)速下訪問網(wǎng)站，出現(xiàn)首屏界面的時(shí)間快了2s左右，2s! ?...，這可以說是最大力度的一次優(yōu)化了。

緩存

緩存有很多種方式，大部分是服務(wù)器端處理的，而客戶端處理的則一般是把資源緩存在本地。

比較有效的本地緩存一般是用application-cache或者service worker將網(wǎng)站的資源緩存到本地，再次訪問時(shí)直接調(diào)用本地的緩存資源，幾乎是本地打開的速度，但是我的項(xiàng)目里的資源用到了CDN配置，所有的資源都在CDN外鏈中，而剛才提到的兩種緩存方式都不支持緩存跨域資源?。

這時(shí)候就得權(quán)衡一下了?，如果是首次訪問網(wǎng)站的瀏覽器，加載時(shí)間cdn服務(wù)器會比自身服務(wù)器快一些，而二次加載則后者更快，只是網(wǎng)站緩存需要自己維護(hù)一套配置，如果配置不得當(dāng)，會落下很嚴(yán)重的坑?，所以目前我還是先選擇相對保守的CDN加載，等以后慢慢磨合?。

轉(zhuǎn)載于:https://www.cnblogs.com/lipten/p/9650455.html

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的记前端项目首屏加载优化（网络篇）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。