前言:Chrome 看正常,Safari 卻壞掉——這種事為什麼一直發生?
台灣老闆常遇到的場景是這樣的:花了一筆預算做好網站,自己用手機看、用電腦看都順,結果某天客戶傳訊息來說「網站壞了」,打開來一看——Safari 上排版整個崩掉。這個狀況在業界極為常見,事後工程團隊要花大量時間逐一修補。背後成因是「瀏覽器碎片化」這個結構性問題,不是單一設計師或工程師的疏失。
由 Mozilla、Apple、Google、Microsoft、Igalia 等瀏覽器引擎供應商共同推動的 Interop 計畫,目標就是處理這個結構性問題。以下整理這個產業級計畫的真實狀態,以及它對台灣業主挑選網頁設計公司的實質影響。
什麼是 Interop?瀏覽器廠商聯手做的相容性大會考
Interop 是由瀏覽器引擎供應商共同發起的跨瀏覽器相容性改進計畫。根據 Mozilla Hacks 官方公告,這個團隊會做這些事:
- 收集業界已穩定的 Web 標準提案
- 透過開發者調查與 bug 回報決定優先順序
- 在 Web Platform Tests 覆蓋率足夠後,共同承諾在一年內把這些功能的瀏覽器實作拉齊
- 用統一的測試套件當作「進步指標」
白話一點講:這就像瀏覽器廠商每年開一次聯合大會考,先協議好今年大家都要把哪些功能補齊、不能再各做各的。對網頁設計公司與業主來說,代表「以前某個功能只 Chrome 支援,現在 Safari、Firefox 也開始跟上」的進度會更可預期。
為什麼不同瀏覽器會跑出不同結果?
要理解 Interop 為什麼重要,得先理解瀏覽器碎片化的成因。
瀏覽器碎片化源自幾個結構性原因:Web 標準持續演進(每年都有新提案進到 CSS、HTML、JavaScript API),各引擎實作進度不一(Blink 用於 Chrome、WebKit 用於 Safari、Gecko 用於 Firefox),行動裝置作業系統又有額外限制(iOS Safari 強制使用 WebKit 核心,業主完全沒得選)。
三個因素疊加,任何一個新網頁技術理論上都會經歷一段「只有部分瀏覽器支援」的時期。業界常見的踩雷經驗是:某個動畫效果在手機 Safari 上變成靜止、某個 CSS 排版只在 Chrome 渲染、某個表單元件在 Edge 上長得完全不一樣。
這不是單一公司的疏失,而是整個產業在標準化過程中必須承受的過渡成本。Interop 計畫的目的,就是把這個過渡時間壓到最短。
Interop 對台灣業主的實質意義
對不是工程師的業主來說,跨瀏覽器相容性往往是被忽略、直到出問題才會發現的環節。Interop 計畫的進展,會直接影響以下三件事:
1. 設計新穎性與相容性的取捨壓力降低
過去兩年業界常見的取捨是:「要做某個酷炫的滾動動畫,但 Safari 還不支援」。隨著 Interop 把這些功能列為共同改善目標,取捨壓力會逐年降低。但這不意味現在就能隨意用所有新功能,還是要看 Interop 該期是否把該功能列入改善清單。
2. 維護成本的可預期性提高
跨瀏覽器修補是網站上線後最常見的隱性維護成本。Interop 改善意味著未來修補的頻率會下降,長期維護合約的工時消耗會更可預期。
3. 技術選型的「未來性」更值得信賴
當瀏覽器廠商共同承諾把某個標準拉到所有引擎都能跑,代表這個技術不是曇花一現的炫技,而是網頁設計產業的長期可投資技術。業主在評估設計公司提出的技術方案時,可以把「是否在 Interop 改善清單內」當作一個判斷指標。
網頁設計公司怎麼處理跨瀏覽器問題
回到業主最關心的問題:怎麼判斷一家網頁設計公司有沒有能力處理跨瀏覽器?以下是業界常用的三個判斷切入點。
看開發流程有沒有正式測試矩陣
業界常見做法是定義一個瀏覽器 + 作業系統 + 裝置的測試矩陣,並在 CI/CD 流程中自動跑跨瀏覽器回歸測試。如果問設計公司「你們怎麼確保每個瀏覽器都正常」,得到的是具體的測試清單與流程,而不是「我們會在 Windows、Mac 開看看」這種模糊回答,代表該團隊對相容性議題有結構化處理能力。
看 CSS 新功能的使用策略
業界目前對新 CSS 功能的常見策略是「優先採用標準化路徑、有計畫地降級支援」,而非全面擁抱或全面排斥。如果看到設計公司在做形象網站時,把 CSS Container Queries、CSS :has() 選擇器、@function 等新功能當作主軸,但都有對應的 fallback,代表他們對標準化進度有掌握。
看有沒有自動化視覺回歸測試
跨瀏覽器議題不只是「能不能跑」,還包含「看起來一不一樣」。業界正規做法會引入 Playwright、Cypress 等工具做跨瀏覽器視覺回歸測試,確保每個版本在每個瀏覽器都長一樣。詢問設計公司是否有這類工具納入流程,是一個較深的技術指標。
台灣業主最容易踩的跨瀏覽器地雷
從實務上觀察,台灣業主網站最常見的跨瀏覽器問題有以下幾類。這些問題發生的當下,業主往往只能看到結果(壞掉),看不太到原因:
- iOS Safari 的 100vh 問題:手機瀏覽器網址列會縮放,造成 100vh 計算不正確,滿版設計常跑版
- Safari 的 CSS Grid 與 flexbox 渲染差異:某些 grid 排版在 Safari 上會出現意料外的間距
- 字型在不同瀏覽器的行高計算差異:同樣的字型大小設定,在 Chrome、Safari、Firefox 上高度可能略有不同
- JavaScript API 的瀏覽器版本限制:某些較新 API 在舊版瀏覽器直接報錯,需要 polyfill 或降級
這些問題的共同點是:不是設計師不會做,而是必須在不同瀏覽器實機驗證過才能發現。這也是為什麼「設計公司有沒有跨瀏覽器測試流程」這個問題會如此關鍵。
挑選網頁設計公司時,跨瀏覽器能力的提問清單
如果你正在評估一家網頁設計公司,以下問題可以直接拿來問,從回答判斷該公司對跨瀏覽器議題的掌握度:
- 你們的網站上線前會在哪些瀏覽器與裝置做實機驗證?有沒有書面清單?
- 遇到 Safari 跑版時,你們的標準處理流程是什麼?是 hack 修補還是改用標準寫法?
- 對於較新的 CSS 功能(如 :has()、Container Queries、@function),你們如何決定是否採用?
- 維護合約中,跨瀏覽器修補是否獨立列項?頻率預期為何?
- 你們怎麼跟上 W3C、Interop 等標準化進度?有沒有固定的資訊來源?
這五題沒有標準答案,但好的設計公司會給出具體且可驗證的回答,而不是模糊的「我們會處理」。
跨瀏覽器相容性跟 SEO 有什麼關係?
跨瀏覽器議題不只是 UI 問題,還會影響 SEO。Google 官方文件明確表示,Mobile-Friendly Indexing 會以 Googlebot 看到的版本為主,而 Googlebot 使用較新版本的 Chromium。這代表:
- 如果你的網站只能在 Chrome 正常顯示,在其他瀏覽器崩潰,代表你的受眾範圍被縮限
- 跨瀏覽器跑版的網站,用戶停留時間、跳出率、轉換率會受到影響,連帶被搜尋引擎視為品質訊號
- 結構化資料在不同瀏覽器的呈現方式不同,若沒實機驗證,可能影響 rich result 顯示
這條因果鏈從「跨瀏覽器相容性」一路串到「SEO 排名」,因此在做網站設計時,這不是「加分題」而是「基本題」。
業界目前的常見做法:漸進增強與優雅降級
業界目前處理跨瀏覽器的兩大主流策略是漸進增強(Progressive Enhancement)與優雅降級(Graceful Degradation)。兩者精神一致:先確保基本功能在所有瀏覽器都能用,再為較新瀏覽器加強體驗。
具體實作上常見的做法包括:
- 使用
@supports條件 CSS 判斷瀏覽器是否支援某功能 - 對 JavaScript 新 API 使用 feature detection,而非瀏覽器版本判斷
- 對圖片格式(AVIF、WebP、JPEG)提供 fallback
- 對字型載入做 FOIT/FOUT 控制
這些都是「同一套程式碼,在不同瀏覽器跑出不同結果」的務實工程做法,不是炫技,而是基本功。
鍛碼匠怎麼看這件事
鍛碼匠數位創意(fordige.com)是 2025 年底成立、位於台中的網頁設計公司,由資料科學家與資深工程師組成。我們在規劃網站時,跨瀏覽器相容性不是上線前的最後一道關卡,而是從技術選型階段就納入的決策因子。
實務上我們的做法是:每一份視覺設計稿定稿前,會先用業界常用的瀏覽器相容性資料庫(Can I Use)查驗每個用到的 CSS 功能支援度;開發流程中用 Playwright 跑跨瀏覽器視覺回歸;維護合約裡跨瀏覽器修補獨立列項,頻率以實機驗證為主。
對台灣業主來說,跨瀏覽器議題常常被低估,直到上線後才顯現為客服成本或轉換率下滑。把這條線在專案啟動時就拉清楚,比事後救火更具成本效益。
