一種尺寸適合一些人：響應式網頁設計圖像解決方案指南

已發表: 2022-03-11

隨著移動和平板設備越來越接近最終統治世界，網頁設計和技術正在競相適應不斷增長的屏幕尺寸。 然而，設計工具來應對這一現象的挑戰帶來了一系列全新的問題，其中一個最新流行詞是“響應式網絡”。 這是在不降低用戶體驗的情況下使網絡在大多數（如果不是全部）設備上運行的挑戰。 無需設計適合台式機或筆記本電腦的內容，信息必須可用於手機、平板電腦或任何連接到網絡的表面。 然而，這種響應式網頁設計的演變已被證明是一個困難的，有時甚至是痛苦的。

雖然容納文本信息幾乎是微不足道的，但當我們考慮到響應式圖像、信息圖表、視頻等內容時，棘手的部分就出現了，這些內容曾經設計時只考慮桌面。 這不僅提出了正確顯示內容的問題，而且還提出瞭如何使用不同的設備消費內容本身。 智能手機上的用戶與台式機上的用戶不同。 還必須考慮數據計劃和處理速度等因素。 谷歌已開始在其搜索結果中突出顯示適合移動設備的網站，一些人推測這將大幅提升此類網站的頁面排名。 早期的解決方案通過部署僅限移動設備的子域（和重定向）解決了這個問題，但這增加了複雜性並且很快就過時了。 （並非每個站點都有能力負擔這條路線。）

關於響應式 Web 圖像的探索

響應式網頁設計圖像必須簡單地縮放以適應現代常見的設備。

此時，開發人員和設計人員必須確保優化他們的網站負載以滿足移動網站上的用戶。 現在超過 20% 的網絡流量是移動用戶，而且這個數字還在上升。 由於圖像佔據了頁面內容數據的最大份額，因此減少這種負載成為當務之急。 已經進行了幾次嘗試來簡化響應式設計圖像大小調整，包括服務器端和前端解決方案。 要討論這些響應式圖像解決方案，我們首先需要了解當前圖像鏈接的缺點。

<img>標籤只有 source 屬性直接鏈接到圖像本身。 如果沒有任何附加組件，它無法確定所需的正確圖像類型。

難道我們不能只包含 HTML 中包含的所有圖像大小，並使用 CSS 規則來display:none除了正確的圖像之外的所有圖像？ 這是完美邏輯世界中最合乎邏輯的解決方案。 這樣瀏覽器可以忽略所有未顯示的圖像，並且理論上不會下載它們。 但是，瀏覽器的優化超出了常見的邏輯。 為了使頁面渲染得足夠快，瀏覽器會在必要的樣式表和 JavaScript 文件完全加載之前預取鏈接的內容。 我們最終沒有忽略用於桌面的大圖像，而是下載了所有圖像並導致更大的頁面加載。 CSS-only 技術僅適用於用作背景圖像的圖像，因為這些可以在樣式表中設置（使用媒體查詢）。

那麼，網站要做什麼呢？

後端響應式圖像縮放解決方案

後端解決方案非常適合在響應式網頁設計情況下處理圖像大小。

除了移動站點/子域之外，我們只剩下嗅探用戶代理 (UA) 並使用它來將正確大小的圖像返回給用戶。 但是，任何開發人員都可以證明此解決方案的不可靠程度。 新的 UA 字符串一直在不斷彈出，使得維護和更新一個完整的列表變得很費勁。 當然，這甚至沒有首先考慮到容易被欺騙的 UA 字符串的不可靠性。

自適應圖像

但是，一些服務器端解決方案值得考慮。 對於那些喜歡後端響應式圖像修復的人來說，自適應圖像是一個很好的解決方案。 它不需要任何特殊標記，而是使用一個小的 JavaScript 文件，並在其後端文件中完成大部分繁重的工作。 它使用 PHP 和 nginx 配置的服務器。 它也不依賴任何 UA 嗅探，而是檢查屏幕寬度。 自適應圖像非常適合縮小圖像，但在需要藝術指導的大圖像時也很方便，即通過裁剪和旋轉等技術來縮小圖像 - 而不僅僅是縮放。

煎茶觸摸

Sencha Touch 是另一種後端響應式設計圖像解決方案，儘管將其稱為第三方解決方案更好。 Sencha Touch 將通過嗅探 UA 來相應地調整圖像大小。 以下是該服務如何工作的基本示例：

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

還有一個選項可以指定圖像大小，以防我們不希望 Sencha 自動調整圖像大小。

歸根結底，服務器端（和第三方）解決方案需要資源來處理請求，然後再發回正確的圖像。 這需要寶貴的時間，進而減慢請求-響應行程。 更好的解決方案可能是設備本身確定要直接請求哪些資源，並且服務器做出相應的響應。

前端解決方案

