原文出處:http://www.w3cplus.com/responsive/responsive-images-101-part-9-image-breakpoints.html
我其實(shí)很害怕寫響應(yīng)式圖片101系列里圖片斷點(diǎn)這個(gè)部分。選擇圖片斷點(diǎn)每個(gè)人都會(huì)遇到,坦白說,我也沒有一個(gè)好的解決方案。
但我們遲早會(huì)遇到圖片斷點(diǎn)的問題。所以不妨現(xiàn)在就開始研究。
在響應(yīng)式布局中,斷點(diǎn)代表在某個(gè)視口尺寸上改變頁面的布局或功能。通常與媒體查詢相對(duì)應(yīng)。
響應(yīng)式圖片斷點(diǎn)與此類似但有細(xì)微差別。當(dāng)我在思考圖片斷點(diǎn)時(shí),我會(huì)嘗試回答兩個(gè)問題:
這些問題的答案產(chǎn)生的斷點(diǎn)會(huì)與響應(yīng)式布局中標(biāo)準(zhǔn)的斷點(diǎn)不同。在布局中,我遵循Stephen Hay的好方法:改變?yōu)g覽器大小直到頁面看起來很糟糕那么這個(gè)時(shí)候啊哈,我們需要一個(gè)斷點(diǎn)。
然而在藝術(shù)指導(dǎo)中,需要多個(gè)圖片源的原因和圖片在什么瀏覽器尺寸下看起來很糟糕并無關(guān)系。我們想提供多個(gè)圖片源是基于表現(xiàn)考慮,不同尺寸屏幕的分辨率等其他原因。
因此我們不能在圖片上機(jī)械重復(fù)使用響應(yīng)式布局?jǐn)帱c(diǎn)?;蛘呶也乱苍S是可以,但是如果這樣做的話,那就和我們使用響應(yīng)式圖片的初衷背道而馳了。
在藝術(shù)指導(dǎo)使用情況中,藝術(shù)指導(dǎo)本身會(huì)告訴我們需要多少個(gè)圖片源并且什么時(shí)候應(yīng)該使用。
回顧Nokia瀏覽器網(wǎng)頁的例子,我們可以知道圖片應(yīng)該在什么時(shí)候從風(fēng)景模式轉(zhuǎn)為肖像模式。發(fā)生轉(zhuǎn)換時(shí),需要一個(gè)新圖片源。
然而,這也許只是圖片的一部分。如果藝術(shù)指導(dǎo)的某一張圖片包含了大范圍的尺寸呢。我們會(huì)發(fā)現(xiàn)仍然需要與藝術(shù)指導(dǎo)切換不對(duì)應(yīng)的多個(gè)圖片源。
可以在第8部分提到的Shopify首頁看到看到這個(gè)例子。
雖然圖片只有一個(gè)主要的藝術(shù)指導(dǎo)切換變化-從全尺寸的圖片變成裁剪的版本-Shopify仍然提供了6個(gè)圖片源說明圖片尺寸和顯示器分辨率。
<picture>
<source srcset="homepage-person@desktop.png, homepage-person@desktop-2x.png 2x"
media="(min-width: 990px)">
<source srcset="homepage-person@tablet.png, homepage-person@tablet-2x.png 2x"
media="(min-width: 750px)">
<img srcset="homepage-person@mobile.png, homepage-person@mobile-2x.png 2x"
alt="Shopify Merchant, Corrine Anestopoulos">
</picture>
了解圖片在藝術(shù)指導(dǎo)使用情況下的表現(xiàn)讓我們得到一些結(jié)論,但仍然沒法回答關(guān)于必要圖片斷點(diǎn)的所有問題。
這就是事情變得有技巧的地方。至少藝術(shù)指導(dǎo)給了我們一些關(guān)于需要多少圖片源的提示。
當(dāng)拉伸自適應(yīng)圖片時(shí),它們總是表現(xiàn)良好。不能指望它們表現(xiàn)變差來告訴我們什么時(shí)候需要改變圖片源。
來看一下分辨率切換的例子:
在這里例子中,當(dāng)前頁面視口尺寸中一張Michelle Obama的照片的尺寸為400px?x 602px
。這張圖片的最大尺寸要在2000px?x 3010px
的分辨率下才會(huì)顯示。最大文件的大小為250K
。
可以直接縮放這張2000px
的圖片,并且它會(huì)表現(xiàn)良好。但是尺寸過大。如果提供一個(gè)小版本的圖片例如分辨率800px?x 1024px
會(huì)顯得更好。圖片尺寸僅為73K
。
我們都同意當(dāng)頁面中圖片尺寸僅為400px?x 602px
時(shí),提供一張分辨率為800px?x 1024px
大小為73K
的圖片會(huì)比下載最大尺寸的圖片更好。
但為什么要止步于800×1204呢?
如果我們提供另一張尺寸為600px × 903px
的圖片源,大小只有42K
。這比800px × 1024px
大小的圖片節(jié)約了31K
(42%
)。
很棒。42%
的空間節(jié)約是很大的進(jìn)步。也許我們應(yīng)該更進(jìn)一步。如果是500px
寬呢?450px
寬呢?
每個(gè)更小尺寸的圖片都可能比之前的尺寸更節(jié)約空間。如果繼續(xù)這種方式,最終會(huì)達(dá)到頁面上這張圖片的精確尺寸。
那么這里有一個(gè)令人困擾的關(guān)于圖片斷點(diǎn)的問題。如何確定當(dāng)前頁面使用的圖片尺寸的文件大小太大了呢?
答案是除非圖片源完全匹配圖片顯示在頁面上的尺寸,否則它總是過大的??偸怯袡C(jī)會(huì)提供更小尺寸的圖片來優(yōu)化。
在這一點(diǎn)上,你也許會(huì)疑惑為什么不直接提供在頁面中使用圖片的精確尺寸呢。
首先,響應(yīng)式設(shè)計(jì)中設(shè)定自適應(yīng)圖片斷點(diǎn)的目的是讓圖片隨著視口改變而伸縮。如果提供頁面中使用圖片的精確尺寸,不論是視口尺寸改變還是設(shè)備旋轉(zhuǎn)都需要下載新圖片。
其次,提供任何能想到尺寸的圖片是不可能的。是的,我們可以動(dòng)態(tài)改變圖片尺寸,但與此同時(shí),服務(wù)器需要處理這些工作就會(huì)拖慢分發(fā)圖片到瀏覽器的速度。
因此,大多數(shù)網(wǎng)站把圖片緩存在內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)上。要把每個(gè)尺寸的圖片緩存在CDN上是非常昂貴的。
最后,瀏覽器在開始下載時(shí)并不知道頁面中圖片的確切尺寸。這就是最初讓我們制定響應(yīng)式圖片新標(biāo)準(zhǔn)的原因。
像開始提到的那樣,我沒有絕對(duì)可靠的關(guān)于如何選擇需要圖片源數(shù)量的方案。相反,我想闡述一些看待這個(gè)問題的不同方式來幫助你做決定。
你團(tuán)隊(duì)中的某些人會(huì)說,“嗨,你覺得這些產(chǎn)品圖片需要多少圖片源?”
你猶豫了一會(huì)兒說,“3個(gè)怎么樣?小,中,大。”
如果你已經(jīng)這么做了也不要羞澀。我很確定現(xiàn)在大部分使用響應(yīng)式圖片的人已經(jīng)這么做了。
也許你的考量中需要兼容手機(jī),平板和桌面也就是小,中,大屏幕。
或者你考慮到圖片會(huì)顯示的范圍并估計(jì)一下。也許你只是簡(jiǎn)單看一下主流的斷點(diǎn)數(shù)量然后決定同樣處理圖片斷點(diǎn)。
我完全理解。顯然這比給所有視口提供一張大圖片要好。
當(dāng)然如果我們的決定更有邏輯會(huì)更好。
可能猜測(cè)聽起來也不是很奇怪,讓我們?cè)谶x擇圖片斷點(diǎn)中加入一些科學(xué)成分。我們來看一些響應(yīng)式圖片并計(jì)算出它們需要多少斷點(diǎn)。
這件事情最難的部分是限制響應(yīng)式圖片,或計(jì)算出總共有多少個(gè)圖片。
對(duì)于一些網(wǎng)站,所有照片可能按照品牌有特定樣式。如果是這種情況,很容易找到具體的有代表性的圖片。選擇一些圖片改變尺寸并保存最大和最小圖片間的尺寸直到你認(rèn)為已經(jīng)得到了合適的范圍。
當(dāng)然,如果你的網(wǎng)站有多種多樣的圖片樣式,找到具有代表性的圖片幾乎是不可能的。
今年夏天早些時(shí)候,Tim Kadlec發(fā)表了一個(gè)關(guān)于手機(jī)圖片過程的演講。在這個(gè)演講中,他主要研究了響應(yīng)式設(shè)計(jì)中自適應(yīng)圖片的內(nèi)存開銷。
Tim展示了隨著圖片增大,改變圖片尺寸的影響也變大了。
在上述例子中,在每個(gè)方向上將一張600px × 600px
的圖片減少50px
會(huì)導(dǎo)致230000b
的浪費(fèi)相比于用同樣方式將200px × 200px
減少50px
只有70000b
的浪費(fèi)。
這一點(diǎn)給我們提供了一些選擇斷點(diǎn)的參考。并不是要使斷點(diǎn)均勻分布,在圖片變大時(shí)應(yīng)該增加更多斷點(diǎn)。
不幸的是,雖然這一點(diǎn)告訴我們大尺寸圖片需要更多斷點(diǎn),我們依然不知道具體在哪里需要這些斷點(diǎn)。
如果我們把績(jī)效預(yù)算的靈感應(yīng)用到響應(yīng)式圖片?這樣會(huì)看起來如何呢?
我們給浪費(fèi)的比特?cái)?shù)定義一定數(shù)量的預(yù)算,瀏覽器下載適應(yīng)當(dāng)前頁面的圖片時(shí)可以在這范圍內(nèi)造成一定的比特浪費(fèi)。
因此我們決定每個(gè)響應(yīng)式圖片的績(jī)效預(yù)算為20K
。這意味著必須確保定義的各種圖片源都小于20K
。
這樣做后,我們發(fā)現(xiàn)圖片斷點(diǎn)基于視覺多樣性發(fā)生了巨大的改變并且使用了壓縮。
讓我們來看三張樣例圖片。
這張圖片的視覺多樣性豐富。顏色和紋理變化意味著無法在保證圖片質(zhì)量的情況下進(jìn)行很大程度的JPEG無損壓縮。
因此,這張圖有8個(gè)圖片斷點(diǎn)-以20k為間隔設(shè)置-最小圖片尺寸為(320×213
),最大圖片尺寸為(990×660
)。
Breakpoint # | Width | Height | File Size |
---|---|---|---|
1 | 320 | 213 | 25K |
2 | 453 | 302 | 44K |
3 | 579 | 386 | 65K |
4 | 687 | 458 | 85K |
5 | 786 | 524 | 104K |
6 | 885 | 590 | 124K |
7 | 975 | 650 | 142K |
8 | 990 | 660 | 151K |
不像時(shí)代廣場(chǎng)的圖片,這張圖片很多地方顏色非常相似并且紋理很少。因此,JPEG能更好得壓縮這張圖片。
在一張能被良好壓縮的圖片上,20K的預(yù)算可以更進(jìn)一步。對(duì)于這張圖片,我們只需要三個(gè)圖片斷點(diǎn)來覆蓋這張圖片會(huì)使用的所有尺寸區(qū)間。
Breakpoint # | Width | Height | File Size |
---|---|---|---|
1 | 320 | 213 | 9.0K |
2 | 731 | 487 | 29K |
3 | 990 | 660 | 40K |
這是一張簡(jiǎn)單的PNG8文件。最大尺寸(990×660
)的大小僅為13K
。因此,它不用做任何改變就適合我們的20K
預(yù)算。
Breakpoint # | Width | Height | File Size |
---|---|---|---|
1 | 990 | 660 | 13K |
來看一下我們創(chuàng)建的樣例頁面上的其他圖片。了解斷點(diǎn)數(shù)量如何變化即便所有圖片開始時(shí)分辨率相同且最終斷點(diǎn)相同。
現(xiàn)在,我并沒有建議大家手動(dòng)決定每個(gè)圖片的斷點(diǎn)。但是未來你可以在服務(wù)器上聲明20K的響應(yīng)式圖片預(yù)算然后讓服務(wù)器計(jì)算每張圖片的圖片源數(shù)量。
我過去已經(jīng)寫過了更多關(guān)于響應(yīng)式圖片的績(jī)效預(yù)算內(nèi)容的細(xì)節(jié)。如果你最終施行了這個(gè)方法,請(qǐng)告訴我。
最近的響應(yīng)式圖片討論組(RICG)中,Yoav Weiss?和?Ilya Grigori討論了一個(gè)基于圖片尺寸請(qǐng)求的頻繁程度來選擇圖片斷點(diǎn)的方式。
對(duì)于在Akamai工作的Yoav和在Google工作的lily來說,他們對(duì)于多圖片的一個(gè)共同問題在于把這些源都存在邊緣服務(wù)器上然而存儲(chǔ)空間通常有限制并且代價(jià)更加昂貴。
不光是像Akamai和Google這樣的公司想要減少邊緣服務(wù)器上存儲(chǔ)的圖片數(shù)量,它們內(nèi)容分發(fā)網(wǎng)絡(luò)的整個(gè)目的都是減少人們耗費(fèi)在web頁面渲染上的時(shí)間。
因此,如果能夠把請(qǐng)求最頻繁的圖片尺寸緩存在邊緣服務(wù)器,它們會(huì)給大多數(shù)用戶帶來最快的分發(fā)體驗(yàn)。
對(duì)于這些組織,他們可以把圖片處理和斷點(diǎn)邏輯與分析系統(tǒng)聯(lián)系起來并且一旦發(fā)現(xiàn)新的圖片尺寸被更頻繁得請(qǐng)求后便改變圖片的尺寸。
當(dāng)把它與Ilya已經(jīng)實(shí)現(xiàn)新HTTP客戶端提示特性結(jié)合起來時(shí),服務(wù)器對(duì)于如何在CDN上保存圖片會(huì)變的非常聰明,這樣做的話很少需要設(shè)計(jì)師和開發(fā)來做決策。
我相信在短短幾年內(nèi),沒有人會(huì)再談?wù)撨x擇響應(yīng)式圖片斷點(diǎn)因?yàn)闆]有人會(huì)再手動(dòng)去做。
當(dāng)然,我們?nèi)匀粫?huì)對(duì)藝術(shù)指導(dǎo)使用情況的圖片作出決定,但即便是這個(gè)情況,我們當(dāng)然不會(huì)給每個(gè)圖片源做決定。我們只處理需要介入的部分然后讓圖片處理服務(wù)解決剩余部分。
根據(jù)績(jī)效預(yù)算或不同尺寸的請(qǐng)求頻繁程度來選擇圖片源都有一大堆好處。但這些解決方案作為手動(dòng)工作流的一部分都站不住腳。
未來,我們的工作流也許是將最高品質(zhì)的圖片上傳到內(nèi)容管理系統(tǒng)或圖片處理系統(tǒng)并且再也不要關(guān)心。
這個(gè)系列一開始有9個(gè)部分,但是討論響應(yīng)式圖片時(shí)總有許多要說。最后補(bǔ)允一篇,用來總結(jié)響應(yīng)式圖片的使用。
更多建議: