影片壓縮軟體怎麼選？網頁背景影片的體積、格式與尺寸實戰指南

一、為什麼背景影片是網頁效能的頭號兇手

先講一個大部分人沒意識到的差別：圖片有地方躲，主視覺影片沒有。

網頁上的圖片可以用延遲載入（lazy loading），使用者沒滑到那個位置，圖片就不下載。這招很有效，也是這幾年網頁優化的基本功。

但滿版背景影片不一樣。它就在第一屏，是使用者打開網站看到的第一個東西，你沒有任何拖延的空間。使用者的網路頻寬在那短短幾秒鐘裡，全部被這支影片吃掉——而同一時間，你的 CSS、字型、logo、選單都在排隊等著載入。

LCP：Google 正在盯著你的主視覺

Google 的網站體驗核心指標裡，有一項叫 Largest Contentful Paint（最大內容繪製，簡稱 LCP），量的是「頁面上最大的那個內容元素，花多久時間顯示出來」。

滿版影片幾乎必定就是那個最大元素。所以影片載入的速度，直接等於你的 LCP 分數，而 LCP 是搜尋排名的訊號之一。

換句話說，一支沒壓好的背景影片，同時傷害三件事：使用者體驗、跳出率、還有 SEO。三殺。

桌機看不出問題，手機才是照妖鏡

這是最容易騙過自己的地方。我們做網頁設計的人，工作環境幾乎都是光纖加大螢幕，20MB 的影片在辦公室裡跑起來毫無異狀。

但你的客戶可能在工地、在展場、在客戶的工廠門口用手機開網站。4G 訊號不穩的環境下，20MB 要下載十幾二十秒，而根據普遍的使用者行為研究，超過三秒沒東西出現，大部分人就走了。

一組真實數據，以及它的侷限

這篇文章的案例是成均五金（jichn.com），一家在桃園做切削刀具的公司，首頁用的就是滿版背景影片。我們在 2026 年 7 月跑了一次 PageSpeed Insights，行動裝置的結果如下：

這裡我必須誠實說明兩件事，因為我不想給你一個過度美化的印象。

第一，上半部的核心指標是「網域層級」的數據，不是首頁單獨的成績。 Chrome 使用者體驗報告在單一網址樣本不足時，會退回整個網域的平均值。而這個站有幾百篇文章頁，那些頁面沒有影片、載入很快，會把平均拉得好看。

第二，實驗室分數只有 60 分。 這是在模擬慢速 4G、低階手機的嚴苛條件下跑出來的，代表確實還有優化空間。而且說實話，這 40 分的扣分裡，影片可能不是最大的兇手——TTFB 0.7 秒對台灣主機來說偏慢，那是伺服器端的問題，跟影片無關。

我把不好看的數字也放上來，是因為這篇文章想講的是真實流程，不是行銷素材。壓縮影片能解決的問題有限，把它當萬靈丹反而會忽略真正的瓶頸。

二、壓縮之前，先做四個判斷

大部分教學一開頭就叫你下載某個影片壓縮軟體，這是本末倒置。動手壓之前，先問自己四個問題，可能會發現根本不用壓。

判斷一：這支影片真的需要存在嗎？

這聽起來像廢話，但我看過太多網站的背景影片，內容是無關痛癢的空拍雲海或抽象光影，跟公司業務完全沒關係，純粹因為「別人都有」所以放一個。

這種影片的溝通價值接近零，卻要付出實實在在的效能成本。與其如此，不如放一張精修過的靜態圖，配上輕量的 CSS 動畫，視覺效果不見得比較差，載入速度天差地遠。

反過來說，成均五金那支影片拍的是實際加工現場——刀具在切削、鐵屑飛出來的畫面。那是說服力，是靜態圖做不到的事。這種影片就值得留，也值得花時間好好壓。

判斷二：手機版要不要一起放？

手機螢幕小，滿版影片還會被標題文字和按鈕蓋掉一大半，實際看得到的畫面可能只剩三成。但下載成本跟桌機一模一樣。

視覺效益低、成本一樣高，這筆帳很難算得過去。比較務實的作法是手機版直接換成靜態圖，後面第七節會講怎麼做。

判斷三：幾秒才夠？

背景影片是循環播放的，沒有人會盯著它看完整段。六到十秒能無縫接回開頭，就已經非常足夠。

