優化! 又是優化!html
切圖崽們做爲整個web應用的紐帶,鏈接着用戶行爲和機器性能. 而優化
的最終意義,在於在這二者之間取得一個最佳的平衡點.jquery
對於圖片資源的加載來講,更是如此. 今天咱們就來簡單說說,項目開發中常見的圖片加載優化方式.web
咱們常常用jquery, jquery中$(function){})
其實是DOMContentLoaded
事件完成的回調,只是完成了DOM樹的構建. 諸如Css的渲染以及頁面內圖片等資源的下載不必定完成了.因此若是此時呈現頁面,頁面會很是難看.性能
爲了解決這個問題,爲了從設計和行爲的角度提升用戶體驗,咱們能夠在圖片等重要資源徹底下載完以前,對頁面加上較爲美觀的遮罩,而且彈出loading提示告知用戶資源正在loading.等到圖片徹底加載完,才移除遮罩和加載動畫.優化
具體的實現思路以下:動畫
$(function(){})調用以後,先彈出蒙板加上loading動畫用來提示用戶正在loading中設計
對頁面中須要預加載的IMG元素進行下載var img = new Image(); img.src="xx.jpg"
code
圖片下載完成會有一個onload的回調img.onload = function(){...}
htm
在這個回調中移除loading動畫以及遮罩事件
這樣就能夠給用戶帶來順滑如絲般的操做體驗了,不再用擔憂用戶看到那些正在下載的未顯示徹底的醜的要死圖片了.
咱們的口號是: 要麼就不給你看,要麼就給你看最好的
應用場景: 請在"首屏中存在圖片的動畫,或者和你對接的UI設計師極其強勢"的狀況下使用
有碼大法和遮罩大法略微有區別,具體實現思路以下:
首先對你須要預加載的圖片準備兩張,一張是高清一張低清. 好比girl_hd大小爲60kb. 另外一張是girl, 大小是6kb.
html頁面中須要預加載的image標籤的src地址寫的是低清的地址<img src="girl.jpg" class="hd-replace">
由於低清圖很小,很快就能被加載出來.
$(function(){})調用以後,獲取頁面須要高清替換的img的src(girl.jpg),以此src爲基準拼接字符串(+'_hd.jpg')得到高清圖的地址(girl_hd.jpg),而後用下載該高清圖var img = new Image(); img.src=「girl_hd.jpg」
圖片下載完成會有一個onload的回調img.onload = function(){...}
回調中替換掉頁面中img的src, 因此如今頁面上的image標籤爲 <img src="girl_hd.jpg" class="hd-replace">
咱們的口號是: 想看無碼高清,請先看有碼低清
應用場景: 請在"首屏中出現大量圖片,且尺寸都不小"的狀況下使用
若是你仔細看了上面預加載的思路,必定往我腦殼上拍磚: 遮罩大法也好,有碼大法也好,這並無提升項目的加載速度啊,最後該下載的圖片還不是得下載. 沒錯,懶加載只是改變了用戶的操做感覺,實際上項目的加載速度並無提升. 可是,如今要說的懶加載,但是實實在在的提升了項目的加載速度哦.
什麼是懶加載,一句話來解釋, 就是圖片按需加載
.
你們必定刷過微博,微博的照片牆就是懶加載的最佳示例.一開始顯示的照片並很少,只有用戶下拉,拉到底部的位置, 照片牆纔會被拉長,新的圖片纔會被加載.
操做思路:
監聽滾動條scroll
事件(固然touchmove
事件也能夠)
每次事件觸發的時候,判斷當前照片牆的位置
若是照片牆已經被刷到了底部某個臨界位置點
Js下載新出現的圖片,var img = new Image(); img.src="xx.jpg"
下載完成有一個onload的回調img.onload = function(){...}
在下載完成的回調中向頁面中插入已經下載好的圖片
固然,根據項目不一樣,會有各類各樣的懶加載方式.但核心是不變的:即頁面初始加載的時候,只加載知足用戶需求的最小數量的資源
. 拿照片牆舉例,可能用戶的微博裏有500張照片,若是你在頁面加載的時候就加載500張,用戶會卡到爆炸(由於後臺一直處於圖片下載狀態). 若是頁面加載的時候只初始加載20張圖片,其餘的圖片經過用戶本身的操做(滾動下拉),來按需加載,會極大提高項目運行的流暢程度.
雖然預加載仍是懶加載實現原理都很是簡單,給個人啓示確是巨大的:
預加載
除了改善用戶的操做感覺,其深層次的核心其實在於:對資源進行碎片化加載
, 即預加載其實能夠出如今任什麼時候間段,當用戶鼠標很長時間沒移動的時候,我可不能夠偷偷下載兩張圖片?在用戶目前沒有進行大量運算操做的時候,我可不能夠偷偷下載兩張圖片?當用戶當前在一個很精簡的登錄界面的時候,我可不能夠偷偷下載他登錄成功跳轉到的頁面的幾張圖片?等等等等
懶加載
的深層次核心在於:按需
, 按需這個詞已經被深深入在我腦子裏了. 如今回想起來,不少不少優化方式都是圍繞着按需來展開的. 按需加載Js
,按需加載圖片
等等
首先,咱們必須保證項目第一時間的加載速度,能讓用戶在最短的時間內看到頁面和內容.
其次,儘可能保證當前頁面的精簡程度,不去作無心義的加載. 只有當用戶真正須要時,咱們才展示給他.
預加載:
優勢:若是提早下好了圖片,等到這張圖片須要用到時,能夠秒開.
缺點:下載圖片的時候會影響項目的加載完成時間,會影響項目運行的流暢程度
懶加載在於:
優勢: 保證用戶加載的項目是最精簡的,最快的, 所下載資源是最少的
缺點: 若是用戶的操做觸發了懶加載,那麼須要等待資源下載到完成的時間,同時資源下載期間,操做流暢度下降
說到底,項目的優化是沒有銀彈的,這一部分的高效極可能致使另外一部分的低效.A項目的優化方法照搬來B項目可能一文不值. 因此咱們切圖崽們能作的,就是深入理解這些技術的原理,而且在項目中吸取經驗,只有深入地理解了各項技術的優劣,只有深入的理解了用戶的需求以及行爲習慣,才能針對特定的項目,特定的場景,進行最適合的處理.