摘要：年月日，開始讓支持無(wú)損壓縮和透明色通道的功能，而在年月日的引用實(shí)做中正式支持。根據(jù)較早的測(cè)試，的無(wú)損壓縮比網(wǎng)絡(luò)上找到的檔少了的文件大小，即使這些檔在使用和處理過(guò)，還是可以減少的文件大小。這兩種緩存方式是可以同時(shí)存在的。

??Webp推出那年，我剛剛考上高中。轉(zhuǎn)眼間，大學(xué)畢業(yè)將近一年，我依舊是那個(gè)青蔥少年！就像Webp一樣，還是那么年輕，時(shí)至今日尚未嶄露頭角，原因是各大瀏覽器對(duì)它的兼容依舊不是那么的友好。IE爸爸甚至至今都沒(méi)有要支持它的跡象。

維基百科：WebP最初在2010年發(fā)布，目標(biāo)是減少文件大小，但達(dá)到和JPEG格式相同的圖片品質(zhì)，希望能夠減少圖片檔在網(wǎng)絡(luò)上的發(fā)送時(shí)間。 2011年11月8日，Google開始讓W(xué)ebP支持無(wú)損壓縮和透明色（alpha通道）的功能，而在2012年8月16日的引用實(shí)做libwebp 0.2.0中正式支持。根據(jù)Google較早的測(cè)試，WebP的無(wú)損壓縮比網(wǎng)絡(luò)上找到的PNG檔少了45％的文件大小，即使這些PNG檔在使用pngcrush和PNGOUT處理過(guò)，WebP還是可以減少28％的文件大小。

??簡(jiǎn)單來(lái)說(shuō)，Webp格式是一種圖片格式，它有更優(yōu)秀的圖片壓縮算法，并且能實(shí)現(xiàn)肉眼難以辨識(shí)的質(zhì)量差異，同時(shí)它還支持有損無(wú)損兩種壓縮模式。

??由于是谷歌的親兒子，所以安卓原生瀏覽器對(duì)Webp的支持還是比較樂(lè)觀的，Chrome桌面版和安卓版的支持也都比較好。國(guó)內(nèi)的瀏覽器也不同程度的對(duì)Webp做了很多支持。我去Can I Use上截了張圖過(guò)來(lái)：

??由此可見，市面上占有率比較大的瀏覽器對(duì)Webp的支持還是很不錯(cuò)的，所以有必要使用起來(lái)。其實(shí)是之前無(wú)意間發(fā)現(xiàn)某寶和某東在使用，所以也想在這塊做一些優(yōu)化。

??有圖有真相，先看看優(yōu)化后的效果吧。

??使用前：

??使用后：

??可以很明顯的看到，僅僅這八張并不是特別大的圖片，便節(jié)省了59.3K的流量。下載時(shí)間也有明顯的縮短。如果你的web項(xiàng)目是類似于某寶某東那樣有著大量圖片，那么這塊節(jié)省的流量可想而知！

??市面上有一些圖片格式轉(zhuǎn)換工具，我這里就不一一列舉了。這里要講的可能是比較簡(jiǎn)單的一種使用方式，因?yàn)槲覀兊膱D片等資源文件托管在阿里云oss上，它只需要你在請(qǐng)求url里面帶個(gè)參數(shù)，就會(huì)自動(dòng)返回你想要的圖片格式。各位看官，如果你們的情況和我不一樣，可能需要自己對(duì)圖片做一部分處理或者別的云存儲(chǔ)也有類似的解決方案。

??好的，言歸正傳，接下來(lái)說(shuō)說(shuō)我的解決方案。我們的Web是利用Vue實(shí)現(xiàn)的前后端同構(gòu)的，所以存在服務(wù)端渲染和客戶端渲染兩種情況，這就要求我們要分別在服務(wù)端和客戶端對(duì)瀏覽器是否支持Webp作出判斷，如果瀏覽器支持，就去oss取webp格式的圖片，否則繼續(xù)使用原本圖片格式。

??我所采取的方法是在封裝網(wǎng)絡(luò)請(qǐng)求的時(shí)候，做了一步判斷，然后把是否支持Webp的變量放到了環(huán)境變量中。由于網(wǎng)絡(luò)請(qǐng)求需要同時(shí)支持客戶端和服務(wù)端，所以我采用的是axios并自己做了一層封裝。

//  封裝axios
createRequest = (req) => {
    // 如果在客戶端創(chuàng)建
    if (process.client) {
        process.env.supportWebp = document.createElement("canvas").toDataURL("image/webp").indexOf("data:image/webp") === 0
    } else {
     //  從服務(wù)端檢測(cè)客戶端是否支持webp
        if (req && req.headers) {
            process.env.supportWebp = req.headers.accept.indexOf("image/webp") > -1
        }else{
            process.env.supportWebp = false
        }
    }
}

??其實(shí)無(wú)論是客戶端還是服務(wù)端，都可以采用判斷accept里面是否帶有"image/webp"的方式，但是有些童鞋說(shuō)判斷accept方式有些瀏覽器不準(zhǔn)確，所以我們?cè)诳蛻舳瞬捎幂^為穩(wěn)妥的方式去判斷。

??每個(gè)人的框架或者環(huán)境可能不同，所以代碼不一定能照搬，只需理解這部分的思想：根據(jù)不同的環(huán)境判斷瀏覽器是否支持Webp。

??在使用的時(shí)候，對(duì)于頁(yè)面中的img，我寫了一個(gè)過(guò)濾器:

