摘要：的圖像提供了該方案。使用的圖像和捕獲技術(shù)相結(jié)合我們能通過一個(gè)標(biāo)簽實(shí)現(xiàn)圖像的自動(dòng)響應(yīng)化。調(diào)整元素當(dāng)然不同的瀏覽器自動(dòng)化調(diào)整圖片大小是可行的而自動(dòng)化的確實(shí)不可能。

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

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

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

克服這個(gè)問題的第一步是創(chuàng)建一個(gè)基于標(biāo)記的解決方案，該方案允許基于設(shè)備的功能來替換圖像的來源。隨著W3C響應(yīng)式圖片交流社區(qū)創(chuàng)造的picture元素（盡管目前還沒有瀏覽器實(shí)現(xiàn)了它）的引入，這個(gè)問題已經(jīng)被解決了。

不過，picture元素的引入也帶來了新問題：
開發(fā)人員現(xiàn)在必須在每一個(gè)斷點(diǎn)為每一個(gè)圖片生成一個(gè)獨(dú)立的asset。而開發(fā)者真正需要的是一個(gè)能夠?qū)⒁粡埜叻直媛蕡D片自動(dòng)轉(zhuǎn)化為適配設(shè)備的小圖片的方案。理想情況下，這個(gè)自動(dòng)化解決方案能夠讓每張圖片只請求一次，并且充分語義化和向后兼容。 Mobify.js的圖像API提供了該方案。

picture元素是當(dāng)前代替img元素的先行者，因?yàn)樗沟瞄_發(fā)者能夠?yàn)椴煌钠聊环直媛手付ú煌膱D片，解決了性能和art direction（盡管新提出的srcN提議值得考慮）問題。典型的設(shè)置包括定義斷點(diǎn)，為不同斷點(diǎn)生成圖像，然后為圖像寫入picture標(biāo)記。我們看看如何通使下面的圖片變得響應(yīng)性：

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

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

上面的代碼有個(gè)問題，在它的配置中，我們的圖片可能不會(huì)對(duì)移動(dòng)設(shè)備優(yōu)化。下面是一張縮放到320像素寬的圖片：

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

因?yàn)檫@個(gè)文件不是原始圖片的簡單縮放版本，需要給它一個(gè)特殊的命名結(jié)構(gòu)（所以，用responsive-obama-mobile.png替代了responsive-obama-320.png）

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

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

讓我們更進(jìn)一步。如果我們想使用現(xiàn)代化的格式，例如WebP來讀取我們的圖像，需要通過判斷瀏覽器是否支持嗎？突然，我們需要生成的文件數(shù)量從6個(gè)增加到12個(gè)。老實(shí)說，沒人愿意因?yàn)椴煌姆直媛识o每個(gè)圖片生成多個(gè)版本的圖片副本，并且需要在代碼標(biāo)記上更新這些圖像版本。
我們需要讓它自動(dòng)化！

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

這個(gè)理想的工作流可以通過Mobify.js的響應(yīng)式圖像API來實(shí)現(xiàn)。Mobify.js是一款改善響應(yīng)式網(wǎng)站的開源庫，提供了響應(yīng)式圖片、javascript和css的優(yōu)化，自適應(yīng)模板等等。它的圖像API能夠自動(dòng)重置大小和壓縮img和picture元素，必要情況下，在后端甚至不需要改變?nèi)魏我恍袠?biāo)記代碼。簡單的上傳高分辨率資料然后讓API去關(guān)心接下來的事情。

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

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

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

下面是調(diào)用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下運(yùn)行，設(shè)備的css像素為320，像素比例為2，那么圖片就會(huì)從

變?yōu)?/p>

forest圖片會(huì)被調(diào)整到640px寬，并且，因?yàn)閏hrome支持WebP,我們可以因此受益，未來可以降低圖片的體積。在第一次請求之后，圖片就會(huì)被Mobify的CDN緩存，以備下次使用。因?yàn)檫@個(gè)圖片不需要任何art direction，我們可以繼續(xù)使用img元素。

你可以看看這個(gè)自動(dòng)調(diào)整圖片大小的例子。打開網(wǎng)站調(diào)試工具，確定原始圖片沒有被下載！

使用這個(gè)方案，我們簡化了工作流程。我們僅僅上傳了一個(gè)高分辨率的圖片，然后讓API實(shí)現(xiàn)圖片的自動(dòng)化調(diào)整大小。中間不需要代理過程，沒有改變?nèi)魏螌傩?只是一斷javascript。去吧，試著復(fù)制下面的代碼粘貼在head元素里（請注意它必須寫在其他資源標(biāo)簽之前）。

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

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

對(duì)于我們大多數(shù)的用例來說，自動(dòng)化調(diào)整img元素實(shí)在是太棒了。但是，就像演示的奧巴馬的例子，art direction對(duì)于某些特定類型的圖片是必要的。 那么我們?nèi)绾尾拍芾^續(xù)使用picture元素來支持art direction而不是添加同個(gè)圖片的6個(gè)版本呢?圖像API同樣會(huì)調(diào)整picture元素，也就是說你可以使用picture元素實(shí)現(xiàn)art direction，而把調(diào)整大小的功能交給API。

