把照片在網頁上拉小，不代表讀者下載的檔案也變小。反過來說，把品質一路往下調，雖然省了空間，也可能讓產品紋理、細線與文字變得難辨識。
這篇要完成的練習，是為同一張照片做兩個設定版本，記錄尺寸、格式、品質與大小，再決定哪個值得進入網站驗收。 適合自己更新官網的店家、工作室與內容編輯；準備可執行 JavaScript 的瀏覽器即可，先用官方範例，不必登入、訂閱或提供客戶圖片。
本文屬於網站上線前的素材準備。若你還沒決定圖片用途，先在網站需求與驗收規格裡寫清楚：放在哪一頁、讀者需要看清楚什麼，再開始壓縮。
一、先分清尺寸、檔案大小與品質
尺寸是圖片的像素寬高，例如 1200×803；檔案大小是儲存或傳輸的資料量，例如 106 kB。相同尺寸換格式、調品質，大小可能不同；縮小寬高也會影響細節，不能把兩種效果混在一起。
Squoosh 的 Quality 是所選編碼器的設定值，75 不表示保留了 75% 畫質，也不能直接拿 WebP 的 75 與另一種格式的 75 比輸贏。 這篇固定格式與尺寸，只改品質來做第二輪比較。
網站顯示寬度也不等於圖片需要的像素寬度。依 web.dev 的圖片密度說明，例如顯示 400 個 CSS 像素、像素密度為 2 的情境，可用 800 像素寬的來源避免放大不足；實際選圖還受版面與瀏覽器條件影響。不要因此規定所有手機圖都做成同一寬度。
本篇的 1200 像素是固定練習條件，不是所有首頁大圖、商品照或手機圖片的最佳答案。
二、開啟工具，先保留原圖與用途
前往 Squoosh 官方網站，選首頁的 Large photo 範例。查核當天它載入 photo.jpg，原始尺寸 3872×2592，編輯器顯示約 2.79 MB；這是工具的示範照片，不是客脈客戶案例。
換成自己的圖片時，先保留原始檔，另外命名輸出版本，例如 product-detail-1200-q75.webp。不要直接覆蓋唯一原圖，也不要在已經嚴重壓縮的版本上反覆轉存。
官方專案的隱私說明表示圖片壓縮在裝置本地處理，但也列出 Google Analytics 的基本使用資料與壓縮前後大小收集。因此「圖片不送到壓縮伺服器」不等於整個網頁完全沒有網路連線；敏感素材仍應遵守自己的資料處理規則。
下載本次設定紀錄與空白驗收表（TXT）。範本只記錄設定與觀察，不包含或轉授權官方照片。
三、六個步驟，做出兩個可比較版本
- 在首頁選 Large photo，保留左側 Original Image 作為參考。確認自己正在調整右側輸出欄，而不是改了另一邊。
- 右側 Compress 選 WebP，保持 Lossless 關閉、Effort 為 4；Quality 先設 75。這些是本次比較條件，不是通用推薦值。
- 開啟 Resize，保留 Maintain aspect ratio；Method 使用 Lanczos3，Width 填 1200，Height 會成為 803。Premultiply alpha channel 與 Linear RGB 保持勾選，Reduce palette 關閉。
- 等預覽與大小更新完成，再記錄數值。拖曳中央比較線檢視同一位置，查看毛髮、邊緣與平滑色塊；不要在編碼尚未完成時抄下上一個設定的結果。
- 尺寸、格式與其他條件不變，只把 Quality 改成 50。再次等待結果，記錄第二組大小與可接受／需重做的理由。回頭比較時也只改這個值。
- 決定候選版本後，使用右側 Download 下載，另外命名。重新開啟下載檔，核對能否顯示、格式、像素寬高及大小，再交給網站的預覽環境驗收。
畫面上的放大預覽很適合找出細節損失，但正式用途還要回到實際顯示尺寸。縮圖後的預覽若以較大尺寸呈現，看起來更糊，不能把這個差異全算到品質參數上。
四、本次實測結果，哪些可以下結論
2026-09-16，本次在桌面瀏覽器操作 Squoosh 官網的 Large photo，核對設定與完成後的預覽。以下大小是工具介面顯示的約值，沒有把它當成逐位元檔案測量。
- 原圖： photo.jpg，3872×2592，約 2.79 MB。
- 版本 A： WebP、1200×803、Quality 75、Effort 4，約 106 kB；介面顯示比原圖小 96%。
- 版本 B： 相同尺寸、格式與 Effort，只改 Quality 50，約 77.3 kB；介面顯示比原圖小 97%。
這組結果顯示：在本次照片與設定下，降低品質值得到較小的輸出。A 與 B 約差 28.7 kB，是用顯示約值相減的結果。不能據此宣布所有圖片都應該選 50，也不能說 96% 全是 WebP 的功勞，因為原圖到 A 同時改了尺寸與編碼。
預覽已目視檢查，縮小後毛髮等細節在放大畫面中會減少；本篇沒有把任何版本評為「無損」或「肉眼完全一樣」。下載控制已操作，但本次未取得可獨立核對的落地檔，因此下載後重新開檔、逐位元大小及網站實際載入仍列為後續驗收，沒有寫成已完成。
這次也沒有替換客脈正式網站圖片、測量 LCP 或訪客速度。壓縮器的大小結果，只能支持素材層面的比較，不能當成搜尋排名、轉換率或網站載入時間的改善證據。
五、上網站前，用四項條件驗收
先在網站預覽頁放入候選圖，再用桌面與手機的實際版面檢查。沒有後台或預覽權限時，可以先交付檔案與設定紀錄，網站項目標示待驗收。
- 內容可辨識： 商品紋理、必要文字、細線與顏色是否足以完成原本用途。這張動物照片不能代表中文截圖或商標也適合相同參數。
- 構圖正確： 手機裁切是否切掉主體、標籤或重要資訊；不要只在壓縮工具裡看全圖就認定網站一定正常。
- 載入正確： 網站是否真的使用新檔，還是仍連到舊檔或其他尺寸版本。技術人員可在瀏覽器 Network 查看實際圖片請求；一般編輯可請維護者提供請求網址與大小紀錄。
- 空間穩定： 圖片載入前後是否讓文字或按鈕明顯跳動。web.dev 建議以圖片寬高或對應比例預留空間，詳見圖片尺寸與版面位移說明。
如果網站已自動產生不同尺寸與格式，先確認既有處理方式，再決定要上傳什麼原始素材。開發者可以依版面搭配 srcset 與 sizes，讓瀏覽器選擇候選圖；單一 1200 像素檔案不等於完成響應式圖片設定。
效能報告與圖片驗收也分開記錄。需要看報告時，可接著讀 Microaudit 健檢與誤判判讀，保持相同測試條件，不用一次分數變化推論長期成效。
六、常見錯誤與免費使用範圍
- 把副檔名改成 .webp。 改名不會重新編碼，必須真的由工具輸出相應格式。
- 只追求最小的 kB。 若必要資訊變模糊，應提高品質、調整尺寸，或重新考慮素材格式與用途。
- 每張圖片都壓到同一大小。 照片、細字截圖與透明標誌需要不同檢查；本篇沒有實測所有格式與素材類型。
- 看到較小結果就刪原圖。 保留原圖及各版本設定，才有辦法重新輸出較大的尺寸。
本次載入範例、調整設定及取得預覽結果，沒有登入或付款。Squoosh 是在瀏覽器執行的開源工具；大量或高解析度素材仍受裝置記憶體與處理時間限制，本篇沒有測試批次處理上限，也沒有宣稱任何網站都能直接接受 WebP。
七、你的練習：交付一張圖與一個選擇理由
先用 Large photo 重做一次，確認知道左右欄與下載位置；再用一張自己有權使用的網站照片，寫出它的顯示用途，做兩組只改一個條件的比較。
紀錄檔名、日期、尺寸、格式、品質、大小、目視結果與驗收狀態。選擇理由可以是「較小版本的產品細節不足，因此保留較高品質」，也可以是「兩者在預期版面都能辨識，先交較小版本做網站驗收」；不用為了減少檔案大小而犧牲資訊。
完成標準是：原圖仍保留、候選檔可重新開啟、設定能重做、選擇有理由。手機版面與實際請求尚未檢查時就保留待驗收，不把素材準備當成正式網站改善已完成。需要委託維護時，可用網站廠商比較與交付問題確認誰負責這段驗收。
查核日期：2026-09-16。本文由 AI 輔助整理官方資料、瀏覽器操作與預覽觀察；範例為 Squoosh 官方示範素材，未宣稱真人審稿、客戶成果、正式網站效能提升或新增詢價。介面與結果可能隨工具版本、範例及環境改變，請保留自己的實際紀錄。