摘要：的圖像提供了該方案。使用的圖像和捕獲技術相結合我們能通過一個標簽實現圖像的自動響應化。調整元素當然不同的瀏覽器自動化調整圖片大小是可行的而自動化的確實不可能。

在Web開發社區，響應式圖片已經成為最大的挫敗之一。原因也很簡單：頁面平均大小產品能從去年的1MB達到了驚人的1.5MB。其中圖片大小的增長比例就占了頁面大小增長的60%或更多，并且這個比例還在不斷攀升。

絕大多數的頁面是可以降低頁面大小的，如果你借助基于設備寬度、像素密度和現代圖像格式（例如WebP）等優化條件的話。這些減重的方法可以加快載入時間，讓用戶參與更多、停留更長時間。不過這里不是爭論是否應該為不同的設備優化圖像，而是關于應該怎么去做。

理想情況下，我們應該繼續使用img標簽，然后瀏覽器會下載適配設備寬度、適配頁面布局的圖片。然而，這樣的功能其實并不存在。實現接近這種功能的方法之一是在javascript執行過程中改變img元素的src屬性，但超前的預解析器（或預加載）扼殺了它的可能性。

克服這個問題的第一步是創建一個基于標記的解決方案，該方案允許基于設備的功能來替換圖像的來源。隨著W3C響應式圖片交流社區創造的picture元素（盡管目前還沒有瀏覽器實現了它）的引入，這個問題已經被解決了。

不過，picture元素的引入也帶來了新問題：
開發人員現在必須在每一個斷點為每一個圖片生成一個獨立的asset。而開發者真正需要的是一個能夠將一張高分辨率圖片自動轉化為適配設備的小圖片的方案。理想情況下，這個自動化解決方案能夠讓每張圖片只請求一次，并且充分語義化和向后兼容。 Mobify.js的圖像API提供了該方案。

picture元素是當前代替img元素的先行者，因為它使得開發者能夠為不同的屏幕分辨率指定不同的圖片，解決了性能和art direction（盡管新提出的srcN提議值得考慮）問題。典型的設置包括定義斷點，為不同斷點生成圖像，然后為圖像寫入picture標記。我們看看如何通使下面的圖片變得響應性：

我們使用了320、512、1024和2048像素基線。

首先，我們需要為每張圖片生成不同的分辨率的副本，可以通過命令行工具，例如 Image Optim或使用Photoshop的“存儲為web所用格式”功能。接下來，我們使用下面的標記：

上面的代碼有個問題，在它的配置中，我們的圖片可能不會對移動設備優化。下面是一張縮放到320像素寬的圖片：

圖片中的人物已經很難區分。為了更好的適應小屏幕，我們需要借助art direction的力量，
為小屏幕裁切這張圖片。

因為這個文件不是原始圖片的簡單縮放版本，需要給它一個特殊的命名結構（所以，用responsive-obama-mobile.png替代了responsive-obama-320.png）

但是如果我們要支持高DPI(點每英寸)設備呢？
picture 元素的規范中有一個srcset屬性，該屬性能讓我們很容易為不同分辨率指定不同的圖片。以下是我們使用picture元素后的代碼：

這里引入了一對新文件（esponsive-obama-mobile-2x.png 和 responsive-obama-4096.png），它們也必須生成。到目前為止，我們擁有同一個圖片的6個不同版本的副本。

讓我們更進一步。如果我們想使用現代化的格式，例如WebP來讀取我們的圖像，需要通過判斷瀏覽器是否支持嗎？突然，我們需要生成的文件數量從6個增加到12個。老實說，沒人愿意因為不同的分辨率而給每個圖片生成多個版本的圖片副本，并且需要在代碼標記上更新這些圖像版本。
我們需要讓它自動化！