當(dāng)然不同的瀏覽器自動(dòng)化調(diào)整圖片大小是可行的,而自動(dòng)化的art direction確實(shí)不可能。picture元素是最可能的方案來實(shí)現(xiàn)在不同的斷點(diǎn)指定不同的圖片，因?yàn)樗鼉?nèi)置的分支邏輯定義語法很健壯(盡管前文也提到了， srcN也提供了非常接近的功能)。不過,為picture元素添加標(biāo)記和為每個(gè)圖片創(chuàng)建6個(gè)版本讓人感覺十分復(fù)雜：

當(dāng)使用圖像API和picture元素相結(jié)合， 代碼標(biāo)記明顯簡化了:

這里的source元素會(huì)自動(dòng)重寫img元素（像前面的例子一樣）。同時(shí)，注意上面的標(biāo)記不需要使用noscript來阻止第二次請求，因?yàn)椴蹲剑–apturing）允許你保留標(biāo)記的語義。

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

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

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

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

如果瀏覽器寬度介于512到1023像素,那么使用responsive-obama.png,因?yàn)樵撁襟w查詢下source沒有指定src。自動(dòng)的決定寬度因?yàn)?br> data-width沒有指定。

如果瀏覽器寬度介于1024到2047像素,那么使用responsive-obama.png,
因?yàn)樵撁襟w查詢下source沒有指定src。調(diào)整寬度為512像素，它被定義在data-width屬性中。

如果瀏覽器寬度為2048像素或更大，那么使用responsive-obama.png,
因?yàn)樵撁襟w查詢下source沒有指定src。調(diào)整寬度為1024像素，它被定義在data-width屬性中。

如果不支持javascript，恢復(fù)為舊的img標(biāo)簽。

圖像API會(huì)遍歷所有的picture元素，并將它轉(zhuǎn)變?nèi)缦拢?/p>

Picture polyfill （包含在Mobify.js里）會(huì)被執(zhí)行然后根據(jù)媒體查詢選擇適當(dāng)?shù)膱D片。當(dāng)瀏覽器廠商支持了原生picture后，它也能運(yùn)行良好。

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

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

不通過捕獲的方式使用圖像API來避免阻塞javascript請求，你需要將所有img元素src屬性改為x-src屬性（你也可以適當(dāng)?shù)奶砑觧oscript編輯來檢測瀏覽器javascript的支持情況）并且在head標(biāo)簽內(nèi)粘貼下面的異步腳本：

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

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

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

Mobify.ResizeImages.getImageUrl(url)

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

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

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

開發(fā)社區(qū)最近也一起討論了響應(yīng)式圖片的問題。其中有一個(gè)有趣的提案是Ilya Grigorik提出的客戶端提醒，該提議包括在每個(gè)請求頭部發(fā)送設(shè)備屬性例如DPR和高度。我喜歡這個(gè)方案，因?yàn)樗茏屛覀兝^續(xù)使用img標(biāo)簽，然后在我們需要?jiǎng)?chuàng)建分支邏輯實(shí)現(xiàn)art direction只需要使用picture（或srcN）即可。盡管添加額外的HTTP頭和使用內(nèi)容協(xié)商來解決這個(gè)問題已經(jīng)被證明有效，對(duì)與擁有成千上萬圖像的網(wǎng)站來說，使用該方案來定位圖像恐怕不太可行。通過服務(wù)層或代理重寫圖像，可以解決這個(gè)問題，不過這兩張方式都可能被設(shè)置的有問題。在我看來，如果在客戶端能更好的控制資源加載，那這些個(gè)問題我們是能夠處理解決的。

如果開發(fā)者更好的控制了資源的加載，那么響應(yīng)式圖片應(yīng)該會(huì)被當(dāng)作一個(gè)簡單的問題來處理。之所以如此多的響應(yīng)圖像解決方案是基于代理實(shí)習(xí)，是因?yàn)樵谖臋n到達(dá)瀏覽器之前，圖像必須被重寫。這是對(duì)預(yù)加載器嘗試盡快下載圖片行為的適應(yīng)。不過代理的方案可能在安全性和擴(kuò)展性方面會(huì)有很多問題，如果我們有一個(gè)簡單的方式來和預(yù)加載器交互，那么很多基于代理的方案就顯得冗余了。

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

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);

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

響應(yīng)式圖片方面的問題有許多的解決方案，工作自動(dòng)化的同時(shí)仍然可以art direction的方案驅(qū)動(dòng)未來的Web開發(fā)的解決方案。

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

每個(gè)圖片之發(fā)生一次請求。

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

已經(jīng)開始使用picture元素來自動(dòng)調(diào)整大小，只專注與使用它來實(shí)現(xiàn)art direction。

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