最近在做一個微信端的小項目，前端代碼寫完后，就放在手機端測試，沒什么問題，但是頁面在加載和渲染時的效果卻讓人有些不爽，雖然是個小項目，我大可不必做這些，但是看着頁面的閃動，就忍不住想做些什么。
先說說問題吧：
上面是首頁效果圖，其實在最開始的時候並沒有考慮web端，這圖是給IOS和安卓native App用的。為了方面兩個本地APP的開發，所以上面的圖中，除了那幾個科目和下面的tabBar，其余都是圖片。
因為都是圖片，所以布局真的是挺簡單，但是問題也隨之來了，幾張圖片都是通過img標簽的src屬性去請求的，所以在刷新或者跳轉的時候，會有明顯的空白閃動。
因為每張圖片都會有請求，這樣就會有排隊等候的時間，獲取到圖片后再渲染繪制，這樣就造成了頁面每個圖片區域都會有短暫的空白閃動。
我的解決方法則是通過base64，可以比較下兩者的network情況：
1.請求時間比較
1.首次加載無緩存
（圖片通過請求獲取的情況）
（將圖片轉換為base64的情況）
從圖中可以看出，在第一次沒有緩存的情況下，普通的img請求都會存在一個較長的排隊時間，也就是這個等候時間造成了頁面渲染時的空白閃動。
而將圖片轉換成base64之后，雖然html因為體積變大，所以加載時間變得更長，但整體的時間卻更短。
2.第二次及以后有緩存
（圖片通過請求獲取的情況）
（將圖片轉換為base64的情況）
在有了緩存之后，兩者的時間都大大降低，但是普通img請求的情況下，圖片依然存在排隊時間，所以頁面依然存在空白閃動的情況，雖然閃動的時間變短了。
而將圖片轉換為base64的情況下，則幾乎是沒有任何跳動的感覺，另外html也從協商緩存中獲取，所以時間大幅度縮短。
2.兩者性能情況
關於性能，我並沒有專門去寫一個需要加載很多頁面的測試頁，依舊只是使用這個頁面去進行的比較。
下面分別是轉換為base64的情況，和正常多次請求圖片的情況：
（將圖片轉換為base64的情況）
（圖片通過請求獲取的情況）
從圖中可以看出，將圖片轉換為base64后，導致文檔時間變長，但是在解析、渲染、繪制的時候，所需要的時間並不比請求png圖片花的時間多，而且我多次收集頁面的加載記錄情況，每次的情況都是一樣。
所以之前看網上有說瀏覽器解析base64的性能比png差了好多倍，但是隨着升級，這部分性能可能得到了提升。當然也可能是和我的測試圖片數量太少有關。
總之，起碼在你的首屏圖片不會經常變動，不需要去服務器獲取的情況下，將它轉換成base64應該是一種不錯的注意。
另外，對於類似tabBar那樣的小圖標，不經常更改，而且會在多個頁面都使用，更好的做法應該是做成iconfont，這樣你的iconfont樣式文件可以做緩存，而且不需要將公用的圖片轉換為base64，也能減小頁面體積。