圖片縮放

為什麼一次縮小會很難看

當瀏覽器在單一操作中把大圖畫進小得多的空間時，它只會取樣有限數量的來源像素，其餘則忽略。落在取樣點之間的細節不會被平均進去，而是直接被丟棄，結果就是鋸齒：斜線參差不齊、細緻紋理閃爍，文字變成雜訊。這就是為什麼只用 width 屬性縮小的圖片，通常比用影像編輯軟體縮小的同一張圖難看。

這裡採用的解法是反覆把圖片縮成一半，最後才做那一小步。每次減半都會平均每四個像素，所以到達目標尺寸時，每個輸出像素都是由它所代表的整個區域計算而來，而不是取自其中某個任意的取樣點。這與圖學中的 mipmap 原理相同，在大幅縮小時差異非常明顯。

專業工具會更進一步使用 Lanczos 等濾波器，參考更大範圍的鄰近像素加權計算，保留稍多一點的視覺銳利度。逐次減半的效果已經相當接近，在照片上很難看出差別，而且速度快到在手機上也能即時預覽。

如何決定目標尺寸

依照圖片要顯示的位置決定尺寸，再考慮像素密度。在頁面上以 800 CSS 像素寬顯示的照片，要在每個 CSS 像素對應兩個裝置像素的現代手機或筆電上看起來清晰，需要約 1600 像素。超過 2 倍後，視覺上幾乎沒有提升，檔案大小卻會大幅增加。

如果頁面要服務多種裝置，較好的做法是準備多種尺寸並使用 srcset 屬性，讓瀏覽器自行挑選。640、960、1280 與 1920 這幾種常見寬度能涵蓋大多數版面。電子郵件請控制在 600 像素左右。文件或簡報則以放置尺寸的 2 倍為準。

千萬不要為了達到目標而放大。放大只是捏造出沒被拍到的像素；它讓模糊的圖變得更大也更模糊，檔案變大卻毫無好處。如果需要比來源更大的圖，該換的是來源本身。

上限，以及它存在的原因

可接受的檔案上限為 30 MB，圖片上限約為 1,670 萬像素，大約是 4000×4000，或任何總面積相同的其他比例。

這個上限來自瀏覽器的 canvas，而不是隨意訂定的規則。尤其是 iOS 上的 Safari 會限制 canvas 可涵蓋的面積，而超過上限時的失敗方式最糟糕：沒有錯誤、沒有例外，只是交回一張空白的白色圖片，彷彿一切正常。為了避免這種情況，超過上限的圖片會附上說明直接拒絕。如果你要縮小 5000 萬像素的 RAW 匯出檔，桌面影像編輯軟體才是合適的工具。

批次處理之所以一次處理一張而不是平行處理，也是同樣的原因。解碼後的圖片不論壓縮檔多小，都會在記憶體中占用寬 × 高 × 4 個位元組，同時處理好幾張大圖，正是讓手機瀏覽器關閉分頁的原因。

縮放、裁切還是壓縮

這三者解決的是不同的問題，而當真正的目標是讓檔案變小時，它們常常被混為一談。

縮放改變的是像素的數量，是影響檔案大小最有效的手段，因為效果是平方級的：寬高各減半，像素數量就變成四分之一。它會改變原尺寸下看得到的內容，但保留整個畫面。

裁切改變的是畫面中包含什麼。它同樣會減少像素，但這是構圖上的決定，而非技術上的決定，而且無法復原。

壓縮改變的是現有像素儲存的精確程度，也就是圖片轉換工具中的畫質設定。它不改變尺寸，以保真度換取檔案大小。

對於網頁上太大的照片，有效的順序是先縮放到顯示尺寸，再以合理的畫質編碼成 WebP 或 JPG。只做後者，通常會錯失大部分可以省下的空間。

縮小為什麼非得用濾鏡不可

縮小影像等於要為每一個輸出像素回答一個問題：什麼顏色能代表原圖的這塊區域。直接取最接近的來源像素、無視它的鄰居，是最省事也最糟糕的答案，因為落在取樣點之間的細節被丟棄而不是被平均掉，而這些被丟掉的細節會以照片裡從未存在過的圖樣重新冒出來。

這就是疊頻失真，和電影裡看起來倒著轉的馬車輪子是同一回事。用低於細節所需的頻率去取樣，並不會讓細節安靜地消失，而是把它折回影像中，變成一種虛假的、頻率更低的圖樣。細緻的紋理會閃爍，斜線會呈階梯狀，小字則變成一團雜訊。

