產品圖片跨螢幕呈現：選對檔案與載入次序

先決定圖片須呈現甚麼

先問圖片要協助顧客作甚麼購買決定，而非先選格式。產品詳情頁可能需要顯示全件商品的主圖、呈現尺寸或表面的其他角度，以及檢視細節的放大圖。目錄卡片的顯示尺寸不同，裁切後仍須能辨認商品。記錄圖片在窄手機、較大手機與桌面畫面的出現位置，以及實際 CSS 顯示寬度。這份清單可幫助決定製作哪些原檔，以及哪張相片最可能率先進入視窗。不要只因工具能輸出不同版本就製作大量檔案；每個版本都應服務某個版位或像素密度需要。同一相片的解析度版本須保持主體和重要細節一致。

要分清「同一畫面換解析度」與「按版面改裁切」。MDN 解釋，srcset 的寬度描述和 sizes 可讓瀏覽器按預期顯示寬度，在同一相片的不同版本之間選擇。若窄畫面真的需要另一種裁切，才用 picture 來源作編輯上的改圖決定。例如只裁到水壺蓋，卻藏起可辨別型號的手柄，便不合適。採用前須在每個斷點查看實際像素。解析度較高的檔案若呈現錯誤細節，也不會更有用。當裁切改變了顧客可見資訊，替代文字亦須與交付版本所傳達的內容一致。

讓候選寬度配合版面

在使用寬度描述的 srcset 時，每個描述值代表檔案本身的像素寬度；sizes 則描述不同媒體條件下圖片預期佔用的版面寬度。瀏覽器把兩者和裝置特性合併，選擇合適版本。若 CSS 在桌面只讓商品圖佔半欄，sizes 卻宣稱圖片永遠佔滿整個視窗，瀏覽器可能下載過大的檔案。相反，若 sizes 低估版位，圖片就可能顯得模糊。請在代表性的畫面寬度查看實際版位，與 sizes 規則比較。保留 src 後備來源，讓未使用響應式選擇的情況仍能顯示圖片。不可把描述寬度寫得與檔案實際像素不符。

根據已量度的版位選擇實際需要的候選檔，再在真實裝置比較傳輸大小與視覺品質。細小目錄縮圖與橫跨詳情頁的主圖，不一定要共用同一組尺寸。壓縮及格式選擇要看商品紋理、包裝文字、邊緣和透明部分的實際效果，不宜只靠全站預設。不能為了減少檔案大小，抹去影響購買決定的視覺證據。若有不同裁切或格式分支，請核對後備來源及所有分支所示的商品、顏色和狀態一致。業務風險不只是多下載幾個位元組；錯配版本可能令買家誤解所售商品。

下載前預留正確空間

瀏覽器知道圖片長寬比例後，便可先預留空間。img 可設定與來源比例一致的有意義 width 和 height 屬性，再由 CSS 按可用寬度縮放；這不代表每張圖都以原始像素大小顯示。MDN 的 img 指引說明，尺寸資料有助避免圖片載入時推動其他內容，但版面仍須符合響應式限制。若按版面裁切的來源有不同長寬比，便要逐個分支處理，不能假設桌面比例套用到所有手機版本。以慢速載入情況檢查，產品名稱、價格和加入購物車操作不應在主圖出現時突然跳動。這是具體版面驗收，並非聲稱所有位移都由圖片造成。

亦要訂明遇到特別高或特別闊的原相時，圖片容器怎樣處理。固定視覺版位配合 object-fit 可能裁掉邊緣；彈性高度可保留所有像素，卻可能把購買控制項推到頁面很下方。應按相片需要呈現的資訊決定，並用真實目錄測試，包括標籤很長的包裝和直向拍攝商品。若使用裁切，重要商品特徵在每種視窗寬度都須留在可見安全區。圖片單獨看很漂亮，放進實際卡片或詳情頁樣板仍可能失效。請同時檢查最初畫面與載入完成的畫面。

先讓可見主圖及時載入

若產品主圖很可能在首屏出現，不應給它設定 loading="lazy"。Google 的 web.dev 圖片指引警告，延後首屏圖片可推遲最大內容繪製。應讓瀏覽器及早在 HTML 找到主圖；若實際量度發現它是 LCP 元素，而且請求發現得太遲，便檢查樣板和網絡瀑布圖。fetchpriority="high" 可向瀏覽器提示真正重要的圖片，但要審慎使用，不能把所有商品相片都提高優先級。不同視窗和內容下，最大的元素可能是標題或另一張圖。先按顧客實際看到的頁面測試，再決定優先次序。

頁面下方的相簿相片或長產品目錄，可考慮延遲載入，以免與可見主圖爭用網絡資源。應按所在位置判斷，而非替所有 img 一律加上該屬性。顧客切換款式後立即顯示的相片，策略可能不同於幾個畫面以下的照片。要確認捲動、鍵盤導覽及沒有 JavaScript 增強時仍可載入；重要商品資料也不能藏在永遠到不了的圖片內。更改前後可比較實際下載位元組，以及主圖何時可供觀看。否則所謂優化可能只是把成本轉移，甚至讓顧客作決定時看到空白圖。

以一件商品驗證所有分支

想像一款有兩種表面的陶瓷杯：手機目錄卡片尺寸較小，桌面詳情頁則在價格和尺寸資訊旁顯示大相。由各種表面的正確原相製作不同解析度，按實際量得的版位設定 sizes，並提供 src 後備。讓可見詳情主圖有穩定尺寸並及早載入；頁面下方相簿可以稍後載入。在窄手機檢查裁切是否仍看到杯柄和表面質感。切換款式後，再核對相片、標籤與可購買的款式是否一致。這些是示例情境的設計假設，不代表現有商店數據、轉換率或通用候選寬度。

建立驗收表，記下實際頁面網址、視窗寬度、所選款式、顯示版位、下載檔案及可見裁切。應檢查瀏覽器真正選中的來源，不要假設一定使用 src 所列檔案。以慢速連線、高密度螢幕及流量有限的裝置測試。單看效能儀表板，未必知道商品紋理已變得誤導；單看圖片外觀，也未必知道手機下載了過大的桌面版本。兩者都要檢查。若圖片不是實際瓶頸，就保留較簡單設定，另查真正延遲原因。最終要在實際樣板上，驗證商品呈現真實、首屏可用、版面穩定及傳輸量合理。

首次推出後仍須有人管理圖片版本。商戶更換主相時，發布流程應重新產生所有仍在使用的候選檔，並有控制地更新版本或處理舊快取。否則窄手機可能顯示新表面，桌面卻仍從快取取得舊顏色。記錄主檔、衍生寬度、按版面裁切及商品款式之間的關係。移除某張產品圖後，檢查 srcset、picture 來源、頁面結構化資料和相簿縮圖是否仍引用它。目錄更新後，簡單的資產清單加上畫面抽查，便可找出頁面速度分數永遠不會指出的錯配。目標是讓每種螢幕都呈現一致的商品資訊。