手機實際下載的是哪一張圖片？

網頁上圖片佔的空間小，並不意味著下載檔案也小。如果所有訪客都收到同一張大圖，手機仍可能下載版面配置用不到的像素。壓縮和響應式選擇分別解決其中一部分問題。

網站圖片流程介紹準備工作，圖片交付指南解釋性能診斷。這次從準備檔案追蹤到瀏覽器真正選擇的資源，直接觀察一張照片，而不把評分當作結果。

我們先在外部圖片編輯器中等比例製作複本，再進行壓縮，Bitinz 沒有調整尺寸。2026-10-29，各複本用本地引擎均衡等級處理；記錄的尺寸、位元組數和雜湊值對應瀏覽器實驗所用的候選檔案。

本地網頁通過 srcset 提供候選圖片，並用匹配的 sizes 規則描述版面配置。瀏覽器記錄包含可視區域寬度、像素密度和所選資源，只測圖片檔案，不代表整頁加載或模擬移動網路速度。證據方法見內容編寫說明。

先比較這些檔案，再看來源中的瀏覽器選圖記錄。瀏覽器只能在網頁實際提供的候選項中選擇。

Bitinz · 1 KB = 1000 位元組。

每列都使用全新瀏覽器環境並關閉快取。最寬的高密度情境選擇了最大的候選圖，因為候選清單在這個位置有較大空檔。值得另外測試一個中間尺寸：瀏覽器只能選擇清單裡確實存在的檔案。

原始照片細節

壓縮後照片細節

在小螢幕和高像素密度顯示器上查看照片。如果最小候選圖已經明顯發糊，就不一定適合；同樣，一張大候選圖即使節省比例很高，也不代表有必要下載。

選圖記錄是指定環境的一次觀察。緩存和瀏覽器自己的決策會影響後續訪問；復現時請用全新瀏覽器環境，檢查實際請求，而不是只憑顯示尺寸推測。

先用圖片壓縮工具處理準備好的複本，再讓網站或內容管理系統提供合適版本。如果生成的網頁始終指向同一大檔案，壓縮本身不會改變這個選擇。

讓 sizes 與 CSS 版面配置保持一致。瀏覽器結合這個提示、候選尺寸和螢幕密度做選擇，不能靠檔案名猜出作者的意圖。版面配置變動後，再查一次實際請求的資源。

對於反覆執行的發布流程，開發者 API可以壓縮準備好的檔案。縮小尺寸仍是獨立的準備步驟。畫質指南介紹替換圖片前如何比較細節。

1. 01測量圖片展示區域，確定設計需要的等比例寬度。
2. 02保留可編輯原圖，準備並壓縮這些複本。
3. 03提供候選圖片，讓 sizes 規則與版面配置相符。
4. 04在不同螢幕上檢查所選資源和實際觀感。