前端性能優化之路——圖片篇。

    本人是一名前端開發者，在公司負責目前負責信息流服務，爲五大手機廠商和各大App提供服務，天天的請求就是以億計算，加上咱們又作了SSP和DSP，就是相似於百度廣告聯盟，騰訊廣點通這種。接觸過的應該知道，因此前端優化一直是我頭痛的問題，不只要注重用戶體驗，同時要兼顧收益，有時候必須犧牲一些用戶體驗，可是做爲一名有思想的前端，仍是努力規避掉，但願能和從事相同業務的同窗一塊兒學習交流一下，話很少說，就來分享個人性能優化之路，有什麼不對的知識點，麻煩你們指出批評。

• 先附上基本的yahoo軍規——yahoo前端性能團隊總結的35條黃金定律
  

yahoo軍規把大部分的前端優化都提到了，而在js優化這一塊若是有興趣的額，推薦你們去看《 高性能javascript》,書裏講的很是詳細。https://segmentfault.com/a/1190000008481413

• web前端優化之圖片優化

Media Queries 調用高清背景圖

     國內手機發展迅速，用 retina顯示屏的愈來愈多，假如如今有一張圖片，有兩部手機，一部是普通顯示屏，一部是高清顯示屏，在一樣大小的屏幕上，高清顯示屏中的位圖會被放大，圖片會變得模糊。

      經過 devicePixelRatio的值，就能夠區分普通顯示屏和高清屏，當devicePixelRatio值等於1時（也就是最小值），那麼它普通顯示屏，當devicePixelRatio值大於1(一般是1.五、2.0)，那麼它就是高清顯示屏。這時候咱們可讓UI準備2套圖片，甚至是3套圖片，不一樣像素的圖利用媒體查詢結合 devicePixelRatio 能夠區分普通顯示屏和高清顯示屏，並給出了以下CSS設計方案： 

.css{/* 普通顯示屏(設備像素比例小於等於1.3)使用1倍的圖 */ 
    background-image: url(img_1x.png);
}
@media only screen and (-webkit-min-device-pixel-ratio:1.5){
.css{/* 高清顯示屏(設備像素比例大於等於1.5)使用2倍圖  */
    background-image: url(img_2x.png);
  }
}複製代碼

也能夠用less或者sass

bg-image($url)
  background-image: url($url + "@2x.png")
  @media (-webkit-min-device-pixel-ratio: 3),(min-device-pixel-ratio: 3)
    background-image: url($url + "@3x.png")
複製代碼

   若是省時間通用性高，就像咱們是服務端用nginx對圖片進行處理，想要什麼樣尺寸的圖片本身裁切,咱們提供了按比例縮放和自定尺寸的裁切方法，地址後拼接字符串就行。

http://image.uczzd.cn/12046251381056834816.jpg?id=0&from=export&width=800&height=600
複製代碼

• 使用更小更快更強，新一代圖片格式 WebP 
  

     WebP是谷歌在10年推出一種新型圖片格式，最先也是應用在谷歌產品中，谷歌發佈的Android Studio 2.3正式版中就包括對WebP支持的更新，在實測中，webp 格式比 jpg 格式減少約 20%。這對優化用戶體驗，減小CDN帶寬消耗有很好的效果，但並非全部瀏覽器都支持 webp ，因此爲了使用 webp，須要作一點兼容性的工做。  

     與其餘圖片格式相比，在肉眼沒法分辨圖片質量差別的狀況下，WebP的空間佔用是最小的，目前國內外各大互聯網公司都已經開始應用這一圖片格式。好比美團

     想實現首先是判斷，即識別單次訪問的來源瀏覽器是否支持 webp 格式，其次是執行，若是該瀏覽器支持，則將原圖替換爲 webp 格式，並返回。若是不支持，則顯示原格式圖片。http://caniuse.mojijs.com/Home/Html/item/key/webp/index.html

在識別階段，咱們有兩種方法：

1. Server 處理

• 經過 UAString 判斷瀏覽器支持狀況
  

 只要有請求，服務端就能拿到你的User-Agent信息，經過對瀏覽器進行分類，支持webp放在白名單裏，不支持的則爲黑名單。判斷爲白名單，則直接調用，返回webp格式圖片；反之，則顯示原圖。這種方式的優勢在於，只需按期維護白名單便可，邏輯簡單；缺點則在於不可擴展、不可測試、UA判斷會出現不許確的狀況。

