web前端圖片極限優化策略

  隨着web的發展，網站資源的流量也變得愈來愈大。據統計，60%的網站流量均來自網站圖片，可見對圖片合理優化能夠大幅影響網站流量，減少帶寬消耗和服務器壓力。

1、現有web圖片格式

咱們先來看下如今經常使用的web圖片的格式：

圖片格式	支持透明	動畫支持	壓縮方式	瀏覽器支持	相對原圖大小	適應場景
baseline-jpeg	不支持	不支持	有損	全部	由畫質決定	全部通用場景
progressive-jpeg	不支持	不支持	有損	全部	由畫質決定	全部通用場景, 漸進式加載
gif	支持	支持	無損	全部	由幀數和每幀圖片大小決定	簡單顏色，動畫
png	支持	不支持	無損	全部	由png色值位數決定	須要透明時
webp	支持	不支持	有損	Chrome、Opera	由壓縮率決定	複雜顏色及形狀，瀏覽器平臺可預知
apng	支持	支持	無損	Firefox、Safari、iOS Safari	由每幀圖片決定	須要半透明效果的動畫
svg	支持	支持	無損	全部(IE8以上)	由內容和特效複雜度決定	簡單圖形，須要良好的放縮體驗，須要動態控制圖片特效
bpg	支持	支持	有損	不支持，須要js解碼	由畫質決定	jpeg上須要極限優化的場景

幾種文件格式的特色概述

• baseline-jpeg 這種類型的JPEG文件存儲方式是按從上到下的掃描方式，把每一行順序的保存在JPEG文件中。打開這個文件顯示它的內容時，數據將按照存儲時的順序從上到下一行一行的被顯示出來，直到全部的數據都被讀完，就完成了整張圖片的顯示。若是文件較大或者網絡下載速度較慢，那麼就會看到圖片被一行行加載的效果，這種格式的JPEG沒有什麼優勢，所以，通常都推薦使用Progressive JPEG

• preogressive-jpeg 和Baseline一遍掃描不一樣，Progressive JPEG文件包含屢次掃描，這些掃描順尋的存儲在JPEG文件中。打開文件過程當中，會先顯示整個圖片的模糊輪廓，隨着掃描次數的增長，圖片變得愈來愈清晰。這種格式的主要優勢是在網絡較慢的狀況下，能夠看到圖片的輪廓知道正在加載的圖片大概是什麼。 __這兩種jpeg格式文件的效果對好比下：

  jpeg優點： 很是通用，JPEG在色調及顏色平滑變化的相片或是寫實繪畫（painting）上能夠達到它最佳的效果。

  jpeg劣勢： 它並不適合於線條繪圖（drawing）和其餘文字或圖示（iconic）的圖形,由於它的壓縮方法用在這些圖形的型態上,會獲得不適當的結果；

• gif GIF(Graphics Interchange Format)的原義是「圖像互換格式」，GIF文件的數據，是一種基於LZW算法(串表壓縮算法)連續色調的無損壓縮格式。是目前web網頁中十分經常使用的一種動畫文件格式。 優點：

  1. 優秀的壓縮算法使其在必定程度上保證圖像質量的同時將體積變得很小
  2. 可插入多幀,從而實現動畫效果
  3. 可設置透明色以產生對象浮現於背景之上的效果

  劣勢： 　因爲採用了8位壓縮,最多隻能處理256種顏色（2的8次方）,故不宜應用於真彩圖像。

• png png文件分爲png8(8位透明png)、png24(256色png)、png32(多階透明png)，png的有點在於使用位圖實現web上的透明圖片，以實現比較好的體驗。

  優點：

  • 支持256色調色板技術以產生小體積文件
  • 最高支持48位真彩色圖像以及16位灰度圖像。
  • 支持Alpha通道的半透明特性。
  • 支持圖像亮度的gamma校訂信息。- 支持存儲附加文本信息,以保留圖像名稱、做者、版權、創做時間、註釋等信息。
  • 使用無損壓縮。
  • 漸近顯示和流式讀寫,適合在網絡傳輸中快速顯示預覽效果後再展現全貌。
  • 使用CRC循環冗餘編碼防止文件出錯。
  • 最新的PNG標準容許在一個文件內存儲多幅圖像。

  劣勢：

  • 但也有一些軟件不能使用適合的預測，生成的文件較大(IE6只支持PNG8)