理想的工作流程是這樣的，它允許開發者上傳分辨率盡可能高的圖片同時仍然使用img元素來達到自動為不同的瀏覽器重置圖片大小和壓縮圖片的目的。img元素很偉大，這個簡單的標簽解決了簡單的問題：為互聯網的用戶展示圖片。理想情況下，我們能通過一種高效的方法繼續沿用這個元素并且向后兼容。然后，當art direction arises 和衡量圖片下限的需求不能滿足時，我們可以使用picture元素，它語法中內建的分支邏輯很完美。

這個理想的工作流可以通過Mobify.js的響應式圖像API來實現。Mobify.js是一款改善響應式網站的開源庫，提供了響應式圖片、javascript和css的優化，自適應模板等等。它的圖像API能夠自動重置大小和壓縮img和picture元素，必要情況下，在后端甚至不需要改變任何一行標記代碼。簡單的上傳高分辨率資料然后讓API去關心接下來的事情。

響應式圖片之所以成為一個難以解決的問題是由于超前的預解析器，它阻止我們通過javascript改變img元素的src屬性。預解析器是瀏覽器的一個功能，通過生成一個獨立的線程（獨立于渲染線程之外），定位資源并使其并行下載，從而讓資源盡快的開始下載。預解析器的工作在響應式設計出現之前很有意義，但在現在的多設備的情況下，代碼標記的圖像不一定是我們希望用戶看到的；因此，我們需要思考一種允許開發者控制資源加載的同時不犧牲預加載的好處的API。在這個問題上，如果想要了解更多細節，可以考慮看看teve Souders的“I <3 Image Bytes.”

很多開發者為了避免預加載采用的一種方法是通過img的data-src屬性手動改變src屬性，巧妙地讓預加載器忽略了這些圖像，然后使用javascript將src屬性的值用data-src的替換。

通過Mobify.js 的 捕獲 API，我們避免了上面的方法，讓我們在保證性能的情況下又不失語義（無需

下面是調用API的的代碼：

Mobify.Capture.init(function(capture){
    var capturedDoc = capture.capturedDoc;
    var images = capturedDoc.querySelectorAll("img, picture");
    Mobify.ResizeImages.resize(images, capturedDoc) 
    capture.renderCapturedDoc();
});

它獲取了頁面的所有圖片，然后重寫的src的值如下：

http://ir0.mobify.com////

例如，如果該API在安卓最新版的chrome下運行，設備的css像素為320，像素比例為2，那么圖片就會從

變為

forest圖片會被調整到640px寬，并且，因為chrome支持WebP,我們可以因此受益，未來可以降低圖片的體積。在第一次請求之后，圖片就會被Mobify的CDN緩存，以備下次使用。因為這個圖片不需要任何art direction，我們可以繼續使用img元素。

你可以看看這個自動調整圖片大小的例子。打開網站調試工具，確定原始圖片沒有被下載！

使用這個方案，我們簡化了工作流程。我們僅僅上傳了一個高分辨率的圖片，然后讓API實現圖片的自動化調整大小。中間不需要代理過程，沒有改變任何屬性-只是一斷javascript。去吧，試著復制下面的代碼粘貼在head元素里（請注意它必須寫在其他資源標簽之前）。

(請注意這段腳本不存在單點故障。如果Mobify.js載入失敗，那么腳本會退出，你的網站依然會正常載入。如果圖片調整服務器掛了或者你處于一個開發環境中并且圖片在外網不可訪問，那么就會載入原始的圖片。)

你也可以利用完整的文檔。支持上面代碼的瀏覽器如下：所有的基于Webkit/Blink內核的瀏覽器，火狐4+，Opera 11+, and Internet Explorer 10+。

對于我們大多數的用例來說，自動化調整img元素實在是太棒了。但是，就像演示的奧巴馬的例子，art direction對于某些特定類型的圖片是必要的。 那么我們如何才能繼續使用picture元素來支持art direction而不是添加同個圖片的6個版本呢?圖像API同樣會調整picture元素，也就是說你可以使用picture元素實現art direction，而把調整大小的功能交給API。

