延遲加載，晉升首屏的加載速度
當用戶打開一個很長的網頁時，首屏內容的加載給了最直不美觀的速度體驗。所以，讓首屏盡快的完成加載也是用戶權衡該頁面是否夠“快”的最首要的身分。5173的首頁，圖片根基都集中不才面的位置，讓下面的這些圖片全數都延遲加載就可以盡可能快的晉升首屏的加載速度。常見的圖片延遲加載手藝想必巨匠都不會目生了，這里就不復述。在 TAB 內容中也同樣有良多圖片，這里也讓它們在觸發 TAB 菜單的時辰再進行加載。給圖片在HTML代碼中添加固定的尺寸自然也不再話下。so easy? no!
具體實施
圖片中不僅僅有營業設置裝備擺設的圖片，也有來自第三方廣告系統的圖片(搜羅首屏的輪播年夜圖也是此類型的)。這些廣告圖片的 URL 是一個 JavaScript 鏈接，其中包含了使用 document.write 的體例來加載廣告圖片的代碼。還有些 TAB 中包含了使用 iframe 嵌入到頁面的合作站點的內容。廣告圖片以及 iframe 都是梗阻頁面加載的元兇。
最初的設法是年夜頭開發一套廣告系統，換一種廣告加載體例，可是開發成本太高。最后想到了使用 textarea 來延遲加載廣告和 iframe，玉伯供給的這種體例確實挺好用的。textarae 是個好工具，非論是通俗的 HTML 代碼亦或是 CSS、JavaScript 代碼，都可以扔到瑯縵沔去實現延遲加載。廣告圖片的優化斗勁麻煩，我在另一篇文章中有具體的介紹。有了 textarea，良多內容都可以像實現圖片延遲加載那樣來實施延遲加載，在 TAB 內容中的 iframe 也可以在觸發 TAB 菜單時再去加載 iframe。
處事端的優化
針對頁面總體積過年夜的問題，代碼的重構確實能減小不少的體積，此外靜態資本一律都要添加gzip，僅僅是添加gzip，帶來的機能晉升也是斗勁較著的。
合理的操作瀏覽器端的緩存也是很主要的，除了登錄信息以及 cookie 的這種時效性較高的請求外，所有能添加 cache-control 的請求都加上了 max-age 的過時時刻。關于瀏覽器端的緩存添加，這里有一篇斗勁具體的文章 Cache them if you can。緩存的添加也會給更新帶來麻煩，所以要有響應的體例來斷根緩存，給靜態資本的請求加上時刻戳即可。
此外處事端此次也斗膽的采用了 varnish 作為緩存加速處事器，這在國內年夜型網站中應該還不多見。
優化成不美觀
做了這么多工作是時辰看磕暌古化成不美觀了，先來砍寤鏖數據對比：
優化前后的請求數對比：
請求數的年夜年夜削減，緩解了處事器的壓力，可以撤失蹤良多處事器了。
優化前后的靜態資本的文件體積對比，沒有包含ajax數據等其他文件體積：
JavaScript的重構太孔殷了，原本竟有41個 JavaScript 外鏈文件，當然這些外鏈也搜羅了15個廣告的外鏈，廣告的優化我稍后再說，可是還剩下26個外鏈 JavaScript。這些臃腫不勝的 JavaScript文件即是造成頁面加載堵塞的元兇，也是系統資本占用的蛀蟲，這是整個項目的可貴之一。
年夜文件體積的對比來看，優化后節約了494KB的下載量，假若按照日PV1000000(估值，現實值弘遠于該值，氖灼戀耐計?隙啵??允灼戀乃俁瓤歟?墑親薌釉厥笨桃?ち級啵?比凰?塹南略亓懇慘?暌沽級啵?173的首屏是DOM數較多，下載量也小良多，所以總時刻和首屏時刻相當接近。這里說得總下載量是頁面初度加載完成的總下載量，因為都用到延遲加載手藝，向下滾動時又會有圖片加載，這些時刻是不計較在內的。
到底應該若何來權衡網頁加載的快慢?此次的優化我沒有用 yslow 和 pagespeed 等測試分數的軟件，而是以現實的加載速度為優化的方針，首屏的加載速度晉升就是最合適現實的聲名。如不美觀一個網站打開半天仍是白屏，相信年夜年夜都人城市感受很慢。這就是現實的體驗，測分軟件是紡暌鉤不出來的。
原載于：雨夜帶刀's Blog
本文鏈接：http://stylechen.com/5173homepage-optimized.html
如需轉載請以鏈接形式注明原載或原文地址。
網友點評
精彩導讀
科技快報
品牌展示