• webp

  目前移動端Android4.0以上、PC端chorme 10+（14 ~ 16 有渲染bug）、opera 11+ 、safri均支持webp格式圖片。 WEBP與JPG相比較，編碼速度慢10倍，解碼速度慢1.5倍，而絕大部分的網絡應用中，圖片都是靜態文件，因此對於用戶使用只須要關心解碼速度便可。但實際上，webp雖然會增長額外的解碼時間，可是因爲減小了文件體積，縮短了加載的時間，實際上文件的渲染速度反而變快了。

  圖片加載測試樣例

  webp上目前可行的應用場景：

  • 1.客戶端軟件，內嵌了基於Chromium的webview，這類瀏覽器中應用的網頁是能夠徹底使用webp格式，提高加載渲染速度，不考慮兼容。
  • 2.用node-webkit開發的程序，用webp能夠減小文件包的體積。
  • 3.移動應用 或 網頁遊戲 ,界面須要大量圖片,能夠嵌入webp的解碼包,可以節省用戶流量，提高訪問速度

  優點：

  • 對於png圖片,webp比png小了45%,可是缺點是你壓縮的時候須要的時間更久了；

  劣勢：

  • 兼容性不太好, 只有opera,和chrome支持;

• apng

  簡單來說apng格式圖片使用多個單張png鏈接起來的動畫圖片格式，支持全透明通道動畫。相比於gif動畫，沒有毛刺，質量更高，但目前支持的瀏覽器並不徹底。能夠去can i use查看其兼容性。目前可用性相對較低，適用於對動畫質量要求很高的狀況。

• svg 是一種矢量圖片，支持透明，縮放，動畫，除了android 2.3的手機，其它場景都支持，是一種比較好的圖片代替方案。 優點：

  • 矢量圖形，不受像素影響——SVG的這個特性使得它在不一樣的平臺或者媒體下表現良好，不管屏幕分辨率如何
  • SVG對動畫的支持較好；其DOM結構能夠被其特定語法或者Javascript控制，從而輕鬆的實現動畫
  • Javascript能夠徹底控制SVG Dom 元素
  • SVG的結構是 XML，其可訪問性（盲文、聲音朗讀等）、可操做性、可編程性、可被CSS樣式化完勝Canvas。另外，其支持 ARIA 屬性，使其如虎添翼。

  劣勢：

  • DOM比正常的圖形慢，並且若是其結點多而雜，就更慢了
  • 不適合網頁遊戲等；固然，咱們能夠結合 Canvas + SVG來實現

• bpg

  http://bellard.org/bpg/ 圖片畫質比較 性能測試對比

  BPG (Better Portable Graphics) 是一個新的圖片格式。用來代替jpeg和webp的方案。這種格式主要有如下特色 優點：

  • 高壓縮比。在畫質相同的狀況下比jpeg小的多
  • 使用一個很小的js解碼器就能夠被瀏覽器支持
  • 基於高清視頻壓縮標準 (HEVC) 一個子集開發
  • 支持和jpeg相同的色值，而且在有損壓縮的通知支持透明，
  • 單通道支持8到14位色值區域
  • 支持有損壓縮
  • 能夠添加更多的元數據編碼
  • 支持動畫
  • 相近畫質前提下比webp更小

  性能：

  • 根據mozilla的研究，bpg使用的HEVC編碼比原生的HEVC性能更好，由於BPG的頭部比HEVC的頭部更小
  • 支持4:2:2和4:2:0的色值設置
  • BPG能夠用於硬件上支持HEVC編解碼器

  這種圖片格式目前尚未被瀏覽器支持，須要js解碼，但其優點很是明顯。

  另外還有mozjpg、sharpP的圖片格式，因爲目前仍在起步階段，這裏暫不介紹了，有興趣的能夠去跟進了解下。

2、前端的圖片優化方案

1. 使用base64編碼代替圖片

   場景：適用於圖片大小小於2KB，頁面上引用圖片總數很少的狀況 原理：將圖片轉換爲base64編碼字符串inline到頁面或css中 優點：減小http的請求次數，並能夠放到後臺數據庫中，只傳輸字符串，有較多的構建工具能夠直接實現 劣勢：這種方法僅限於圖片總數較少，並且圖片大小小於2KB的狀況。不然圖片字符串會變得很長很長

