截圖壓到 130 kB 就能上線？用 Squoosh 做雙版本驗收

網站要放操作畫面或產品截圖時，常見做法是把圖片壓到最小就上傳。但截圖裡的小字、按鈕邊線和圖示，比照片更容易在有損壓縮後變糊。今天的目標只有一個：用同一張圖做「有損／無損」兩個版本，依實際閱讀用途選，而不是只比百分比。

適合自己更新網站的店主、工作室和內容編輯。準備一台可開瀏覽器的電腦即可；先用 Squoosh 內建範例，不必上傳客戶截圖，也不需帳號。以下數字是我在 2026-09-26 桌面瀏覽器看到的工具介面約值，換圖或換設定都可能不同。

【五分鐘做一輪】

1. 開啟 Squoosh 首頁，點「Device screen」範例。編輯器載入 pixel3.png；左側保留原圖，介面顯示約 1.62 MB。先不要開 Resize，讓兩輪尺寸相同。

2. 右側 Compress 選 WebP，Lossless 關閉，保留 Quality 75、Effort 4。等計算完成，這次介面顯示約 130 kB、比原圖少約 92%。這只是該範例的檔案大小比較，不代表網站快了 92%。

3. 把 Lossless 打開，保持「Slight loss」為 0；工具切到無損模式，這次顯示約 996 kB、比原圖少約 39%。注意模式改變後 Effort 也變成 6，所以這是「兩種輸出設定」的比較，不是只改一個參數的嚴格實驗。

4. 用畫面中央的分隔線對照原圖與輸出，放大看按鈕文字、細線、圖示輪廓與色塊交界。先在 100% 檢查，再縮到實際頁面會顯示的寬度。若文字難辨、線條破碎，就不要只因有損版較小而採用。

5. 各下載一版，檔名註明格式與設定，再放回網站草稿頁。請另一人用手機實際讀出截圖中的關鍵資訊，並查看頁面有沒有載入錯圖、被裁切或顯示過大。通過後才替換正式圖片；保留原始檔以便重做。

【怎麼判斷？】這張內建範例同時有照片和介面元素，不能代替你自己的密集文字截圖。若截圖是純色介面、表格或教學步驟，小字是否可讀應優先於檔案最小；若是照片，可能有更大的壓縮空間。每張圖分開看，不把「Quality 75」解讀為保留 75% 畫質，也不把不同格式的數值直接當成同一尺度。若網站平台不接受 WebP，先確認可用格式或提供相容版本，不必為了新格式破壞上線流程。

最常見的錯誤有三個：只看 Squoosh 的縮小比例、只用桌面大圖判斷清晰度、以及在比較時同時改尺寸與格式卻把差異全歸因於格式。今天只量到範例圖在工具中顯示的約略大小，沒有下載後精確量測，也沒有測官網載入速度、搜尋排名或詢價效果。

你可以拿一張不含個資的自製截圖，記錄原始大小、兩個輸出設定、畫面中的一處最小文字，以及手機上能否讀清；寫下最後選哪版和理由。Squoosh 可免費在瀏覽器使用。官方專案說圖片壓縮在裝置本地處理，但網站仍使用分析資料；涉及敏感素材時，先依自己的資料規範判斷能否使用線上工具。

官方工具與隱私說明（查核：2026-09-26）：

https://squoosh.app/

https://github.com/GoogleChromeLabs/squoosh#privacy

照片縮尺寸及 WebP 品質比較的延伸練習：

https://kemai-ai.com/blog/squoosh-website-image-compression-guide?utm_source=nabi&utm_medium=community&utm_campaign=14day-learning-test

整理／配圖：客脈 AI。配圖為 AI 生成概念示意，非實際壓縮畫面；本文數字只描述上述內建範例的當次操作。