當然不同的瀏覽器自動化調整圖片大小是可行的,而自動化的art direction確實不可能。picture元素是最可能的方案來實現在不同的斷點指定不同的圖片，因為它內置的分支邏輯定義語法很健壯(盡管前文也提到了， srcN也提供了非常接近的功能)。不過,為picture元素添加標記和為每個圖片創建6個版本讓人感覺十分復雜：

當使用圖像API和picture元素相結合， 代碼標記明顯簡化了:

這里的source元素會自動重寫img元素（像前面的例子一樣）。同時，注意上面的標記不需要使用noscript來阻止第二次請求，因為捕捉（Capturing）允許你保留標記的語義。

Mobify.js同樣能用于已變更的picture元素，便于顯式的定義不同的斷點需要多寬的圖片，而不再一覽與設備的寬度。 舉個例子， 你有一張平板電腦一半寬的圖片，那么根據瀏覽器的最大寬度指定該圖片的寬度所生成的圖片，它會比實際需要的尺寸大一些：

為了解決這個問題，圖像API可以改變picture標記，使得我們可以重新設定每個source元素的寬度，而不是為每個斷定指定不同的src屬性。例如，我們可以寫成下面這樣：

注意那個使用了data-src屬性的picture元素，這里定義了一個高分辨率的原始圖片作為一個起點，這個圖片會被用于其他斷點的尺寸調整。

如果瀏覽器寬度介于0到511像素(例如一部智能手機), 那么使用responsive-obama-mobile.png (出于對art
direction的考慮)。

如果瀏覽器寬度介于512到1023像素,那么使用responsive-obama.png,因為該媒體查詢下source沒有指定src。自動的決定寬度因為
data-width沒有指定。

如果瀏覽器寬度介于1024到2047像素,那么使用responsive-obama.png,
因為該媒體查詢下source沒有指定src。調整寬度為512像素，它被定義在data-width屬性中。

如果瀏覽器寬度為2048像素或更大，那么使用responsive-obama.png,
因為該媒體查詢下source沒有指定src。調整寬度為1024像素，它被定義在data-width屬性中。

如果不支持javascript，恢復為舊的img標簽。

圖像API會遍歷所有的picture元素，并將它轉變如下：

Picture polyfill （包含在Mobify.js里）會被執行然后根據媒體查詢選擇適當的圖片。當瀏覽器廠商支持了原生picture后，它也能運行良好。

這里有一個使用已變更picture元素標記（ the modified picture element ） 的例子，你可以看看。

使用捕獲需要將腳本寫在head標簽里，這會阻塞javascript的調用并且會推遲資源的初始化下載。該延遲的時間長度在3G鏈接下大概為0.5秒（例如dns解析和資源的捕獲和下載），在4G或wifi下耗時會相對少些，大約有60毫秒的延遲。這個延遲的小代價換到的是易于使用，和向下兼容以及語義化。

不通過捕獲的方式使用圖像API來避免阻塞javascript請求，你需要將所有img元素src屬性改為x-src屬性（你也可以適當的添加noscript編輯來檢測瀏覽器javascript的支持情況）并且在head標簽內粘貼下面的異步腳本：

這段腳本會異步載入Mobify.js ，當載入完成后，開始正常載入圖片就像載入html文檔一樣。

如果你正在使用一個客戶端javascript MVC框架，例如Backbone 或 AngularJS，你仍然可以使用Mobify.js的圖像API。首先，將Mobify.js庫包含到你的app中：

然后，使用Mobify.js文檔中列出的方法重寫圖片的URL。

Mobify.ResizeImages.getImageUrl(url)

該方法接受一個絕對URL然后返回圖像調整后的URL。最簡單的方式將圖片傳入這個方法是通過創建 模板輔助函數（template helper） (例如, {{image_resize "/obama.png" }} 在 Handlebars.js)執行了getImageUrl 方法來自動生成圖像的URL。

