【學習圖片】15.影像內容分發網路

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

瞭解影像內容交付網路如何具有轉換和最佳化影像內容的能力。

你可能已經熟悉內影像內容分發網路（CDN）的核心概念：一個分佈但相互連線的伺服器網路，可以快速高效地向使用者提供資源。當檔案上傳到CDN提供商時，該檔案的副本將在全球CDN網路的其他節點上建立。當使用者請求檔案時，資料將由地理位置最近的節點傳送給該使用者，從而減少延遲。CDN的分散式特性還提供了冗餘性，以防網路故障或硬體故障，並進行負載平衡以減輕流量峰值。

影像CDN可以提供所有這些好處，但有一個關鍵區別：根據用於訪問它的URL字串，能夠轉換和最佳化影像內容。

使用者將上傳一個規範的高解析度影像到提供商，提供商將生成用於訪問該影像的URL：

https://res.cloudinary.com/demo/image/upload/sample.jpg

儘管每個提供商使用的確切語法都會有所不同，但最基本的所有影像CDN都允許你更改源影像的尺寸、編碼和壓縮設定。例如，Cloudinary透過以下語法對上傳的影像進行動態調整大小：h_後跟數字高度（以畫素為單位），w_後跟寬度，以及一個c_值，允許你指定有關如何縮放或裁剪影像的詳細資訊。

可以透過在檔名和副檔名之前新增逗號分隔的值來應用任意數量的轉換，這意味著上傳的影像可以透過請求它的img元素的src進行根據需要操作。

<img src="https://res.cloudinary.com/demo/image/upload/w_400/sample.jpg" alt="…">

當使用者首次訪問包含這些轉換的URL時，將生成併傳送一個新版本的影像，該影像按比例縮放至寬度為400px（w_400）。然後在整個CDN上快取該新建立的檔案，以便將其傳送給任何請求相同URL的使用者，而無需按需重新建立。

雖然影像CDN提供商提供軟體開發工具包以促進高階用法和與各種技術堆疊的整合並不罕見，但僅憑這種可預測的URL模式，我們就可以輕鬆地將單個上傳檔案轉換為可行的srcset屬性，而無需任何其他開發工具：

<img
  src="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w"
  srcset="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w,
          https://res.cloudinary.com/demo/image/upload/w_800/sample.jpg 800w,
          https://res.cloudinary.com/demo/image/upload/w_600/sample.jpg 600w"
  alt="…">

我們能夠使用現在應該熟悉的語法來手動指定我們想要的壓縮級別：q_，"質量 "的縮寫，後面是壓縮級別的數字縮寫。

<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg"  alt="…">

然而，由於大多數影像CDN提供了一系列強大功能：全自動壓縮、編碼和內容協商，你很少需要手動包含這些資訊。

自動壓縮

CDN所擁有的計算能力意味著它們能夠提供一項非常強大的功能：透過分析影像內容來演算法確定其理想的壓縮水平和編碼設定，就像你或我手動微調每個影像的壓縮一樣。

這些演算法自動化了你可能會做出的在檔案大小和感知質量之間權衡的決策，透過分析影像內容來尋找可度量的退化跡象，並相應地微調壓縮設定。這通常意味著與一種大小適合所有的手動壓縮方法相比，檔案大小會大大減小。

儘管這個過程聽起來很複雜，但它的實現卻非常簡單：對於Cloudinary來說，將“q_auto”新增到影像URL中即可啟用此功能：

<img src="https://res.cloudinary.com/demo/image/upload/w_1400/sample.jpg" alt="…">
<!-- 250 KB-->

<img src="https://res.cloudinary.com/demo/image/upload/w_1400,q_auto/sample.jpg" alt="…">
<!-- 134 KB-->

自動編碼和內容協商

當接收到對影像的請求時，影像CDN透過瀏覽器傳送的HTTP頭來確定瀏覽器支援的最新編碼方式，這些HTTP頭是在請求資源時傳送的。具體來說，是透過“Accept”頭部來指示瀏覽器可以理解的編碼方式。我們使用與填充<picture>元素的<source>的type屬性相同的媒體型別。

例如，在資產URL的影像轉換列表中新增“f_auto”引數，明確告訴Cloudinary要提供瀏覽器能夠理解的最有效的編碼方式：

<img src="https://res.cloudinary.com/demo/image/upload/w_1200,q_auto,f_auto/sample.jpg" alt="…">

然後，伺服器生成一個具有該編碼的影像版本，併為所有具有相同瀏覽器支援水平的後續使用者快取該結果。該響應包括一個Content-Type頭，明確告知瀏覽器該檔案的編碼，而不考慮檔案的副檔名。即使一個使用現代瀏覽器的使用者會對一個以.jpg結尾的檔案提出請求，該請求也會伴隨著一個標頭，告知伺服器支援AVIF，伺服器會傳送一個AVIF編碼的檔案，並明確指示將其視為AVIF。

image.png

最終的結果是一個過程不僅使你免於建立備用編碼檔案和手動微調壓縮設定（或維護一個為你執行這些任務的系統），而且也不需要使用<picture>和type屬性來有效地向使用者傳遞這些檔案。因此，僅使用srcset和sizes語法就可以為您的使用者提供編碼為AVIF的影像，如果不支援，則降級為WebP（或僅適用於Safari的JPEG-2000），再次降級為最明智的傳統編碼方式。

使用影像CDN的缺點更多是後勤問題而非技術問題，其中最主要的是成本。雖然影像CDN通常會為個人使用提供功能強大的免費計劃，但生成影像資產需要頻寬和儲存空間進行上傳，伺服器上的處理來轉換影像，並需要額外的空間來快取轉換結果，因此高階用法和高流量應用程式可能需要付費計劃。

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

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

交流

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

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

相關文章