解法是對每個輸出像素所代表的整塊區域取平均，而不同濾鏡對這個平均的加權方式不同。方框平均簡單，成像略軟；Lanczos 以 sinc 為基礎的曲線對更大範圍的鄰域加權，能保住較多視覺上的銳利度，代價是硬邊附近會出現淡淡的振鈴。這裡採用的逐次減半，用極低的成本就達到了接近的效果。

尺寸、長寬比與裁切

縮放保留整個畫面，改變的是用多少像素去描述它；裁切改變的則是畫面本身。把兩者搞混，就會做出你在粗製網站上看到的那種變形影像：一張寬幅照片因為寬高被分別設定，硬是被擠進正方形的容器裡。

當版面要求固定形狀時，請刻意去裁切，而不是硬拉變形。CSS 的 object-fit 搭配 cover 可以在瀏覽器裡做到這件事，用在裝飾性圖片上沒問題；但只要主體本身重要，事先裁切才能掌握畫面留下什麼。自動置中裁切在合照裡砍掉人頭的準確率高得驚人。

藝術指導指的正是一種裁切不夠用的情況：在桌機上效果很好的寬幅主視覺，在手機上往往需要一個更緊湊的直式裁切，而不只是同一個畫面的縮小版。這正是搭配媒體條件的 picture 元素的用途，與 srcset 不同，後者提供的是同一個裁切的不同尺寸。

圖片重量對頁面的代價

圖片通常是一個頁面下載內容中最大的部分，而最大內容繪製（Google 在 Core Web Vitals 中回報的指標之一）也往往就是一張圖片。那個檔案裡每一個多餘的 KB，都會延後頁面看起來已經載入完成的那一刻。

一個可行的預算是把主視覺圖片控制在大約 200 KB 以內，首屏以下的圖片則要小得多；只要尺寸抓對了，用一般的品質設定就能達成。直接送出一張 3 MB 的照片再讓 CSS 把它縮小顯示，是內容型網站上最常見的效能問題，而且不只浪費訪客的時間，還吃掉他們的流量。

另一半是版面穩定性。沒有宣告 width 與 height 的圖片不會預留空間，所以圖片一送達，下方的文字就會往下跳。把這兩個屬性設好，或在 CSS 裡設定 aspect-ratio，都是一行就能完成的改動，卻能消除一整類看得見的缺陷。

一次處理大量圖片

只有幾個檔案時，瀏覽器工具是最快的途徑。超過幾十個，或是要放進建置流程時，能寫成腳本的工具更合適：ImageMagick 的 mogrify -resize 1600x -quality 82 *.jpg 一道指令就能處理整個目錄，而 sharp、libvips 或 Pillow 能在 Node 或 Python 的流程中做同樣的事，記憶體用量遠比它們的名聲低得多。

兩個習慣能避開常見的意外。第一，對副本動手，因為 mogrify 預設就地覆寫，而且沒有復原可言。第二，使用像 1600x 這種只限定寬度的條件，而不是固定的寬高，這樣直式與橫式照片都能處理，也不會變形。

對於會接收使用者上傳的網站，縮放應該在收檔時做一次，而不是每次請求都做，並在你日後可能需要其他尺寸時保留原始檔。透過圖片 CDN 隨需衍生各種尺寸是另一種合理架構；在頁面裡用 CSS 縮小則不是，因為不管怎樣完整的檔案都已經被下載了。

放大，以及 AI 工具改變了什麼

把影像放大，無法救回從來不曾被拍下的細節。古典的內插法（雙線性、雙三次、Lanczos）是用同樣的資訊做出一張平滑的大圖，看起來很軟，因為它本來就很軟。這不是演算法的缺陷，而是那些資訊真的不存在。

機器學習放大器則靠著它先前見過的東西，捏造出看似合理的細節，因此結果更銳利。做桌布，或把度假照片印出來，這往往正是你要的。但只要牽涉到證據性質的東西，例如文件掃描檔、顧客會據以判斷的商品照、新聞報導中的圖片，這就是個嚴重的問題，因為多出來的細節只是猜測，卻以和真實像素同等的自信呈現出來。

可靠的原則始終不變：從源頭修。從原始檔重新匯出、用更高解析度重新掃描，或是直接索取你需要的尺寸版本。其餘的做法，都是拿捏造出來的材料在修補。