概觀

影像通常是網頁最佔空間的元件,無論是位元組或 HTTP 請求數目皆然。最佳化網站影像對於改善使用者體驗、降低交付成本並提高搜索引擎排名位置均至關重要。例如,Google 搜尋排名演算法的最大內容繪圖指標會因網站影像最佳化程度而受到大幅影響。

架構決策

影像最佳化解決方案可根據您在成本、彈性與效能方面的需求,以多種方式設計。當建立影像最佳化解決方案的架構時,您需要做出下列技術決策:

  • 需要哪些影像轉換? 是否要格式化、調整大小、裁剪等等。
  • 針對特定影像請求決定在哪裡套用何種轉換? 在用戶端前端 (靜態、回應式設計等)、在服務器端 (以裝置等請求內容為基礎) 還是組合兩者?
  • 在哪裡執行轉換? 在集中位置還是以分散式方式進行?
  • 何時執行轉換? 每次進行,還是短暫儲存轉換後的影像? 以同步還是非同步方式執行?

另一項重要決定是,要採用 AWS 服務來組建解決方案,還是購買第三方受管解決方案。

常見使用案例

基於 CloudFront、S3 與 Lambda 的客戶管理解決方案

最常見的影像最佳化使用案例需要根據使用者瀏覽器功能進行自動格式化,並讓前端可調整影像大小。熱門 Web 開發框架,例如 Next.JS,會提供回應式影像元件,可根據裝置檢視區自動選取影像大小。此常見使用案例的建議架構以下圖說明:

  1. 使用者會針對具特定轉換的影像傳送 HTTP 請求,例如編碼及大小。轉換會在 URL 進行編碼,以更準確的方式作為查詢參數。URL 範例如下所示:https://exmaples.com/images/cats/mycat.jpg?format=webp&width=200
  2. 請求由附近的 CloudFront 邊緣節點處理,提供最佳效能。在向上游傳遞請求之前,會在檢視器請求事件執行 CloudFront Functions,以便重寫請求 URL。CloudFront Functions 是 CloudFront 的一項特徵,可讓您利用 JavaScript 編寫輕量函數,以便進行大規模、延遲敏感的 CDN 自訂。在我們的架構,我們重寫 URL 以便驗證請求的轉換,並透過排序轉換來將 URL 標準化,並將其轉換為小寫以利增加快取命中率。當要求自動轉換時,函數也會決定要套用的最佳轉換。例如,如使用者使用指令 format=auto 要求最高度最佳化的影像格式 (JPEG、WebP 或 AVIF),CloudFront Function 會根據請求中存在的接受標頭來選取最佳格式。
  3. 如果 CloudFront 已快取請求的影像,則會發生快取命中,並從 CloudFront 快取傳回影像。為增加快取命中率,我們啟用 Origin Shield,這項 CloudFront 特徵可在來源前作為額外快取層,以便進一步將其從請求卸載。如果 CloudFront 快取無該影像,則將轉送請求到 S3 儲存貯體,該儲存貯體的建立目的是為了儲存轉換的影像。如果請求的影像已轉換並儲存在 S3,則只需透過 CloudFront 提供並加以快取。
  4. 否則,S3 會以 403 錯誤代碼回應,且 CloudFront 的原始容錯移轉會偵測到該代碼。由於這項原生特徵,CloudFront 會重試相同 URL,但這次採用基於 Lambda 函數 URL 的次要來源。當被調用時,Lambda 函數會從另一 S3 儲存貯體下載原始影像 (儲存於該儲存貯體)、利用 Sharp 程式庫進行轉換、將轉換後的影像儲存在 S3,然後透過 CloudFront 來提供,並進行快取以便用於未來請求。


若要部署此解決方案,請按照此部落格的步驟操作。此外,此部落格會向您展示如何與 Next.JS 的影像元件搭配使用。請注意,此解決方案允許您針對轉換後的影像停用將其儲存於 S3 的功能,僅依賴 CloudFront 快取來提供轉換後的影像。

第三方受管解決方案

若您偏好採用第三方受管影像最佳化解決方案,請考慮 AWS Marketplace 的可用解決方案,例如 CloudinaryImageKit.io Cloudimage。若您想管理自己的 CloudFront 分佈,這三者均採用 CloudFront 或已整合 CloudFront。此類第三方供應商專門從事影像最佳化,可提供進階 SaaS 功能,但需要額外費用。

資源

本頁對您是否有幫助?