6月30日老板召集部門開會，當(dāng)時發(fā)生了一件很尷尬的事情，老板打開了臺macBookAir，系統(tǒng)上的圖標(biāo)很老，估摸著還是雪豹那個時代的系統(tǒng)，然后打開了公司主站gulugulu.cn，奇跡發(fā)生了，網(wǎng)站居然卡在那需要10來秒才能打開，我很尷尬，但是還是很鎮(zhèn)定的說應(yīng)該是電腦系統(tǒng)太老了，老板打開了bilibili 和taptap的網(wǎng)站基本上都能在幾秒內(nèi)打開，臉上有些掛不住啊（我自信5月份將主站升級到Vue2.0之后性能已經(jīng)有了質(zhì)的飛越，多次測試都在3秒以內(nèi)可以打開，沒想到...），之后換了臺較新的macbookpro后網(wǎng)站打開快多了，這讓我很好奇為什么差別這么遠，而bilibili和taptap在兩臺電腦上打開速度相差不大，之后我把bilibili和taptap首頁所有資源全部做了一個統(tǒng)計，對比：

當(dāng)時分析出如下信息：

圖片：

blibili頁面內(nèi)容長度大，沒有大幅banner類圖片，所有圖片內(nèi)容均做了懶加載，所以首屏加載時僅僅加載了顯示屏區(qū)域內(nèi)的圖片，并且圖片均做了兩類適配，支持webp格式的顯示webp，不支持webp格式的顯示jpg，同事做了類似阿里云裁剪設(shè)置，圖片最大的都不超過75kb，真心佩服。

taptap稍差一點，就內(nèi)容而言并沒有bilibili豐富，但是因為他們最大的圖片有200kb左右，沒有webp格式，同樣他也做了懶加載，但是因為有大幅圖片存在，所以首屏中圖片已經(jīng)達到了2000Kb。

最后說說我們gulugulu，驚喜的發(fā)現(xiàn)有一個小圖片就有1300kb，我欲哭無淚，定是運營上傳圖片時沒有壓縮圖片，向來自己動手。
1、首先我對從阿里云獲取的圖片做了統(tǒng)一的裁剪處理，設(shè)置寬度為容器的1.5倍高度自動，格式j(luò)pg，清晰度80%，添加類似這樣的命令后綴即可@1e_120w_120h_1c_0i_0o_90Q_1x.jpg。
2、然后對本地圖片全部通過tinypng.com壓縮，后再次導(dǎo)入項目。
3、最后對大于10kb的icon盡量全部采用svg字體文件替代
最后測得首頁所有圖片即使沒有做懶加載也不到1400kb（首頁內(nèi)容太少，幾乎只有一屏，做懶加載沒必要）除了最大的一個banner有200kb之外，其余所有圖片均小于80kb

js && css：

因為框架是spa類型的框架，前端邏輯和依賴較多，js就會比taptap這類以后端架構(gòu)為主的頁面大很多，組件的按需加載早已經(jīng)做過了,當(dāng)時有段時間總覺得是因為自己代碼寫的不好導(dǎo)致的。

反復(fù)觀察bilibili和taptap的載入情況后發(fā)現(xiàn)，他們都開啟了gzip壓縮，千方百計讓運維重新過了一次nginx的設(shè)置，開啟gizp后js大小下降非常明顯最大的一個357kb文件在gzip5級壓縮下，大小下降到了150kb。之后我將npm安裝的第三方插件大部分轉(zhuǎn)成了script標(biāo)簽引入方式，靜態(tài)文件分配到若干cdn中，并做了dns-prefetch，dns預(yù)解析。終于將js降到了原來的1/3大小。之后又打開了cdn中的gzip和緩存策略，設(shè)置完成后測試網(wǎng)站首屏已經(jīng)相當(dāng)喜人，最快首屏可以到1.8秒左右。性能魔方測試結(jié)果排名16，平均載入時間<2.3秒。

之后優(yōu)化方向

1、可能會加入懶加載和webp格式圖片。
2、可能會嘗試在vue中多書寫公共樣式，減少scoped樣式，以減少css大小

• 相關(guān)項目
  地址：gulugulu.cn