談談Web應用中的圖片優化技巧及反思

時間 2019-11-08

標籤談談 web 應用圖片優化技巧反思欄目 HTML 简体版

原文原文鏈接

這篇文章，咱們將一塊兒探討，web應用中能對圖片進行什麼樣的優化，以及反思一些「負優化」手段javascript

1、爲何要對圖片進行優化

對於大多數前端工程師來講，圖片就是UI設計師(或者本身)切好的圖，你要作的只是把圖片丟進項目中，而後用以連接的方式呈如今頁面上，並且咱們也常常把精力放在項目的打包優化構建上，如何分包，如何抽取第三方庫........有時咱們會忘了，圖片纔是一個網站最大頭的那塊加載資源(見下圖)，雖然圖片加載能夠不不阻礙頁面渲染，但優化圖片，絕對可讓網站的體驗提高一個檔次。css

2、從圖片大小開始優化

壓縮圖片可使用統一的壓縮工具 — imagemin，它是一款能夠集成多個壓縮庫的工具，支持jpg，png，webp等等格式的圖片壓縮，好比pngquant，mozjpeg等等，做爲測試用途，咱們能夠直接安裝imagemin-pngquant來嘗試png圖片的壓縮:html

PNG壓縮

npm install imagemin
    npm install imagemin-pngquant

這裏先安裝imagemin庫，再安裝對應的png壓縮庫前端

const imagemin = require('imagemin');
    const imageminPngquant = require('imagemin-pngquant');

    (async () => {
        await imagemin(['images/*.png'], 'build/images', {
            plugins: [
                imageminPngquant({ quality: '65-80' })
            ]
        });

        console.log('Images optimized');
    })();

咱們能夠在quailty一項決定壓縮比率，65-80貌似是一個在壓縮率和質量之間實現平衡的數值，騰訊AlloyTeam出品的gka圖片處理工具，一樣使用到了imagemin庫，他們默認也是使用65-80的選項：
gka代碼
用它壓縮一張png圖片，咱們看看效果如何:vue

這是壓縮前的：
java

這是壓縮後的：
webpack

從肉眼上幾乎看不出區別，但實際上減小了百分之77的體積！讀者能夠本身保存圖片進行比較。git

JPG/JPEG壓縮與漸進式圖片

壓縮jpg/jpeg圖片的方式與png相似，imagemin提供了兩個插件：jpegtrain和mozjpeg供咱們使用。通常咱們選擇mozjpeg，它擁有更豐富的壓縮選項:github

npm install imagemin-mozjpeg

const imagemin = require('imagemin');
    const imageminMozjpeg = require('imagemin-mozjpeg');

    (async () => {
        await imagemin(['images/*.jpg'], 'build/images', {
            use: [
                imageminMozjpeg({ quality: 65, progressive: true })
            ]
        });

        console.log('Images optimized');
    })();

注意到咱們使用了progressive: true選項，這能夠將圖片轉換爲漸進式圖片，關於漸進式圖片，它容許在加載照片的時候，若是網速比較慢的話，先顯示一個相似模糊有點小馬賽克的質量比較差的照片，而後慢慢的變爲清晰的照片：web

而相比之下，非漸進式的圖片(Baseline JPEG)則會老老實實地從頭至尾去加載：

張鑫旭大神的這篇文章，能夠幫你更好地瞭解二者的區別：
漸進式jpeg(progressive jpeg)圖片及其相關
簡單來講，漸進式圖片一開始就決定了大小，而不像Baseline圖片同樣，不斷地從上往下加載，從而形成屢次迴流，但漸進式圖片須要消耗CPU去屢次計算渲染，這是其主要缺點。
固然，交錯式png也能夠實現相應的效果，但目前pngquant沒有實現轉換功能，可是ps中導出png時是能夠設置爲交錯式的。

在真實項目中如何操做？

實際項目中，總不能UI丟一個圖過來你就跑一遍壓縮代碼吧？幸虧imagemin有對應的webpack插件，在webpack遍地使用的今天，咱們能夠輕鬆實現批量壓縮：

npm install imagemin-webpack-plugin

先安裝imagemin-webpack-plugin

import ImageminPlugin from 'imagemin-webpack-plugin'
    import imageminMozjpeg from 'imagemin-mozjpeg'

    module.exports = {
      plugins: [
        new ImageminPlugin({
          plugins: [
            imageminMozjpeg({
              quality: 100,
              progressive: true
            })
          ]
        })
      ]
    }

接着在webpack配置文件中，引入本身須要的插件，使用方法徹底相同。具體可參考github的文檔imagemin-webpack-plugin