2. 合併圖片sprite(雪碧圖)

   場景：任何用到頁面圖片的場景 原理：將多個頁面上用到的背景圖片合併成一個大的圖片在頁面中引用 優點：能夠有效的較少請求個數，並且，而不影響開發體驗，使用構建插件能夠作到對開發者透明。適用於頁面圖片多且豐富的場景。 劣勢：生成的圖片體積較大，減小請求個數同時也增長了圖片大小，不合理拆分將不利於並行加載

3. 使用css、svg、canvas或iconfont代替圖片

   css代替圖片 場景：適用於移動端或較高級的瀏覽器，並且繪製的圖案較爲簡單。 原理：css方式能夠用來繪製相對簡單的團來代替圖片，通常使用before或者after僞元素來豐富圖案的複雜度。 優點：具備實現簡單，圖片體積小的特色，能夠實現簡單的動態效果 劣勢：也受限於css的兼容性特色，繪製複雜圖案困難

   svg的描述和適用場景上文已說明。

   canvas代替圖片 場景：須要高性能的圖片或動畫 原理：適用html5的canvas元素繪製建立圖片 優點：整個就是畫2D圖形時，頁面渲染性能比較高，頁面渲染性能受圖形複雜度影響小，性能只受圖形的分辨率的影響，畫出來的圖形能夠直接保存爲 .png 或者 .jpg的圖形，適合於畫光柵圖像或者不規則圖形 劣勢：沒有dom操做，必須依賴定時器，文字渲染性能差，不能添加描述(title屬性什麼的)，兼容性限制

   iconfont是一種web字體來代替圖片的解決方案： 場景：代替頁面上色彩單一的圖片 優點：兼容性好，應用廣，目前使用也很普遍 劣勢：可是因爲字體的顏色設置單一，只能用於代替顏色單一的圖片，對於色彩複雜的圖片，iconfont處理起來比較困難

4. 響應式圖片

   場景：不一樣終端對同一個圖片需求不同，能夠根據終端加載不一樣的圖片來節省不必的流量 原理：經過picture元素，picturefill或平臺判斷來爲不一樣終端平臺輸出不一樣的圖片 優點：減小不必的圖片加載，靈活控制，慢速用戶加載小圖片不至於加載失敗，移動端不必加載大尺寸圖片等，能夠經過不一樣方式兼容全部瀏覽器 劣勢：沒法避免圖片的加載過程，圖片自己沒優化

5. 圖片壓縮

   場景：在不得不加載圖片的前提下，要進一步提高優化效果，只能經過有損或無損壓縮來減小圖片的大小。 原理：對圖片進行無損、有損壓縮，轉爲壓縮後圖片來實現 優點：減小圖片加載流量，效果比較明顯 劣勢：服務器和瀏覽器壓力增大，並且服務器須要額外的服務支持

6. 更好的圖片格式

   場景：以前說到webp、bpg、sharpP等新圖片格式具備更好的壓縮比，可使用這類新型的圖片來代替原始圖片 原理：對圖片格式轉換，在畫質能夠接受的狀況下達到更好的壓縮比效果 優點：減小圖片加載流量，效果比較明顯 劣勢：服務器和瀏覽器壓力增大，並且服務器須要額外的服務支持，格式轉換要考慮瀏覽器的兼容性

3、圖片壓縮

壓縮圖片方式比較多，這裏不一一列出，例以下面的部分工具平臺：

Kraken (Web) 主頁： https://kraken.io/

智圖 主頁： http://zhitu.tencent.com/ 支持原圖png轉爲jpeg和webp(目前不支持bpg)，並提供各類壓縮比壓縮，目前在tx內部普遍使用。

目前bpg格式圖片也有部分公司在試用。這方面也能夠嘗試下。

4、小結

  上面提供了web圖片的一些格式特色和圖片優化的可行方案，具體的場景須要考慮選擇不一樣的方式來進行優化。固然常見的優化思路爲：頁面靜態資源圖片使用css，canvas，svg，iconfont，sprite，base64來優化，後臺返回的數據資源圖片則經過響應式、圖片壓縮來優化，同時儘量考慮使用新的更高壓縮比的圖片來作圖片轉化。例如webp、bpg

google image rearch 連接

  原文連接： https://ouvens.github.io/frontend-weboptimize/2015/11/17/front-end-image-optmize.html