export function judgeWebp (src) {
  if(process.env.supportWebp + "" === "true"){
    return src + "?x-oss-process=image/format,webp"
  }
  return  src
}
const filters = {
  //......,
  judgeWebp
}
Object.keys(filters).forEach(key => {
  Vue.filter(key, filters[key])
})

??對(duì)于背景圖片，style動(dòng)態(tài)綁定似乎是不能使用過(guò)濾器的，所以采用計(jì)算屬性的方式實(shí)現(xiàn)。各位看官如果有更好的方法歡迎提出來(lái)。

??到此為止，我們可以根據(jù)瀏覽器是否支持webp來(lái)獲取到不同格式的圖片了。另外，有些社區(qū)也有過(guò)利用第三方polyfill來(lái)實(shí)現(xiàn)瀏覽器兼容Webp的方案。但是似乎并不是那么的流行，追求穩(wěn)妥的情況下，我這里暫不使用，如果你有過(guò)類似的實(shí)踐，歡迎與我分享。

??webp的分享就到這里，接下來(lái)我們簡(jiǎn)單聊聊http緩存。http緩存大致分為兩類，一類是強(qiáng)制緩存，另一類叫對(duì)比緩存。這兩種緩存方式是可以同時(shí)存在的。強(qiáng)制緩存，一聽這名字就威武霸氣，所以它的優(yōu)先級(jí)也是比較高的，就是說(shuō)，如果強(qiáng)制緩存生效，對(duì)比緩存就不再執(zhí)行。另一個(gè)區(qū)別點(diǎn)就是，強(qiáng)制緩存如果生效，就不再和服務(wù)器交互了，對(duì)比緩存則需要每次都和服務(wù)器交互協(xié)商。

??先說(shuō)強(qiáng)制緩存。瀏覽器向服務(wù)器請(qǐng)求數(shù)據(jù)，返回的header頭中會(huì)攜帶緩存規(guī)則。體現(xiàn)在Expires和Cache-Control這兩個(gè)屬性當(dāng)中。

??Expires是HTTP 1.0的東西，可以說(shuō)是歷史遺留產(chǎn)物了。它的值是到期時(shí)間，如果請(qǐng)求時(shí)間小于這個(gè)到期時(shí)間，就會(huì)采用緩存。我們一眼就能發(fā)現(xiàn)這個(gè)邏輯其實(shí)意義并不大，而且如果服務(wù)端和客戶端時(shí)間不一致，會(huì)有誤差產(chǎn)生。

??Cache-Control似乎是為彌補(bǔ)Expires的天生缺陷而生的。它倆如果同時(shí)存在，Expires則不會(huì)生效。它的取值可以為：

??這里需要區(qū)別no-store和no-cache，謹(jǐn)記no-store是不做緩存，而no-cache是使用對(duì)比緩存。似乎翻譯過(guò)來(lái)很像，但是實(shí)際效果差很多，對(duì)于no-store這種不緩存，除非特殊情況，我們一般不使用。

??我們?cè)倭牧膶?duì)比緩存。對(duì)比緩存主要分兩大塊，一塊兒是根據(jù)修改時(shí)間判斷緩存是否生效，另一塊是通過(guò)Etag（個(gè)人理解就是個(gè)hash值）來(lái)判斷。

??Last-Modified是存在于返回的header中的，顧名思義，它告訴我們這個(gè)資源的最后修改時(shí)間。當(dāng)瀏覽器再次發(fā)起請(qǐng)求的時(shí)候，會(huì)由If-Modified-Since帶著這個(gè)值到服務(wù)器去做對(duì)比，如果服務(wù)器發(fā)現(xiàn)這個(gè)值小于目前服務(wù)器上資源的Last-Modified，則會(huì)把新的文件返回，狀態(tài)碼200。如果大于等于則只返回?cái)y帶304狀態(tài)碼的請(qǐng)求，通知瀏覽器這個(gè)值尚未失效。

??它的缺點(diǎn)是這里的時(shí)間值只能精確到秒。

??Etag可以理解為服務(wù)器給資源打的hash值，就類似于我們使用構(gòu)建工具打包資源文件后面會(huì)跟一條常常的字符串一樣，它保證資源文件的唯一性。Etag隨response返回給瀏覽器，同理瀏覽器下一次請(qǐng)求會(huì)由If-None-Match攜帶Etag的值去到服務(wù)器作比對(duì)。如果發(fā)現(xiàn)這個(gè)值不存在，說(shuō)明本地的資源文件已經(jīng)失效，服務(wù)器返回新的資源文件給客戶端，狀態(tài)碼200。反之，返回304通知客戶端資源文件仍然生效。

??相較于對(duì)比最后修改時(shí)間的策略，它的優(yōu)點(diǎn)在于可以突破精確到秒的限制，另外如果我們有一些定期更新的文件，但是資源內(nèi)容不變，Etag的優(yōu)勢(shì)就更為明顯了。

??這里要提及的一點(diǎn)是，當(dāng)Last-Modified和Etag策略同時(shí)生效的時(shí)候，Etag的優(yōu)先級(jí)更高。

??本來(lái)是想記錄一下webp的，但是既然是優(yōu)化，就順便寫了寫http緩存這塊的內(nèi)容。除此之外，各位還可以根據(jù)實(shí)際情況合理配置cdn以及nginx等的緩存，以實(shí)現(xiàn)更好的用戶體驗(yàn)。優(yōu)化路上無(wú)止境，但愿我們都能往極致的方向去做。今天就聊到這兒，有什么說(shuō)錯(cuò)的地方還請(qǐng)各位看官批評(píng)指正，希望大家多多指教！