網店如何為手機及桌面版提供合適的商品圖片？

先看顧客要判斷甚麼

商品照片會影響購買決定：顧客可能要查看外形、表面質感、接駁位或隨附配件。壓縮不能令這些細節消失。先按用途盤點圖片，而非全站套用同一壓縮設定。目錄縮圖、商品主圖、放大圖及情境照的顯示尺寸和細節要求都不同。記下在窄屏手機與桌面版各自佔用的闊度、是否位於首屏，以及顧客能否開啟較大版本。底圖須忠實反映商品；檔案雖小但看不清重要細節，會帶來另一種購物風險。Google 亦同時提倡清晰影像及合適的響應式尺寸。

響應式傳送通常是為同一張照片預備不同像素闊度的版本，再告訴瀏覽器每個檔案的實際尺寸。若在 srcset 標為 800w，該檔案就應真是 800 像素闊。sizes 描述版面上圖片會佔的空間，它本身不會改變畫面的顯示尺寸；實際版面仍由 CSS 控制。瀏覽器會把這個空間與裝置的像素密度等資訊一起考慮，選擇適合的檔案。保留一般 src 網址作為基本後備。內容團隊應檢查 CMS 或圖片服務真的產生對應檔案，不能只在同一張超大原圖外加幾個屬性。

假設某網店的陶瓷杯照片在手機上約佔 360 個 CSS 像素，在桌面商品頁約佔 620 個；這只是版面示例，不是網站量度結果。商店可準備涵蓋兩種顯示需求及高像素密度裝置的數個來源闊度，再看各種視窗實際選了哪個。沒有適用所有網站的固定斷點清單：平板雙欄、放大功能及不同裁切都會改變需要。若目錄縮圖與商品詳頁雖然顯示尺寸相差很遠，仍下載同一個大型檔案，應先檢查實際傳輸。目標是讓顧客看清需要的細節，同時避免無謂下載像素。

預留空間與安排載入次序

圖片到達前，瀏覽器需要知道應預留多少位置。可使用有意義的 width、height 屬性或等效比例；商品頁的價格、款式選項及購買按鈕若在照片旁邊或下方，版面跳動尤其惱人。所標示的比例應符合該組來源圖片。若手機版本採用不同裁切比例，便要專門處理，不能硬把它拉成桌面版本形狀。檢查時讓圖片在較慢連線下逐步載入；等頁面完全穩定後才截圖，便看不到顧客實際遇到的跳動。

延遲載入需要選擇性使用。Google 的 web.dev 指引指出，首屏可見的圖片，特別是可能成為最大內容繪製元素的主圖，一般應正常及早載入。屏幕下方的目錄圖片可考慮 loading=lazy；若把它無差別加到商品主圖，反而可能延遲顧客最想看的影像。預先載入所有圖片同樣會破壞優先次序。先找出可能是主要視覺元素的圖片，再用真正的商品頁樣板測試，而不是只看空白測試頁。手機上的長頁首或促銷區可能改變首屏位置，須按實際版面確認。

檔案格式與壓縮率要在可接受的畫質範圍內選擇，不能改變商品內容。以商店支援的格式輸出代表照片，在同一顯示尺寸比較表面質感、需要閱讀時的包裝細字，以及傳輸大小。透明背景商品圖與一般照片或有不同需要。保留原始母檔，避免每次裁切都由已壓縮的版本再次轉存。若圖片服務按請求即時轉換，還要檢查快取鍵及產生的版本是否仍對應正確商品與顏色。效能報告中的裁切圖再清晰，也不能因此顯示錯誤色款或錯配件。

核實實際交付效果

在手機、平板及桌面闊度打開具代表性的目錄頁與商品詳頁。使用瀏覽器開發工具記錄顯示尺寸、currentSrc 網址、檔案原有像素尺寸、傳輸量，以及圖片在滾動前後何時出現。這些是店主應自行收集的網站觀察；本文示例數字並非 Astera 客戶的實績。高像素密度手機也要測試，因為瀏覽器選用比 CSS 顯示框更大的檔案，未必就是錯。應比較下載檔案與其顯示用途，而非只看是否取用了最大原圖。慢連線及回訪情況亦值得重測，以觀察首次載入與快取效果。

可按圖片用途建立簡短驗收表。商品主圖應盡早、穩定而清楚地呈現，讓顧客查看重要細節。目錄縮圖在滾動時不應造成不必要的大檔案傳輸，每張卡片亦應先預留照片位置。放大圖應在顧客要求時提供較多細節，而不是讓每位訪客一開始就下載巨型檔案。若中英文版面闊度不同，兩者都要測試；但僅因說明文字變成中文，並不代表需要另一套圖片像素。替代文字有其無障礙用途，選字與選檔案尺寸屬不同工作。

Google 的圖片指引亦指出，標準 HTML img 元素有助搜尋器發現圖片，使用 picture 或 srcset 時應保留 src 後備網址。希望商品照片可公開被發現的網店應留意這點。核對所選圖片網址能正常回應，商品頁周邊內容亦準確描述商品；不要把所有重要商品照片只放在 CSS 背景。改動後至少再檢查一種特殊商品，例如特別高的物件、深色表面，或具有細小接駁位的設備。這些例子容易揭示一般樣本看不出的裁切或壓縮問題。把最後選用版本及例外情況記錄給內容團隊。

實際製作流程應由新商品拍攝時開始。母檔以商品身份命名，記錄核准的裁切與顏色，再按有文件紀錄的方法產生各個衍生版本。若不同色款共用樣板，色款與圖片對應關係必須明確；效能優化絕不可把藍色商品圖誤放在黑色商品頁。每次大量匯入後抽樣檢查，因圖片服務可能只在特殊方向或檔名出錯。內容編輯需在發布前預覽手機裁切，開發人員則要查看網絡實際選取的資源。前者核對照片是否真實，後者核對傳送是否有效率，兩者都應納入驗收，並指定誰負責修正不合格的圖片。

證據未明確時，先選可回退的改動。若公司自己的分析資料確實指出高流量頁面，可先處理相關樣板；否則選一組具代表性的商品，不要把它稱為流量冠軍。前後比較須使用相同裝置及連線假設，保留截圖與網絡記錄。若傳輸量下降卻令顧客看不清材質，應恢復畫質或改善放大途徑。手機圖片若清晰但到達太遲，要先檢查載入優先次序及伺服器回應，而不是再壓縮一次。真正的量度結果應交代網址、裝置、日期與觀察條件；沒有這些證據，就只應描述預期原理及測試方案。頁面樣板或圖片服務改動後要再檢查，因舊結果可能已不適用。