3、經過圖片按需加載減小請求壓力

圖片按需加載是個老生常談的話題，傳統作法天然是經過監聽頁面滾動位置，符合條件了再去進行資源加載，咱們看看現在還有什麼方法能夠作到按需加載。

使用強大的IntersectionObserver

IntersectionObserver提供給咱們一項能力：能夠用來監聽元素是否進入了設備的可視區域以內，這意味着：咱們等待圖片元素進入可視區域後，再決定是否加載它，畢竟用戶沒看到圖片前，根本不關心它是否已經加載了。
這是Chrome51率先提出和支持的API，而在2019年的今天，各大瀏覽器對它的支持度已經有所改善(除了IE，全線崩~)：

廢話很少說，上代碼：
首先，假設咱們有一個圖片列表，它們的src屬性咱們暫不設置，而用data-src來替代：

<li>
  <img class="list-item-img" alt="loading" data-src='a.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-src='b.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-src='c.jpg'/>
</li>
<li>
  <img class="list-item-img" alt="loading" data-src='d.jpg'/>
</li>

這樣會致使圖片沒法加載，這固然不是咱們的目的，咱們想作的是，當IntersectionObserver監聽到圖片元素進入可視區域時，將data-src"還給"src屬性，這樣咱們就能夠實現圖片加載了:

const observer = new IntersectionObserver(function(changes) {
  changes.forEach(function(element, index) {
   // 當這個值大於0，說明知足咱們的加載條件了，這個值可經過rootMargin手動設置
    if (element.intersectionRatio > 0) {
      // 放棄監聽，防止性能浪費，並加載圖片。
      observer.unobserve(element.target);
      element.target.src = element.target.dataset.src;
    }
  });
});
function initObserver() {
  const listItems = document.querySelectorAll('.list-item-img');
  listItems.forEach(function(item) {
   // 對每一個list元素進行監聽
    observer.observe(item);
  });
}
initObserver();

運行代碼並觀察控制檯的Network，會發現圖片隨着可視區域的移動而加載，咱們的目的達到了。

這裏給出一個線上demo，供你們調試學習
(ps: 這裏額外介紹一個vue的圖片懶加載組件vue-view-lazy，也是基於IntersectionObserver實現的)。

仍是Chrome的黑科技——loading屬性

重新版本Chrome(76)開始，已經默認支持一種新的html屬性——loading，它包含三種取值:auto、lazy和eager(ps: 以前有文章說是lazyload屬性，後來chrome的工程師已經將其肯定爲loading屬性，緣由是lazyload語義不夠明確)，咱們看看這三種屬性有什麼不一樣：

auto：讓瀏覽器自動決定是否進行懶加載，這其中的機制尚不明確。

lazy：明確地讓瀏覽器對此圖片進行懶加載，即當用戶滾動到圖片附近時才進行加載，但目前沒有具體說明這個「附近」具體是多近。

eager：讓瀏覽器馬上加載此圖片，也不是此篇文章關注的功能。

咱們能夠經過chrome的開發工具看看這個demo中的圖片加載方式，咱們把上一個demo中的js腳本都刪掉了，只用了loading=lazy這個屬性。接着，勾選工具欄中的Disabled Cache後仔細觀察Network一欄，細心的人應該會發現，一張圖片被分爲了兩次去請求！第一次的狀態碼是206，第二次的狀態碼纔是200，如圖所示：

這個現象跟chrome的lazy-loading功能的實現機制有關：

首先，瀏覽器會發送一個預請求，請求地址就是這張圖片的url，可是這個請求只拉取這張圖片的頭部數據，大約2kb，具體作法是在請求頭中設置range: bytes=0-2047，

而從這段數據中，瀏覽器就能夠解析出圖片的寬高等基本維度，接着瀏覽器立馬爲它生成一個空白的佔位，以避免圖片加載過程當中頁面不斷跳動，這很合理，總不能爲了一個懶加載，讓用戶犧牲其餘方面的體驗吧？這個請求返回的狀態碼是206，代表：客戶端經過發送範圍請求頭Range抓取到了資源的部分數據，詳細的狀態碼解釋能夠看看這篇文章

而後，在用戶滾動到圖片附近時，再發起一個請求，完整地拉取圖片的數據下來，這個纔是咱們熟悉的狀態碼200請求。

能夠預測到，若是之後這個屬性被廣泛使用，那一個服務器要處理的圖片請求鏈接數可能會變成兩倍，對服務器的壓力會有所增大，但時代在進步，咱們能夠依靠http2多路複用的特性來緩解這個壓力，這時候就須要技術負責人權衡利弊了