我看過有人把三十秒的形象影片直接拿來當背景，體積是必要長度的四倍，而九成的訪客根本不會看到第十秒。

判斷四：音軌還留在裡面嗎？

這是最常被忽略、也最容易解決的一項。背景影片一定是靜音自動播放的——瀏覽器本來就不允許有聲音的影片自動播放。既然如此，音軌就是純粹的死重量。

成均那支影片我們用 MediaInfo 檢查過，容器裡只有一條視訊串流，沒有音訊。這點當初有做對。一段立體聲音軌動輒佔掉幾百 KB，對一個只有 1.6MB 的檔案來說，那是很大的比例。

三、壓縮的三個槓桿，效果差很多

如果這篇文章你只讀一段，讀這段。

一般人聽到「要把影片檔案變小」，直覺反應是「那把影片改小一點」——把 1080p 降成 720p，或是把畫面裁窄一點。這個直覺對了一半，但選錯了最有效的工具。

影片體積主要由三個東西決定，效果差距非常大：

為什麼位元率是最有效的那一根槓桿

位元率（bitrate）是每秒鐘分配給影像的資料量。同樣一支 1080p 影片，用 20 Mbps 壓跟用 2 Mbps 壓，尺寸完全一樣，體積差十倍。

關鍵在於：背景影片對畫質的要求本來就比較低。 它上面通常蓋著標題、按鈕、半透明遮罩，觀眾不會盯著細節看，而且它在動——動態畫面本來就比靜態畫面更容易掩蓋壓縮痕跡。

這代表你可以把位元率壓得比正常影片狠得多，而觀眾察覺不到。

成均案例：尺寸沒動，體積掉九成

回到那支七秒的影片。原始 MP4 母帶 20MB，換算下來平均位元率大約 22.9 Mbps——這是準備給電視播放或高畫質下載用的規格，拿來當網頁背景是徹底的浪費。

當時我們的處理是：解析度維持 1920×1080 不動、長度維持七秒不動、音軌移除、位元率大幅壓低。結果是 1.77MB。

畫面沒有變小、時間沒有變短、肉眼幾乎看不出畫質差異，體積少了九成。這就是為什麼我說位元率是第一根該拉的槓桿。

換算成人話：每一位訪客省下 18.23MB 的下載量。以這個站的流量規模，一個月大概能省下五十幾 GB 的頻寬，還沒算重複造訪的次數。

四、格式怎麼選：MP4、WebM 與 AV1

選對編碼格式，等於免費得到一次壓縮率的提升——同樣的畫質，體積更小，你什麼都不用犧牲。理論上是這樣。實際上，我們踩到了一個坑，等一下會講。

三代編碼器的差別

我們原本以為會省更多，結果沒有

兩年後我們回頭檢查那支 WebM，用 MediaInfo 一看，編碼器寫著「Google/On2's VP8 Video (VP80)」——當初用的是 VP8，不是 VP9。

看到這個我很興奮，因為按照普遍的說法，VP9 在同畫質下能比 VP8 再省三成到五成。我當下的預估是重壓之後應該會落在 1.0 到 1.2MB。

實際重壓出來是 1.6MB。

只省了不到一成。我預估錯了，而且錯得不算少。

為什麼理論值沒有兌現

後來想了想，原因大概有三個，這些是那種只有實際跑過才會知道的事：

第一，第一次已經壓得很兇了。 「VP9 比 VP8 省三成」這個數字，通常是在中高位元率區間測出來的。我們當初已經把 1080p 壓到 2.0 Mbps，這個位元率對 1080p 來說本來就相當激進，接近這支素材的極限。榨過一輪的東西，第二輪能榨出來的自然有限。

第二，影片只有七秒。 每個檔案都有固定開銷——容器標頭、關鍵影格、索引資訊。在一支三分鐘的影片裡，這些開銷佔比微不足道；在一支七秒、只有 1.6MB 的檔案裡，比例就顯著多了。

第三，素材本身的特性。 這支影片拍的是加工過程，鏡頭運動不大、畫面內容相對穩定。編碼器最擅長處理的就是這種畫面，VP8 在這種素材上已經表現得不錯，VP9 的優勢就沒那麼容易展現出來。

我把這段寫出來，是因為網路上關於影片壓縮軟體的教學，幾乎都只會告訴你「換 VP9 可以省三成」，然後就沒有下文了。實際做過你才會知道，那個數字要看素材、看你原本壓到什麼程度、看影片多長。

那還要不要換 VP9？我的答案是要，但別抱太大期待。省 9.6% 也是省，而且新編碼在低位元率下的細節保留通常更好，畫質是有加分的。只是不要以為換個編碼器就能有戲劇性的改變。

順便修掉一個沒人注意的問題：色彩空間

檢查那支 WebM 的時候，我還看到一行「色彩空間：ITU-R BT.601 範圍」。

BT.601 是標準畫質時代（480i / 576i）的色彩標準，1080p 的正規標準應該是 BT.709。標錯的後果是有些瀏覽器會照著標籤去解讀色彩矩陣，畫面可能會偏灰、飽和度不太對，或是紅色偏橘。

差異不至於誇張，但如果影片裡有品牌識別色，或是像成均這種要呈現金屬光澤的畫面，客戶很可能會覺得「怎麼跟我在剪輯軟體裡看的不一樣」。這通常是壓縮工具沒有明確指定色彩參數時的預設行為，重壓時加上正確標記就能解決。

另外還有一個小知識：MediaInfo 上會顯示「緩衝維度 1920×1088」，多出八個像素。這不是錯誤——視訊編碼以 16×16 的巨集區塊為單位處理，1080 除以 16 除不盡，編碼器會自動補到 1088，播放時再裁回來。看到不用緊張。

五、影片壓縮軟體比較與實測

講完原理，終於可以講工具。市面上的影片壓縮軟體大致分四類，各有各的適用場景。

HandBrake：如果你只想裝一套

免費、開源、跨平台，介面直覺，內建一堆預設組合。對大部分人來說，這就是答案。缺點是它對 WebM 的支援沒有 MP4 那麼完整，如果你要走 VP9 路線，設定選項會比較侷限。

FFmpeg：醜但無敵

沒有介面，全部靠打指令，第一次用會很挫折。但它能做到的事情，沒有任何圖形介面工具比得上——精確控制每一個參數、一行指令批次處理整個資料夾、想改什麼就改什麼。

成均那支影片的重壓就是用 FFmpeg 跑的，指令長這樣：

ffmpeg -i 652d4bd2d1385.mp4 -c:v libvpx-vp9 -crf 33 -b:v 0 \ -row-mt 1 -an \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ output_vp9.webm

逐段解釋，這樣你可以自己改：

• -c:v libvpx-vp9：指定用 VP9 編碼
• -crf 33：品質控制，數字越小越清晰、檔案越大。背景影片建議抓 30 到 36 之間，因為上面通常蓋著文字，觀眾不會細看
• -b:v 0：把位元率的決定權完全交給 CRF
• -row-mt 1：開啟多執行緒，壓縮速度差很多
• -an：移除音軌
• 最後三個 bt709：修正前面提到的色彩空間標記問題

如果不確定 CRF 要設多少，就用不同數值各跑一次，然後把檔案並排比對。這比查表可靠得多，因為每支素材的最佳值都不一樣。

線上工具：方便，但有一件事要注意

拖進瀏覽器就能壓，不用安裝，對偶爾處理一支影片的人來說很夠用。

但如果你是接案的、或是在公司裡處理客戶素材，這裡有個必須考慮的問題：你把客戶的影片上傳到一個你不知道底細的伺服器了。

產品發表前的宣傳片、還沒公開的工廠內部畫面、客戶指名保密的素材——這些東西丟上不明來源的線上服務，是實實在在的風險。很多這類網站的隱私條款寫得很模糊，檔案在他們伺服器上留多久、有沒有人看過，你無從查證。

商業專案我的建議是一律用本機工具處理。多花五分鐘裝軟體，換掉一個不知道什麼時候會爆的風險，很划算。

順便推薦一個檢查工具

MediaInfo，免費，把影片檔拖進去就會列出編碼器、位元率、解析度、色彩空間、有沒有音軌。這篇文章裡關於 VP8 和 BT.601 的發現，全部來自這個工具。壓縮完檢查一下，能避免很多「以為壓好了其實沒有」的狀況。

