6月30日老板召集部門開會，當時發(fā)生了一件很尷尬的事情，老板打開了臺macBookAir运翼，系統(tǒng)上的圖標很老双谆，估摸著還是雪豹那個時代的系統(tǒng)壳咕，然后打開了公司主站gulugulu.cn顽馋，奇跡發(fā)生了谓厘，網(wǎng)站居然卡在那需要10來秒才能打開，我很尷尬寸谜，但是還是很鎮(zhèn)定的說應該是電腦系統(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)計讨跟，對比：
| 站點 | 圖片 | js | css | 總資源 | 總加載時間 |
|---|---|---|---|---|---|
| gulugulu.cn(優(yōu)化前) | ~3000kb | ~1800kb | ~400kb | ~5800kb | <=3.2秒 |
| bilibili.com | <900kb | <300kb | <20kb | <=1300kb | <=2.2秒 |
| taptap.com | <2000kb | <100kb | <109kb | <=2200kb | <=1.8秒 |
| gulugulu.cn(優(yōu)化后) | <=1400kb | <=610kb | <=170kb | <=2400kb | <=2.5秒 |
當時分析出如下信息：
圖片：
blibili頁面內(nèi)容長度大纪他，沒有大幅banner類圖片，所有圖片內(nèi)容均做了懶加載晾匠，所以首屏加載時僅僅加載了顯示屏區(qū)域內(nèi)的圖片茶袒，并且圖片均做了兩類適配，支持webp格式的顯示webp凉馆，不支持webp格式的顯示jpg薪寓，同事做了類似阿里云裁剪設置，圖片最大的都不超過75kb句喜，真心佩服预愤。
taptap稍差一點，就內(nèi)容而言并沒有bilibili豐富咳胃，但是因為他們最大的圖片有200kb左右植康，沒有webp格式，同樣他也做了懶加載展懈，但是因為有大幅圖片存在销睁，所以首屏中圖片已經(jīng)達到了2000Kb。
最后說說我們gulugulu存崖，驚喜的發(fā)現(xiàn)有一個小圖片就有1300kb冻记，我欲哭無淚，定是運營上傳圖片時沒有壓縮圖片来惧，向來自己動手冗栗。
1、首先我對從阿里云獲取的圖片做了統(tǒng)一的裁剪處理供搀，設置寬度為容器的1.5倍高度自動隅居，格式jpg，清晰度80%葛虐，添加類似這樣的命令后綴即可@1e_120w_120h_1c_0i_0o_90Q_1x.jpg胎源。
2、然后對本地圖片全部通過tinypng.com壓縮屿脐，后再次導入項目涕蚤。
3宪卿、最后對大于10kb的icon盡量全部采用svg字體文件替代
最后測得首頁所有圖片即使沒有做懶加載也不到1400kb（首頁內(nèi)容太少，幾乎只有一屏万栅，做懶加載沒必要）除了最大的一個banner有200kb之外佑钾，其余所有圖片均小于80kb
js && css：
因為框架是spa類型的框架，前端邏輯和依賴較多烦粒，js就會比taptap這類以后端架構(gòu)為主的頁面大很多次绘，組件的按需加載早已經(jīng)做過了,當時有段時間總覺得是因為自己代碼寫的不好導致的。
反復觀察bilibili和taptap的載入情況后發(fā)現(xiàn)撒遣，他們都開啟了gzip壓縮，千方百計讓運維重新過了一次nginx的設置管跺，開啟gizp后js大小下降非常明顯最大的一個357kb文件在gzip5級壓縮下义黎，大小下降到了150kb。之后我將npm安裝的第三方插件大部分轉(zhuǎn)成了script標簽引入方式豁跑，靜態(tài)文件分配到若干cdn中廉涕，并做了dns-prefetch，dns預解析艇拍。終于將js降到了原來的1/3大小狐蜕。之后又打開了cdn中的gzip和緩存策略，設置完成后測試網(wǎng)站首屏已經(jīng)相當喜人卸夕，最快首屏可以到1.8秒左右层释。性能魔方測試結(jié)果排名16，平均載入時間<2.3秒快集。
之后優(yōu)化方向
1贡羔、可能會加入懶加載和webp格式圖片。
2个初、可能會嘗試在vue中多書寫公共樣式乖寒，減少scoped樣式，以減少css大小
- 相關項目
地址：gulugulu.cn
