針對web頁面的首屏加載問題，一直是個問題，為此還引出一個性能考量標准：白屏時間、首屏時間。
1.白屏時間
打開chrome控制台的Performance，我們可以看到頁面的渲染快照：
這段白屏時間影響的因素歸根結底就是：資源加載耗時較長（chunk.js文件下載耗時35.75s）；
而對於現在的大行其道的SPA來說，只要這個js文件沒有執行，那么頁面的代碼就只是這樣：
自然渲染結果暫時就只是一個白板咯
2.首屏時間
通常首屏內容中加載最慢的就是圖片或者 iframe 資源，因此可以理解為當圖片或者 iframe 都加載出來了，首屏肯定已經完成了。
所以只需要通過此類dom元素的onload事件來記錄資源加載的最長的那個時間點，然后與performance.timing.navigationStart比較久可以算出首屏渲染所需要的時間了；
performance.timing.navigationStart：表示從上一個文檔卸載結束時的 unix 時間戳，如果沒有上一個文檔，這個值將和 fetchStart 相等。
根據上述兩段分析，我們可以知道，白屏時間限制於帶寬，針對這一點，我們可以對靜態文件進行CDN加速、OOS之類的來提高訪問速度；
默認我們已經解決了白屏的問題（資源訪問速度）；
接下來就是首屏渲染的問題：
瀏覽器解析js是需要時間的（js的執行關系到頁面數據的填充）；
img等標簽請求網絡資源也是需要時間的（多圖片的可以考慮圖片懶加載，當然這不是這篇文章討論的）
對此，有一種解決方案就是骨架屏。
4.骨架屏
骨架屏長這樣：
就是在數據或者資源渲染之前，讓用戶看到一個頁面的骨架，不至於讓用戶對着空白屏傻傻等待。
針對現在的SPA應用，其實只要針對首屏做一個骨架屏就可以了；
這里有一個用vue-skeleton-webpack-plugin這個插件設置骨架屏的案例：https://www.jianshu.com/p/0a1b01ad62d6；
骨架屏的顯示邏輯是這樣的：
從代碼上來看，其實就是在不同的時間節點上用不同的dom片段來填充下面的區域：
5.骨架屏的生成/制作
手動編寫骨架屏代碼；
svg輪廓圖片代替dom節點以及css樣式；
自動化生成骨架屏代碼（https://github.com/Jocs/jocs.github.io/issues/22）
6.快捷方法
打開首屏，找到根節點，右鍵編輯：
將可id="app"內部區域代碼復制到你的骨架屏頁面；
然后index.html稍加樣式：
針對有偽元素的dom節點可以使用偽元素來實現該dom節點骨架屏樣式；
那么不支持偽元素的dom節點怎么處理呢（input、img等），暫時考慮用span標簽將其包圍，並且span標簽設置為行內塊狀元素；
這樣首頁的骨架屏就做好了 ^_^ ,是不是很便捷