六、成均五金完整實測：從 20MB 到 1.6MB

把前面散落的資訊串成完整的過程。

專案背景

成均五金是桃園平鎮的切削刀具供應商，主要客群是製造業採購和工廠技術主管，屬於典型的 B2B 網站。首頁需要一支能傳達「我們懂加工」的畫面，所以拍了實際的切削過程——刀具高速旋轉、鐵屑飛濺，那種畫面用照片拍不出來。

當初的決策與理由

兩年後回頭檢查，發現三件事

一、編碼器用的是 VP8，不是 VP9。 重壓成 VP9 之後是 1.6MB，比原本省 9.6%。省得比預期少很多，原因前面第四節分析過了。

二、色彩空間標成 BT.601，應該是 BT.709。 重壓時一併修正。

三、沒有 MP4 備援，也沒有 poster 圖。 這是三個問題裡最嚴重的一個。

第三點值得展開講。原始碼裡只掛了一個 WebM 來源，fallback 只有一行文字「Your browser does not support HTML5 video」。

WebM 的壓縮效率確實好，這個選擇沒錯。但 Safari 要到相對晚期的版本才對 WebM 有完整支援，而成均的客群是製造業——工廠端的主管使用舊 iPad 或舊 iPhone 的比例不低。這些人打開網站，主視覺區域可能就是一片空白，什麼都沒有。

更麻煩的是，因為沒有 poster 圖，連個備援畫面都沒有。這不只是相容性問題，也是效能問題：影片載入完成前，LCP 元素會落到其他東西上，或者根本沒有東西可以量。

總結這個案例的三個數字

如果要用三個數字概括：體積減少 92%、解析度完全沒有犧牲、每位訪客省下 18.4MB 下載量。

而最關鍵的一個認知是：這 92% 裡面，有 91.2% 是第一次壓縮達成的，換編碼器只貢獻了剩下的 0.8 個百分點。把位元率調對，遠比追逐最新的編碼格式重要。

七、壓縮之外，還有三件事沒做完

很多人壓完影片就收工了，但其實還有一半沒做。這三件事跟壓縮同等重要，而且做起來都不難。

一、poster 圖：影片還沒來之前的替身

poster 屬性指定一張圖，在影片載入完成之前先顯示。它解決兩個問題：使用者不會看到空白區塊，而且瀏覽器有東西可以當作 LCP 元素。

這張圖從影片裡截一格就好，壓到 30KB 以內。挑選時記得選一格構圖完整的畫面，因為它會是很多人看到的第一眼。

二、MP4 備援：照顧那些用舊裝置的人

雙來源的寫法，瀏覽器會自己挑第一個能播的：

<video autoplay muted loop playsinline poster="hero-poster.jpg" preload="metadata"> <source src="hero.webm" type="video/webm"> <source src="hero.mp4" type="video/mp4"> </video>

幾個屬性的作用：

• muted：靜音，不加的話 iOS 和多數瀏覽器不會自動播放
• playsinline：讓 iOS 在頁面內播放，不要跳成全螢幕
• preload="metadata"：先只載入基本資訊，不要一開始就下載整支影片
• loop：循環播放

MP4 那支不用壓得太小，它是備援，走到那一步的使用者本來就是少數。

三、行動版降級：手機直接換靜態圖

最有效的優化，是讓手機根本不下載影片。用 JavaScript 判斷視窗寬度，只在桌機才把 source 塞進去；或者更簡單，用 CSS 在手機隱藏影片、顯示背景圖。

要注意的是：光用 display: none 隱藏是沒用的，瀏覽器還是會下載。必須從 DOM 層面控制，或是一開始就不要輸出那個 <video> 標籤。

這一節提到的三件事，嚴格說已經超出「壓縮」的範疇，進到網頁設計與前端實作的領域了。但這正是我想強調的：影片優化從來不是單獨一個環節的事，剪輯、壓縮、前端、伺服器設定要一起看，只顧其中一段，效果會被其他環節吃掉。

八、五個最常見的錯誤

這幾年幫客戶處理網站影片，重複看到的問題大概就這幾個。

錯誤一：壓一次就當作永久解

成均那支影片是 2023 年壓的，兩年後才發現用的是舊編碼器、色彩標記也標錯了。編碼技術一直在進步，瀏覽器支援度也一直在變，兩年前的最佳解今天可能只是及格。建議每年至少檢查一次。