• 讀取 JavaScript 種下的 cookie 判斷瀏覽器支持狀況  
  

 Server處理中的另外一種方式是經過讀取 JavaScript 種下的 cookie來實現判斷。這種方式的優勢是表現穩定，訪問速度更快，切換無壓力。但缺點是，頁面靜態化會致使用戶切換瀏覽器時不能自主更新，圖片服務失效。好比用戶用支持webp的瀏覽器A請求頁面，這時緩存的靜態頁面均使用webp圖片，但當該用戶使用不支持webp的瀏覽器B時，訪問網頁則會出現請求不到圖片的報錯。

• Client 處理
  

Client 處理，是美團云爲美團主站提供的處理方式。在這種處理方式中，瀏覽器端發送的beacon webp 請求後，經過檢測其加載狀況來斷定 webp 支持狀況，而後瀏覽器寫一個cookie。以後經過讀取瀏覽器cookie判斷是否支持webp，就能夠進行下一步替換操做了。

2.替換圖片過程當中也是有兩種處理方式：

• Server 處理
  

在 server 端處理的優勢是對下游開發者透明，缺點是靜態頁面的緩存數量會翻倍。

替換方式以下：

1. 生成 URL 的函數（ 好比 $deal->getImageUrl ) ，經過運行函數中直接實現替換
   
2. 對 varnish 靜態化的頁面，首先識別瀏覽器請求頭類型，而後將webp 和傳統 jpg 的各緩存一份兩份待處理。而後在生成 URL 的地方作替換。
   

• Client 處理
  

在 client 端處理能夠比較好地應對頁面靜態化的狀況，主要針對懶加載（非首屏）的圖片進行處理，直接經過修改懶加載器來實現。
對非懶加載的圖片暫時沒有特別好的辦法。目前，可用替換路徑的方式來處理。

Client 處理實際上效果也是不錯的，美團頁面裏90%以上的圖片都是懶加載的，基本上均可以知足需求。對於大多數用戶來講，採用Client 處理實現webp轉換是個不錯的選擇。

• tracking Pixel（像素追蹤）精準追蹤數據
  

     既然提到圖片這一塊，我有忍不住想扯寫些題外的tracking Pixel（像素追蹤），幾乎全部網站都會作數據的採集，上報統計。特別是咱們作SSP、DSP廣告這塊須要獲取例如

• 用戶使用的瀏覽器、操做系統、分辨率等。
  
•  用戶瀏覽行爲記錄，好比用戶網站上的點擊行爲、購買行爲等。
  
•  用戶在APP、WEB中停留時間、是否活躍等
  

      數據永遠說的是實話，數據證實一切可能。如facebook廣告投放的跨境電商朋友都會使用facebook Pixel(像素追蹤)以得到各環節的精準數據。這樣追蹤數據後，咱們才能投放廣告後銷量上去了，哪一個纔是效果最好的，哪一個效果很差，進而經過多個數據對比，對廣告進行合理的調整優化。

     國內搜狗、百度、360、新浪都是用這種tracking Pixel方法，實際就是利用1px 的圖片，在圖片地址後綴拼接你須要的信息參數，瀏覽器在請求任何資源的時候會發送當前系統的數據，好比瀏覽器信息，操做系統信息，做爲http請求頭送過去，他們就能統計了。

    爲何不用js請求統計？

並非全部的頁面都支持JS的！NoJSStats的實現機制就是網站分析中點擊流數據獲取的方式之一——Web Beacons，即在頁面中嵌入一個1像素的透明圖片，當該頁面被瀏覽時，圖片就會被請求加載，因而在後端的服務器日誌中就會記錄該圖片的請求日誌，這樣就能夠得到日誌記錄。

例如百度：

這是百度1px圖片地址： http://wn.pos.baidu.com/adx.php?複製代碼

var url = ["//eclick.baidu.com/se.jpg?", "type=fatalError", "data=1220", "mes=" + encodeURIComponent(e)].join("&"),    img = new Image;    img.src = url
百度在地址欄後拼接了不少參數，後端按照圖片後綴名生成對應的數據報表。複製代碼

                                                                                                    

本文引用@美團雲 提供的webP方法，感謝。