要注意，使用這項特性進行圖片懶加載時，記得先進行兼容性處理，對不支持這項屬性的瀏覽器，轉而使用JavaScript來實現，好比上面說到的IntersectionObserver：

if ("loading" in HTMLImageElement.prototype) {
      // 沒毛病
    } else {
      // .....
    }

還能夠作到錦上添花！

以上介紹的兩種方式，其實最終實現的效果是類似的，但這裏還有個問題，當網速慢的時候，圖片還沒加載完以前，用戶會看到一段空白的時間，在這段空白時間，就算是漸進式圖片也沒法發揮它的做用，咱們須要更友好的展現方式來彌補這段空白，有一種方法簡單粗暴，那就是用一張佔位圖來頂替，這張佔位圖被加載過一次後，便可從緩存中取出，無須從新加載，但這種圖片會顯得有些千篇一概，並不能很好地作到preview的效果。
這裏我向你們介紹另外一種佔位圖作法——css漸變色背景，原理很簡單，當img標籤的圖片還沒加載出來，咱們能夠爲其設置背景色，好比:

<img src="a.jpg" style="background: red;"/>

這樣會先顯示出紅色背景，再渲染出真實的圖片，重點來了，咱們此時要借用工具爲這張圖片"配製"出合適的漸變背景色，以達到部分preview的效果，咱們可使用https://calendar.perfplanet.com/2018/gradient-image-placeholders/ 這篇文章中推薦的工具GIP進行轉換，這裏附上在線轉換的地址https://tools.w3clubs.com/gip/
通過轉換後，咱們獲得了下面這串代碼：

background: linear-gradient(
      to bottom,
      #1896f5 0%,
      #2e6d14 100%
    )

最終效果以下所示：

4、響應式圖片的實踐

咱們常常會遇到這種狀況：一張在普通筆記本上顯示清晰的圖片，到了蘋果的Retina屏幕或是其餘高清晰度的屏幕上，就變得模糊了。

這是由於，在一樣尺寸的屏幕上，高清屏能夠展現的物理像素點比普通屏多，好比Retina屏，一樣的屏幕尺寸下，它的物理像素點的個數是普通屏的4倍(2 * 2)，因此普通屏上顯示清晰的圖片，在高清屏上就像是被放大了，天然就變得模糊了，要從圖片資源上解決這個問題，就須要在設備像素密度爲2的高清屏中，對應地展現一張兩倍大小的圖。

而一般來說，對於背景圖片，咱們可使用css的@media進行媒體查詢，以決定不一樣像素密度下該用哪張倍圖，例如：

.bg {
        background-image: url("bg.png");
        width: 100px;
        height: 100px;
        background-size: 100% 100%;
    }
    @media (-webkit-min-device-pixel-ratio: 2),(min-device-pixel-ratio: 2)
    {
        .bg {
            background-image: url("bg@2x.png") // 尺寸爲200 * 200的圖
        }
    }

這麼作有兩個好處，一是保證高像素密度的設備下，圖片仍能保持應有的清晰度，二是防止在低像素密度的設備下加載大尺寸圖片形成浪費。

那麼如何處理img標籤呢？

咱們可使用HTML5中img標籤的srcset來達到這個效果，看看下面這段代碼：

<img width="320"  src="bg@2x.png" srcset="bg.png 1x;bg@2x.png 2x"/>

這段代碼的做用是：當設備像素密度，也就是dpr(devicePixelRatio)爲1時，使用bg.png，爲2時使用二倍圖bg@2x.png，依此類推，你能夠根據須要設置多種精度下要加載的圖片，若是沒有命中，瀏覽器會選擇最鄰近的一個精度對應的圖片進行加載。
要注意：老舊的瀏覽器不支持srcset的特性，它會繼續正常加載src屬性引用的圖像。

5、安全地使用WebP圖片

WebP的優點這裏再也不贅述，簡單來講就是：一樣尺寸的圖片，WebP能保證比未壓縮過的png、jpg、gif等格式的圖片減小百分之40-70(甚至90)的比例，且保證較高的質量，更能夠支持顯示動態圖和透明通道。

但目前WebP的兼容性並不太好：

但咱們能夠經過兩種方式，對暫未支持webp的瀏覽器進行兼容：

picture結合source標籤

HTML5的picture標籤，能夠理解爲相框，裏面能夠支持多種格式的圖片，並保留一張默認底圖：

<picture>
      <source srcset="bg.webp" type="image/webp">
      <source srcset="bg.jpg" type="image/jpeg"> 
      <img src="bg.jpg" alt="背景圖">
    </picture>

