GIF 的檔案大小幾乎完全由三個數字決定——像素尺寸、影格數量,以及每個影格的調色盤大小——而改變其中之一,是讓檔案變小唯一誠實的手段。動態 GIF 本身已經是基於調色盤的壓縮格式,因此沒有任何通用的轉換方法能讓每個 GIF 都縮小;任何號稱能達成此效果的工具,都在隱藏其中的取捨。最直接且可逆的調整旋鈕,是每個輸出影格所允許的最大顏色數:從預設的 256 降到 128 或 64,顏色表與像素索引串流往往會變得更精簡。有時候這樣的壓縮確實能省下位元組;有時候新的調色盤配置壓縮效率反而比原本更差,檔案變大,而誠實的答案就是保留原檔。一個瀏覽器端的 GIF Optimizer,使用自選的調色盤上限重新編碼動畫,並顯示實際的前後位元組數,是測試調色盤縮減是否真的對你的特定檔案有幫助的最安全方式。
實際上決定 GIF 檔案大小的因素
磁碟上的位元組主要由三個變數主導。第一個是畫布尺寸,因為每個可見影格都鋪設在一個固定的像素網格上,解碼器必須將其保留在記憶體中,而編碼器則必須對其建立索引。第二個是影格數量,因為每增加一個可見影格,就多了一組像素索引串流、一個延遲標記,以及一個完整畫布或一小塊局部修補。第三個是每影格的調色盤表,它列出該影格像素可用的顏色。GIF 把這個表的上限設為 256 個項目,但工具也可以強制使用更小的上限,例如 128 或 64 色,並在該限制下重新編碼每個影格。動畫時序、透明像素和影格處理方式會影響每個影格如何疊加在前一個影格之上,但它們本身並不會直接影響位元組;它們影響的是這三個核心變數如何被一起打包。
由於這三個變數都由原始內容決定,縮小 GIF 唯一通用的方法就是減少其中之一。縮小畫布意味著調整 GIF 大小,這是與調色盤最佳化不同的操作。減少影格數意味著修剪、減速或捨棄影格,這也是另一種不同的操作。縮小調色盤意味著將每個影格重新量化為一組更少的顏色,並在該上限下重新編碼像素索引,這正是專注於調色盤的 GIF Optimizer 所設計來執行的工作。
為什麼調色盤縮減反而可能讓 GIF 變大而非變小
許多人期待任何「壓縮」按鈕都能讓檔案變小,但這種預期與 GIF 格式的特性不符。較低的調色盤上限可以簡化顏色表並縮短像素索引串流,但接下來的 LZW 壓縮效果取決於這些索引中重複的模式。如果原始檔案使用了針對其特定顏色調整的寬廣調色盤,新的受限調色盤可能會產生壓縮效率較差的索引模式。即使畫面中的相異顏色變少了,結果仍可能是檔案變大。任何用「省下 30%」之類標籤來隱藏這種結果的調色盤最佳化工具,都是在對磁碟上的位元組數據說謊。
正確的工作流程應該把調色盤縮減視為一場實驗,而不是必然的保證。誠實的工具會接受自選的調色盤大小,在該上限下重新編碼完整可見動畫,顯示實際的原始與輸出位元組數,並且只有在取捨可接受時才讓使用者下載結果。這正是瀏覽器端 GIF Optimizer 所實作的行為:它從不聲稱能省下多少,只顯示真實的差異,並在新檔案更差時讓你保留原檔。
如何在瀏覽器中最佳化 GIF 檔案大小
這就是這個關鍵字所描述的直接任務:拿著你已有的動態 GIF,在不離開當前瀏覽器分頁的情況下產生一個更小的版本。
- 在瀏覽器中開啟 GIF Optimizer 頁面,點擊檔案選擇器。從你的本機裝置選擇你想縮小的動態 GIF。
- 從可用選項中選擇調色盤大小:256 色、128 色或 64 色。每個選項都會在該最大顏色數下重新編碼可見影格。
- 點擊 Optimize GIF 開始本機重新編碼。瀏覽器會解碼動畫,將每個局部修補合成為完整的可見畫布,將每個輸出影格量化為所選的調色盤上限,然後重建新的 GIF 串流。
- 讀取預覽旁顯示的原始大小與新的輸出大小。頁面以位元組顯示這兩個數字,讓你可以直接比較。
- 觀看重新編碼後動畫的完整循環。確認影格順序、每影格延遲與透明度在目標大小下看起來仍然正確。
- 如果取捨可以接受,點擊下載按鈕,將新的 GIF 儲存到你的裝置。如果新檔案變大或品質下降,則改為保留原檔。
由於每個步驟都在當前分頁中執行,GIF 永遠不會被上傳到伺服器、排入雲端工作佇列,或儲存到任何帳號中。下載的檔案是由重新編碼後的串流所構成的標準 Blob。
為你的素材選擇 256、128 或 64 色
這三個調色盤選項是輸出控制項,而不是關於原始檔案包含多少顏色的陳述。256 色上限保留了完整的 GIF 範圍,當保留色彩細節比積極縮減更重要時,這是正確的選擇——漸層、照片、細小文字與平滑的陰影在 256 色下都能完整保留。128 色上限是大多數插圖、UI 動畫與具有中等色彩多樣性的螢幕錄影的合理起點,因為它將調色盤減半,同時仍為膚色、品牌色與反鋸齒邊緣的乾淨來回保留空間。64 色上限則是針對簡單繪圖、平面圖像、線稿,或任何可以接受可見簡化以換取更小調色盤所帶來之位元組節省的明確實驗。
| 調色盤上限 | 最適合 | 可預期的取捨 |
|---|---|---|
| 256 色 | 照片、漸層、平滑陰影、細小反鋸齒文字 | 保留細節,但很少能讓檔案明顯縮小 |
| 128 色 | 插圖、UI 動畫、螢幕錄影、中等色彩多樣性 | 對大多數素材是合理的平衡;良好的初次嘗試 |
| 64 色 | 平面圖像、線稿、簡單繪圖、刻意的簡化 | 可見的色階現象與抖動差異;不一定能省下位元組 |
一個實用的工作流程是從 128 開始,下載結果,將新檔案放在原檔旁邊進行一個完整循環的並列比較。如果顏色可以接受且新的位元組數較小,你就完成了。如果顏色可以接受但新檔案更大,代表素材原本就已調整得當,原檔就是正確的輸出。只有在視覺結果在其實際顯示尺寸下仍然成立時,才嘗試 64 色;如果色階或透明邊緣破壞了外觀,請退回 128 色,或為目的地使用其他格式。
編碼前 Optimizer 強制執行的限制
瀏覽器在重新編碼開始前會套用嚴格的限制,因為壓縮動畫在記憶體中可能膨脹為遠大於其檔案大小的量。頁面會以明確的錯誤訊息拒絕超出這些範圍的輸入,絕不會產生部分或過期的下載來取代。
| 限制 | 數值 |
|---|---|
| 輸入檔案大小 | 上限 20 MB |
| 畫布尺寸 | 任一邊不得超過 4,096 像素 |
| 每影格解碼後像素數 | 不得超過 3,000,000 |
| 影像影格數 | 不得超過 50 |
| 處理位置 | 僅限當前瀏覽器分頁 |
如果你的素材大於 20 MB、超過 50 個影格,或超出畫布與像素預算,Optimizer 將會以錯誤訊息停止,而不會猜測。在這種情況下,實際的變通方法是先修剪影格或調整 GIF 大小,兩者都是由專用工具處理的獨立作業。Optimizer 的輸出結果是一個新的 GIF 串流:它保留了已解碼的可見影格順序與每影格延遲,但不會沿用素材來源的調色盤表、註解區塊、應用程式擴充、位元組層級的最佳化方法,或有限的循環次數。輸出設定為連續循環,這對於重新發布的動畫是正確的預設值。
何時其他改動會比調色盤縮減更有效
調色盤縮減只是一個手段,不是萬靈丹。如果你的 GIF 尺寸已經很小,且已使用調色盤最佳化儲存,那麼另一種改動更可能縮小位元組數。將畫布縮小到實際顯示尺寸,通常比任何調色盤上限省下更多,因為編碼後的像素數會隨面積線性下降。修剪多餘的影格、放慢動畫,或移除幾乎重複的影格,則會直接移除整串像素資料,而不是對它們重新量化。若目的地接受現代格式,轉換為影片容器或動態 WebP 的壓縮效果可能比任何受限於調色盤的 GIF 都更積極。
如果僅靠調色盤縮減還不夠,合理的下一步是在瀏覽器中將 GIF 縮小,然後在較小的畫布上重新執行調色盤最佳化。這樣的組合會同時針對兩個最大的位元組驅動因素。社群平台、通訊應用程式與 CMS 系統也會在自身端對上傳的內容重新編碼,因此最終發布的素材可能比你在本機下載的更大或更小;請務必測試實際發布的內容,而不是本機檔案。對於動畫中的靜態影格,將個別的 PNG 匯出並用另一個 GIF 製作工具重新組合,有時比讓單一 GIF 檔案承擔所有工作更有效率。
如果你正在權衡各種選項,如何在不破壞動畫的情況下調整 GIF 檔案大小對此有詳細說明。