錯誤二：把客戶的機密影片丟上線上工具

前面講過，這裡再強調一次。方便跟風險要一起算。

錯誤三：忘了拿掉音軌

背景影片必定靜音，音軌純屬浪費。而且很多人壓完根本不知道音軌還在，因為聽不到。用 MediaInfo 檢查一下就知道了。

錯誤四：影片上傳到 CMS 之後就再也沒人管

網站交付之後，影片檔就靜靜躺在伺服器上，沒有人會主動想到它。等到客戶抱怨網站慢，才發現問題在那裡放了兩年。

錯誤五：只在自己的電腦上測速

辦公室光纖、高階筆電、Chrome 開發者工具——這三個條件加起來，你永遠測不出真實使用者的痛苦。至少要用 PageSpeed Insights 跑一次行動裝置模擬，最好是拿自己的手機關掉 Wi-Fi 實際開一次看看。

九、常見問題

壓縮影片一定會失真嗎？

技術上是的，這些都是破壞性壓縮。但「失真」跟「看得出來失真」是兩回事。背景影片在畫面上有文字遮蔽、又是動態的，壓縮痕跡很難被察覺。成均那支從 20MB 壓到 1.77MB，我們在 27 吋螢幕上並排比對，看不出明顯差異。

網頁背景影片壓到幾 MB 才算合格？

沒有絕對標準，但可以參考這個級距：2MB 以內算優秀，2 到 5MB 算可以接受，超過 5MB 就該重新檢討。如果超過 10MB，那基本上是在懲罰你的訪客。

CRF 該設多少？

VP9 的 CRF 建議範圍是 30 到 36。從 33 開始試，覺得糊就往下調，覺得檔案太大就往上調。每支素材的甜蜜點都不一樣，實測比查表準。

可以直接嵌入 YouTube 影片當背景嗎？

技術上可以，而且省下你的頻寬。但代價是：要載入 YouTube 的播放器程式碼（那不小）、會有第三方 cookie 和隱私問題、控制權在別人手上、而且很難做到真正乾淨的滿版無 UI 效果。做正式的商業網站，我還是建議自己託管。

用 GIF 代替影片可以嗎？

千萬不要。GIF 的壓縮效率極差，同樣的畫面用 GIF 存可能比 WebM 大上十倍甚至更多，而且色彩只有 256 色。如果你需要的是無聲循環動畫，靜音的 WebM 或 MP4 在每一個面向都完勝 GIF。

影片壓縮軟體要選付費的嗎？

以網頁背景影片這個需求來說，完全不需要。HandBrake 和 FFmpeg 都是免費開源，而且是這個領域公認最好用的工具，付費軟體在這件事上給不了你更多。

十、回到那支七秒的影片

寫這篇文章的過程中，我一直在想那通抱怨電話。

當時我們的反應是趕快把影片壓小，壓完 1.77MB，覺得任務完成，然後就把這件事忘了兩年。直到最近整理案例才發現：用的是 2010 年的編碼器、色彩空間標錯、沒有 MP4 備援、沒有 poster 圖。

更打臉的是，我原本很有把握地預估換 VP9 能壓到 1.0 到 1.2MB，結果實測 1.6MB。理論值跟現實之間，隔著素材特性、影片長度、以及你第一次已經壓到什麼程度。

這件事給我的體會是，效能優化沒有「做完」這個狀態。你當年做的每一個決定，都是基於當時的技術條件和判斷。兩年後標準變了、瀏覽器變了、你自己的知識也變了，回頭看一定會發現東西。這不是當初做錯，是這個領域本來就會這樣。

所以如果你正在找影片壓縮軟體，我的建議不是「找到最強的那一套」，而是：先把位元率調對，其他的慢慢來。把 20MB 壓到 2MB 這一步，用免費工具十分鐘就能完成，而且它貢獻了整趟優化 99% 的效益。至於換編碼器、修色彩空間、加備援來源——那些是錦上添花，值得做，但別讓它們變成你遲遲不開始的藉口。

最後一件事：壓完記得回去用手機、關掉 Wi-Fi，實際開一次你的網站。那三秒鐘的等待感受，比任何工具跑出來的分數都真實。