前端響應式設計圖像縮放解決方案是優化網站負載的絕佳選擇。

最近，瀏覽器端在處理響應式圖像方面有了很大的改進。

<picture>元素已由 W3C 在 HTML5 規範中引入和批准。 它目前並未在所有瀏覽器上廣泛使用，但不久之後它就可以原生使用。 在那之前，我們依賴於 JavaScript 的 polyfills 來處理元素。 對於缺少該元素的舊版瀏覽器，Polyfills 也是一個很好的解決方案。

還有一種情況是srcset屬性可用於多個基於 webKit 的瀏覽器的<img>元素。 這可以在沒有任何 JavaScript 的情況下使用，如果要忽略非 webKit 瀏覽器，這是一個很好的解決方案。 對於其他解決方案不足的奇怪情況，這是一個有用的權宜之計，但不應被視為全面的解決方案。

圖片填充

Picturefill 是<picture>元素的 polyfill 庫。 它是響應式圖像大小和縮放問題的前端解決方案中最受歡迎的庫之一。 有兩個版本； Picturefill v1 使用span模仿<picture>元素，而 Picturefill v2 在已經提供它的瀏覽器中使用<picture>元素並為舊版瀏覽器提供 polyfill（例如，對於 IE >= IE9）。 它有一些限制和變通方法，尤其是對於 Android 2.3 - 順便說一下，這是img srcset屬性發揮作用的一個例子。 下面是使用 Picturefill v2 的示例標記：

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

為了提高數據計劃有限的用戶的性能，圖片填充可以與延遲加載相結合。 但是，該庫可以提供更廣泛的瀏覽器支持並解決奇怪的情況，而不是依賴補丁。

Imager.js

Imager.js 是 BBC 新聞團隊創建的一個庫，用於使用與 Picturefill 使用的方法不同的方法來完成響應式圖像。 雖然 Picturefill 嘗試將<picture>元素帶到不受支持的瀏覽器中，但 Imager.js 專注於僅下載適當的圖像，同時還要注意網絡速度。 它還結合了延遲加載，而不依賴於第三方庫。 它通過使用佔位符元素並用<img>元素替換它們來工作。 下面的示例代碼展示了這種行為：

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

呈現的 HTML 將如下所示：

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

瀏覽器支持比 Picturefill 的支持要好得多，但代價是它是一種比前瞻性解決方案更實用的解決方案。

源改組

Source Shuffle 從與其他前端庫略有不同的角度處理響應式圖像問題。 它類似於“移動優先”思想流派的東西，默認情況下它提供最小的分辨率。 在檢測到設備具有更大的屏幕時，它會將圖像源換成更大的圖像。 感覺更像是一個 hack，而不是一個完整的庫。 這對於主要是移動網站來說是一個很好的解決方案，但意味著桌面和/或平板電腦的雙重資源下載是不可避免的。

其他一些值得注意的 JavaScript 庫是：

  • HiSRC - 用於響應式圖像的 jQuery 插件。 對 jQuery 的依賴可能是個問題。
  • Mobify.js - 一個更通用的響應式內容庫，包括圖像、樣式表甚至 JavaScript。 它在資源加載之前“捕獲” DOM。 Mobify 是一個功能強大的綜合庫，但如果目標只是響應式圖像，則可能有點矯枉過正。

概括

歸根結底，由開發人員決定哪種響應式網頁設計圖像方法適合用戶群。 這意味著數據收集和測試將更好地了解採取的方法。

最後，在決定適當的響應式圖像解決方案之前，考慮以下問題列表可能會有所幫助。

  • 舊版瀏覽器有問題嗎？ 如果沒有，請考慮使用更現代的方法（例如：Picturefill、 srcset屬性）
  • 響應時間是否關鍵？ 如果沒有，請尋求第三方或後端解決方案。
  • 解決方案應該是內部的嗎？ 第三方解決方案顯然會被排除在外。
  • 網站上是否已經有很多圖像正在嘗試轉換為響應式圖像？ 是否存在關於驗證或語義標籤（或者更確切地說是非語義標籤）的問題？ 這將需要一個後端解決方案來將圖像請求路由到諸如自適應圖像之類的東西。
  • 藝術指導是否有問題（特別是對於包含大量信息的大圖像）？ 對於這種情況，像 Picturefill 這樣的庫將是更好的解決方案。 此外，任何後端解決方案都可以正常工作。
  • 是否擔心缺少 JavaScript？ 任何前端解決方案都將是不可能的，這留下了依賴 UA 嗅探的後端或第三方選項。
  • 移動響應時間是否優先於桌面響應時間？ 像 Source Shuffle 這樣的庫可能更合適。
  • 是否需要為網站的各個方面提供響應行為，而不僅僅是圖像？ Mobify.js 可能會更好。
  • 完美世界實現了嗎？ 使用純 CSS display:none方法！