圖像已經被Mobify"s Performance Suite 尺寸調整服務器 調整了，它支持自動化調整WebP，CDN緩存等等。不過每個月免費調整的數量有一個默認的限制，不過別擔心，如果你對流量的需求比較大，那么大聲喊Mobify 一聲，我們會盡可能的給予幫助。該API也允許你使用不同的圖像調整服務，例如Sencha.io Src,或是你自己的后端服務。

Webkit團隊最近已經實現了src-set屬性，那么Blink和Gecko也將在不久實現。這是正確道路上前進的一大步，這意味著瀏覽器廠商已經嚴重重視了相應式圖像的問題。然而，它不能解決 art direction問題，也不能避免生成多個分辨率版本文件的步驟。

開發社區最近也一起討論了響應式圖片的問題。其中有一個有趣的提案是Ilya Grigorik提出的客戶端提醒，該提議包括在每個請求頭部發送設備屬性例如DPR和高度。我喜歡這個方案，因為它能讓我們繼續使用img標簽，然后在我們需要創建分支邏輯實現art direction只需要使用picture（或srcN）即可。盡管添加額外的HTTP頭和使用內容協商來解決這個問題已經被證明有效，對與擁有成千上萬圖像的網站來說，使用該方案來定位圖像恐怕不太可行。通過服務層或代理重寫圖像，可以解決這個問題，不過這兩張方式都可能被設置的有問題。在我看來，如果在客戶端能更好的控制資源加載，那這些個問題我們是能夠處理解決的。

如果開發者更好的控制了資源的加載，那么響應式圖片應該會被當作一個簡單的問題來處理。之所以如此多的響應圖像解決方案是基于代理實習，是因為在文檔到達瀏覽器之前，圖像必須被重寫。這是對預加載器嘗試盡快下載圖片行為的適應。不過代理的方案可能在安全性和擴展性方面會有很多問題，如果我們有一個簡單的方式來和預加載器交互，那么很多基于代理的方案就顯得冗余了。

那么如何在更好的控制資源加載的同時，仍然享受預加載器帶來的好處呢？這里關鍵點是我們不希望簡單的關閉預加載器-它并行下載的能力是一個巨大的勝利，并且已經被瀏覽器實現了。（請注意捕獲API不會阻塞并行下載。）其中一個方法是提供一個beforeload事件，該事件在資源載入之前觸發。該事件在safari瀏覽器中通過一個擴展就可以實現了，在某些瀏覽器中也可以使用，不過容量有限。如果現在能夠使用該方案的話，那么就不再需要捕獲了。下面是一個使用beforeload事件的一個基礎例子：

function rewriteImgs(event) {
    if (event.target === "IMG") {
        var img = event.target;
        img.src = "http://ir0.mobify.com/" + screen.width + "/" + img.src;
    }
}
document.addEventListener("beforeload", rewriteImgs, true);

關鍵的挑戰在于以某種方式在執行構圖循環時候（in the main rendering loop）讓預加載器和javascript交互良好。有一個當前正在瀏覽器中開發的一個新系統，叫做 Service Worker,
它的目的是允許開發者截獲網絡請求來協助構建離線web應用。然而，當前的實現不允許攔截初始請求。這是因為載入一個額外的腳本會阻塞其他資源的載入-不過我相信這個情況會改變，例如通過不犧牲性能的內聯腳本的方式。如果你有如下的需求，可以考慮使用 Mobify.js 來自動處理響應式圖片：

響應式圖片方面的問題有許多的解決方案，工作自動化的同時仍然可以art direction的方案驅動未來的Web開發的解決方案。

只需要為每個資源提供一份高版本的圖片，讓API實現提供基于設備條件（寬度，WebP支持情況等等）的小圖片。

每個圖片之發生一次請求。

需要100%的語義和向下兼容舊標記并且不需要改變后端（使用捕獲的情況）。

已經開始使用picture元素來自動調整大小，只專注與使用它來實現art direction。

原文 Automate Your Responsive Images With Mobify.js
作者 Shawn Jansepar