這兩天一直在看首屏優化的文章,因此將其總結概括一下,方便之後使用。css
相對於移動端的首屏優化,PC在有些方面要苛刻得多,主要是由於PC端有太多的東西想要讓用戶看到,這就不免PC端的頁面大而「重」,與咱們如今「富客戶端」的概念想相呼應。html
本文目錄前端
以800x600像素尺寸爲標準,當瀏覽器加載頁面後看到第一眼的顯示內容爲首屏。而從開始加載到瀏覽器頁面顯示高度達到600像素且此區域有內容顯示的時間爲首屏顯示時間。jquery
以京東首頁爲例:json
當咱們打開京東時,第一眼看到的內容即爲首屏內容,也就是如上圖的內容。後端
一個頁面的「總加載時間」要比「首屏時間」長,但對於最終用戶體驗而言,當內容充滿首屏的區域時,用戶就能夠看到網站的主要內容並能夠進行各自的選擇了。首屏時間的快與慢,直接影響到了用戶對網站的認知度。
因此首屏時間的長短對於用戶的滯留時間的長短、用戶轉化率都尤其重要。瀏覽器
仍是首先以京東爲例:緩存
當咱們打開京東的網站(不要滾動鼠標和鍵盤),右鍵查看源代碼會發現京東首頁的DOM樹出奇的簡單,頁面DOM中多含有mod_lazyload的類性能優化
<div class="J_f J_lazyload J_f_lift mod_lazyload need_ani chn" id="portal_8" data-backup="basic_8" data-source="cms:basic_8" data-tpl="portal_tpl">
再看下 localstorage服務器
尤爲是觀察location下面的鍵值對,會發現它們的值中多存在一串完整的相似於html的內容(內容太多刪除了值中的內容)
由上面的結構咱們可知jd.com已經將它們的頁面結構放到了localstorage,不難想象這只是它頁面中的其中一個模塊的內容
分析到這裏已經很明顯了,經過前端緩存和異步加載jd已經完美的實現了首屏快速加載,在PC端達到了秒開的級別。
把須要請求的路徑寫在 dom 上(例如:data-tpl="elevator_tpl"),用戶滾動時,一旦該模塊進入了視窗,則請求 dom 上對應的 data-tpl 地址,拿到渲染這個模塊所須要的腳本和數據,不過這中間還有一層本地緩存 localstorage,若是在本地緩存中匹配到了對應的 hash string 內容,則直接渲染,不然請求到數據以後更新本地緩存。localstorage中的 version 會在頁面加載時候,與後端文件 hash相對比,hash不變直接取localstorage中的內容(固然也可使用cookie判斷版本)。
這裏其實存在兩個請求,一個請求是加載數據和腳本,而這裏的內容是:
爲啥不在返回的內容中直接把腳本也輸出出來?爲了讓數據充分緩存下了很多功夫。數據的變化頻率比較高,若是數據和初始化腳本包裝在一塊兒,雖然節約了一個請求,但一旦數據變化,整個腳本都得從新加載,而將數據和腳本分離,腳本能夠長期緩存在本地,單獨請求數據,這個量會小不少。直接改變上面的 version 版本號即可以讓瀏覽器從新請求最新腳本。
從上面能夠看出,任何一個模塊的改動,在前端只會引發一個較小的加載變化,加上 http 的緩存策略,服務器的壓力也是很小的。
看了上面的內容相信你們對於京東關於首屏優化的方案有了一個大致的瞭解,下面咱們再整理一下關於首屏顯示速度優化細節上的內容:
爲了求快,首頁是沒有css外鏈的,這樣會再發起屢次請求,相信對於咱們來講,也是老生常談的前端優化了。
那有人可能會問沒有css外鏈,那若是一整個頁面的css是否會增長頁面的體積?其實上面就已經提到了,頁面切分爲模塊化加載,對應模塊下的css交給js或jsonp請求返回
京東採用請求的方式減小了與服務器交互的時間
<script src="//misc.360buyimg.com/??/jdf/lib/jquery-1.6.4.js,/jdf/2.0.0/ui/ui/1.0.0/ui.js,/mtd/pc/index/gb/lib.min.js,/mtd/pc/base/1.0.0/base.js,/mtd/pc/common/js/o2_ua.js,/mtd/pc/index/home/index.min.js,/mtd/pc/index/home/init.min.js"></script>
懶執行,有交互才執行,有興趣的能夠看看小鬍子哥的淘寶首頁性能優化實踐這篇文章
圖片在其餘屏(非首屏)都採用懶加載的模式,這樣既能節省流量,也能減小請求數或延遲請求數。
以上基本上即是最近整理的一些內容,還有不少咱們前端開發應該注意像script標籤的位置啊,div的嵌套深度啊等咱們開發自己應該具有中的就很少說了。正所謂「一如前端深似海」。。。