有了這段代碼，瀏覽器會自動根據是否支持webp格式來選擇加載哪張圖片，若不支持，則會顯示bg.jpg，若是瀏覽器連picture都不支持，那麼會fallback到默認的img圖片，這是必不可少的一個選項。

並且這裏要注意source的放置順序，若是把jpg放在第一位，webp放在第二位，即便瀏覽器支持webp，那也會選擇加載jpg圖片。

藉助cdn服務自動判斷

目前，有些圖片cdn服務能夠開啓自動兼容webp的模式，即支持webp的瀏覽器則將原圖轉換爲webp圖片並返回，不然直接返回原圖。實現這個功能的原理是，根據瀏覽器發起的請求頭中的Accept屬性中是否包含webp格式來判斷：

有則說明瀏覽器支持webp格式，這對開發者來講多是最簡單的兼容方案，可是依賴於後端服務。

接下來，談一談我認爲應該反思的負優化手段：

6、對Base64Url的反思

首先複習一下Base64的概念，Base64就是一種基於64個可打印字符來表示二進制數據的方法，編碼過程是從二進制數據到字符串的過程，在web應用中咱們常常用它來作啥呢——傳輸圖片數據。HTML中，img的src和css樣式的background-image均可以接受base64字符串，從而在頁面上渲染出對應的圖片。正是基於瀏覽器的這項能力，不少開發者提出了將多張圖片轉換爲base64字符串，放進css樣式文件中的「優化方式」，這樣作的目的只有一個——減小HTTP請求數。但實際上，在現在的應用開發中，這種作法大多數狀況是「負優化」效果，接下來讓咱們細數base64 Url的「罪狀」：

第1、讓css文件的體積失去控制

當你把圖片轉換爲base64字符串以後，字符串的體積通常會比原圖更大，通常會多出接近3成的大小，若是你一個頁面中有20張平均大小爲50kb的圖片，轉它們爲base64後，你的css文件將可能增大1.2mb的大小，這樣將嚴重阻礙瀏覽器的關鍵渲染路徑：

css文件自己就是渲染阻塞資源，瀏覽器首次加載時若是沒有所有下載和解析完css內容就沒法進行渲染樹的構建，而base64的嵌入則是雪上加霜，這將把原先瀏覽器能夠進行優化的圖片異步加載，變成首屏渲染的阻塞和延遲。

或許有人會說，webpack的url-loader能夠根據圖片大小決定是否轉爲base64(通常是小於10kb的圖片)，但你也應該擔憂若是頁面中有100張小於10kb的圖片時，會給css文件增長多少體積。

第2、讓瀏覽器的資源緩存策略功虧一簣

假設你的base64Url會被你的應用屢次複用，原本瀏覽器能夠直接從本地緩存取出的圖片，換成base64Url，將形成應用中多個頁面重複下載1.3倍大小的文本，假設一張圖片是100kb大小，被你的應用使用了10次，那麼形成的流量浪費將是:(100 1.3 10) - 100 = 1200kb。

第3、低版本瀏覽器的兼容問題

這是比較次要的問題，dataurl在低版本IE瀏覽器，好比IE8及如下的瀏覽器，會有兼容性問題，詳細狀況能夠參考這篇文章。

第4、不利於開發者工具調試與查看

不管哪張圖片，看上去都是一堆沒有意義的字符串，光看代碼沒法知道原圖是哪張，不利於某些狀況下的比對。

說了這麼多，有人可能不服氣，既然這種方案缺點這麼多，爲啥它會從之前就被普遍使用呢？這要從早期的http協議特性提及，在http1.1以前，http協議還沒有實現keep-alive，也就是每一次請求，都必須走三次握手四次揮手去創建鏈接，鏈接完又丟棄沒法複用，而即便是到了http1.1的時代，keep-alive能夠保證tcp的長鏈接，不須要屢次從新創建，但因爲http1.1是基於文本分割的協議，因此消息是串行的，必須有序地逐個解析，因此在這種請求「昂貴」，且早期圖片體積並非特別大，用戶對網頁的響應速度和體驗要求也不是很高的各類前提結合下，減小圖片資源的請求數是能夠理解的。

可是，在愈來愈多網站支持http2.0的前提下，這些都不是問題，h2是基於二進制幀的協議，在保留http1.1長鏈接的前提下，實現了消息的並行處理，請求和響應能夠交錯甚至能夠複用，多個並行請求的開銷已經大大下降，我已經不知道還有什麼理由繼續堅持base64Url的使用了。