【學習圖片】1.圖片簡史

前端小智發表於2023-02-17
本文首發於微信公眾號:大遷世界, 我的微信:qq449245884,我會第一時間和你分享前端行業趨勢,學習途徑等等。
更多開源作品請看 GitHub https://github.com/qq449245884/xiaozhi ,包含一線大廠面試完整考點、資料以及我的系列文章。

<img>這個元素幾乎不需要介紹了。它是1993年在Netscape(當時叫“Mosaic”)釋出的,並且在1995年加入了HTML的規範,一直在Web平臺中扮演著一個簡單但強大的角色。開發人員透過src屬性新增一個圖片檔案,並透過alt屬性提供文字代替,以防圖片無法顯示或者輔助技術需要替代內容。從那時起,瀏覽器的工作只有一件事:獲取圖片資料,然後儘快渲染。

<img src="https://assets.codepen.io/11355/aquilegia.jpg" alt="A white aquilegia bloom.">

在 web 開發的大部分歷史中,處理影像並不複雜。儘管現 代web 十分複雜,但處理影像的基本原則並沒有改變:使用 web 友好的影像格式以保證相容性,使用合理壓縮技術來節省頻寬,並使影像的尺寸適合頁面佈局中的空間。

在我們認為我們對使用者體驗有更多影響力的時候,使用固定寬度佈局使這個過程變得簡單易懂。設定影像尺寸特別容易。對於一個寬500畫素,高300畫素的影像,只需指定相同大小的影像就行了。

響應式佈局中的影像

除了靈活的佈局和使用CSS媒體查詢之外,"靈活的影像和媒體"是響應式網頁設計的三個重要方面之一。為了使影像變得靈活,開發人員開始使用CSS將max-width:100%設定在影像上(或所有影像,整個站點),告訴瀏覽器的渲染引擎透過縮放影像來防止影像超出其父容器。從視覺上看,這完美無瑕-縮小光柵影像在視覺上是無縫的。

透過一兩行CSS,縮小的影像看起來就像我們指定了一個影像源,而這個影像源就是要以這個尺寸顯示的。當渲染引擎得到的影像資料多於影像在佈局中所佔據的空間時,它們就能對如何渲染縮小的影像做出明智的決定,並且可以在不引入任何視覺偽影或模糊的情況下完成。

事例:https://codepen.io/web-dot-de...

你通常不希望放大影像,也就是說,把 <img> 顯示為比源影像的固有大小更大的大小。顯示的影像會顯得模糊和有點像顆粒的樣子。

事例地址:https://codepen.io/web-dot-de...

使用 img { max-width: 100% } 意味著,當靈活的容器調整大小時,影像將根據需要縮小。與設定更嚴格的 width: 100% 不同,這也確保影像不會超過其固有大小而被縮放。很長一段時間以來,這就是處理影像的規則:使用瀏覽器能理解的格式,使用合理的壓縮級別,永遠不要向上縮放影像。

事例地址:https://codepen.io/web-dot-de...

但是,儘管這種方法在視覺上簡單有效,它也帶來了巨大的效能代價。由於 <img> 僅支援一個影像資料來源,因此該方法要求我們提供具有儘可能大的內在大小的影像資源。

例如,如果一張影像佔據的空間的寬度可以根據使用者的視口大小從 300px2000px 不等,則該影像的源影像的內在寬度至少應為 2000px。對於僅透過小視口檢視頁面的使用者,一切都會看起來很正常,因為影像將很好地縮放。在呈現的頁面中,一個巨大但縮小的源影像看起來與適當大小的影像沒有任何區別。但是,他們仍然要傳輸和渲染 2000px 寬的影像,消耗大量頻寬和處理能力,沒有任何實際效益。

隨著第一款“Retina”裝置的出現,情況變得更加糟糕,因為顯示密度成為了視口大小的關注點。為了適應高密度顯示器,影像源需要更大的內在寬度。簡單地說,密度是雙倍的顯示器需要兩倍多的影像畫素才能儘可能清晰地呈現影像。

在這裡,開發人員再次可以依靠渲染引擎將影像縮小的能力。透過在src中提供瀏覽器一個800畫素寬的源影像,並在CSS中指定它應該以400畫素寬顯示,結果是以雙倍畫素密度渲染的影像。

事例地址:https://codepen.io/web-dot-de...

單一影像源適合佈局中最大的可能空間和高密度顯示,當然可以在視覺上適合所有使用者。巨大的高解析度影像源在小的低密度顯示器上呈現出來就像其他任何小的低密度影像一樣,但感覺更慢。使用者將承受這個巨大的4000畫素寬影像源的所有效能成本,沒有任何好處。

很長一段時間以來,<img> 只做了一件事 - “獲取影像資料並將其放在螢幕上”。當然它做得很好,但 <img> 無法適應我們正在經歷的瀏覽上下文的巨大變化。當響應式Web設計成為主流開發實踐時,瀏覽器對img的效能進行了最佳化,但除了最優越的使用者外,頁面的影像內容從一開始就是低效的。無論瀏覽器如何快速請求、解析和渲染影像源,該資源很可能比使用者需要的更大。

程式碼部署後可能存在的BUG沒法實時知道,事後為了解決這些BUG,花了大量的時間進行log 除錯,這邊順便給大家推薦一個好用的BUG監控工具 Fundebug

原文:https://web.dev/learn/images/...

交流

有夢想,有乾貨,微信搜尋 【大遷世界】 關注這個在凌晨還在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收錄,有一線大廠面試完整考點、資料以及我的系列文章。

相關文章