網頁設計:跨瀏覽器相容性測試 Chrome、Safari、Firefox、Edge 完整指南

網站在 Chrome 看起來正常,不代表 Safari、Firefox、Edge 一定沒問題。
現代的跨瀏覽器相容性已經不是以前針對 IE6、IE7、IE8 寫一堆 CSS Hack,
而是從「支援哪些瀏覽器」開始,逐步檢查 HTML、CSS、JavaScript、RWD、
表單、字型、圖片與實際裝置操作。
FRONT-END / CROSS-BROWSER TESTING

網站跨瀏覽器相容性怎麼做?Chrome、Safari、Firefox、Edge 前端測試重點

網頁設計:跨瀏覽器相容性測試 Chrome、Safari、Firefox、Edge 完整指南

Chrome / Edge Chromium 系列仍要跑正式版關鍵流程
Safari 不能只用 Chrome 模擬,需驗證 WebKit / 真機
Firefox 獨立 Gecko 引擎,適合抓出 Chromium 沒出現的問題
最後更新:2026 年 8 月

做網站十幾年前最麻煩的事情之一,是同一段 CSS 在 IE6、IE7、IE8、
Firefox 看起來都不一樣。
當時常見的做法是瀏覽器專用 CSS、 Conditional Comments,甚至針對不同版本寫 Hack。

現在情況已經好很多。瀏覽器廠商持續透過 Web Platform Tests 與
Interop 計畫改善 HTML、CSS、JavaScript 與 Web API 的一致性,
但「各瀏覽器都支援」仍不代表每一種裝置、作業系統、輸入方式與實際使用情境都會完全相同。

所以現代跨瀏覽器測試的目標,不是要求每個瀏覽器做到像素級完全一樣,
而是確認內容可閱讀、功能可操作、版面不壞掉、表單能送出、
JavaScript 不報錯,而且主要商業流程能完成

先講結論:
不要再用「這是不是 Safari?」來決定程式怎麼跑。
優先檢查「這個瀏覽器支不支援我要用的功能?」,
再決定提供完整效果或 fallback。

一、網站跨瀏覽器相容性到底要測什麼?

「跨瀏覽器相容」不是 Chrome、Safari、Firefox、Edge 每一個像素都必須完全相同。
不同瀏覽器可能有不同的預設表單樣式、字型渲染與作業系統介面,
強迫所有環境長得一模一樣,通常沒有必要。

真正要確認的是使用者能不能完成網站設計原本要完成的任務。
例如企業官網至少要確定選單打得開、電話與 LINE 連結可以點、
詢價表單可以填寫與送出;
電商網站則要確認商品選擇、加入購物車、
登入與結帳流程沒有因為瀏覽器不同而中斷。

01

版面 Layout

Grid、Flexbox、定位、Sticky、Overflow、RWD breakpoint 是否正常。

02

JavaScript

Console 是否報錯,互動元件、Dialog、選單、輪播、AJAX 是否能運作。

03

表單

Input、Select、Date、驗證訊息、Autofill 與送出流程是否正常。

04

媒體

圖片格式、影片、音訊、Lazy Loading 與不同裝置解碼能力。

05

操作方式

滑鼠、鍵盤、觸控、Hover、Focus、手機虛擬鍵盤都要考慮。

06

商業流程

登入、搜尋、詢價、購物車、付款等真正影響營收的流程優先測。

二、Chrome、Edge、Safari、Firefox 為什麼還會不一樣?

Chrome Edge Safari Firefox 瀏覽器引擎比較

現代瀏覽器都遵循 HTML、CSS、ECMAScript 與各種 Web API 標準,
但底層的瀏覽器引擎、作業系統整合與功能推出時間仍可能不同。

瀏覽器 主要引擎 測試時主要注意
Google Chrome Blink / Chromium 主要開發基準、最新版 Web API、Android Chrome
Microsoft Edge Chromium 正式 Edge、Windows 環境、企業使用情境
Apple Safari WebKit iPhone / iPad、觸控、Viewport、WebKit 功能差異
Mozilla Firefox Gecko 獨立瀏覽器引擎、CSS / JS 行為、Firefox Android
Chrome 和 Edge 同樣是 Chromium,不代表只測 Chrome 就可以。
共用引擎可以減少大量差異,但正式品牌版、作業系統整合、
使用者設定與企業環境仍值得跑過關鍵流程。

三、先定義瀏覽器支援範圍,不要拿所有版本全部測一遍

跨瀏覽器測試最浪費時間的做法,就是一開始完全沒有支援政策,
然後看到什麼瀏覽器就測什麼。

正確做法是先看網站實際流量、客戶需求與系統限制,
再決定哪些瀏覽器是「完整支援」、哪些只要求基本功能可用。

益盛科技實務上會先問這四件事

01 實際訪客用什麼?

先看 GA4 或其他流量資料,不要只看全球平均市占率。

02 客戶產業是什麼?

B2B、政府、學校、企業內網可能有不同的裝置與瀏覽器環境。

03 功能有多重要?

結帳、登入、詢價要比裝飾動畫優先確保相容。

04 新功能真的需要嗎?

如果效果只是加分,就應該允許舊環境使用較簡單的 fallback。

Baseline 可以當第一層判斷

現在查 MDN 時,
很多 Web API、CSS 與 JavaScript 功能旁邊都會看到 Baseline 標示。

Widely available

已經在主要瀏覽器維持一段時間的一致支援。
一般網站使用的風險相對低。

Newly available

最新主要瀏覽器已經支援,但較舊裝置或瀏覽器可能還沒有。

Limited availability

還不是所有主要瀏覽器都有,正式使用前要準備 fallback 或重新評估。

Baseline 很適合回答「這個 Web 功能現在能不能安心使用?」,
但它不是 QA 報告。你的表單、JavaScript、第三方 API、
字型、動畫與真機操作仍然要自己測。

四、網站跨瀏覽器相容性測試完整流程

網站跨瀏覽器相容性測試完整流程

如果是企業官網或電商網站,我不建議等到全部做完才一次測。
比較有效率的方式是從開發階段就分層檢查。

1

先定支援矩陣

列出 Chrome、Edge、Firefox、Safari,以及桌機、Android、iPhone 哪些是正式支援環境。

2

先把 HTML 寫對

錯誤的巢狀標籤、重複 ID、表格結構或表單 markup,
有時會被不同瀏覽器以不同方式修正。
開發完成後先跑 HTML Validator。

3

確認 CSS / Web API 支援程度

新 CSS、JavaScript API 或瀏覽器功能先查 Baseline 與 MDN,
不要寫完才發現 Safari 或 Firefox 尚未支援。

4

桌機四大瀏覽器跑關鍵流程

Chrome、Edge、Firefox、Safari 都至少測首頁、導覽、
表單、搜尋、登入或購物流程。

5

手機模擬後,再用真機確認

DevTools 可以快速找 RWD 問題,但 iPhone Safari、
Android Chrome 的觸控、鍵盤、Viewport 與系統整合仍應用真機確認。

6

把重要流程加入自動化

登入、表單、購物車等流程可用 Playwright 或 WebDriver
放進 CI,避免下次改 CSS 或 JavaScript 又把其他瀏覽器弄壞。

五、Chrome、Safari、Firefox、Edge 前端測試重點

測試項目 Chrome Edge Safari Firefox
基本 Layout 必測 必測
手機 Viewport Android 輔助 iPhone 必測 Android
表單 / Select / Date 必測 必測
Touch / Hover Android 觸控 Windows 必測 Android
影片 / 音訊 必測 必測
Console Error
時間不夠怎麼排?
如果開發主要使用 Chrome,第二順位通常應該先測 Safari,
再跑 Firefox 與 Edge。因為 Safari 使用 WebKit、Firefox 使用 Gecko,
比再測另一個 Chromium 環境更容易發現引擎差異。
但企業內部系統若大量使用 Edge,Edge 的順位就要往前移。

六、CSS 跨瀏覽器相容性怎麼處理?

不要一開始就寫瀏覽器專用 CSS

過去常看到這種做法:

-webkit-transition: all .3s;
-moz-transition: all .3s;
-ms-transition: all .3s;
-o-transition: all .3s;
transition: all .3s;

現代前端不應該看到一個效果就手動把所有瀏覽器 Prefix 寫一輪。
大部分標準化功能直接使用標準語法即可;
專案真的需要 Prefix 時,可以交給 Autoprefixer 依 Browserslist
的瀏覽器目標自動產生。

需要新功能時,用 Progressive Enhancement

基本版先確保所有支援環境可以使用,
支援新 CSS 的瀏覽器再套上進階效果。

/* 所有瀏覽器都有基本版 */
.product-list {
  display: block;
}

/* 支援 Grid 才升級 */
@supports (display: grid) {
  .product-list {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 24px;
  }
}

如果功能不支援時需要明確 fallback,也可以反過來寫:

@supports not (display: grid) {
  .product-card {
    margin-bottom: 24px;
  }
}
這種思路的好處是:瀏覽器不需要被你「認出來」,
它自己告訴你功能支不支援。

Browserslist 建議依網站實際客群設定

前端建置環境如果有 Babel、PostCSS、Autoprefixer 等工具,
可以建立統一的 Browserslist。

# .browserslistrc 範例

> 0.5% in TW
last 2 versions
Firefox ESR
not dead

上面只是範例,不是每個網站都應該照抄。
如果你的 GA4 顯示某個舊版本瀏覽器仍有大量客戶,
支援政策就應該依真實流量調整。

七、JavaScript 相容性:不要再用 User-Agent 猜瀏覽器

很多舊網站會先問:

if (navigator.userAgent.includes("Safari")) {
  // Safari 專用處理
}

這種做法很脆弱。User-Agent 可能包含其他瀏覽器名稱,
格式也可能因版本或平台而改變。

真正應該問的是:「我要用的 API 存不存在?」

if ("IntersectionObserver" in window) {

  // 使用 IntersectionObserver
  startLazyAnimation();

} else {

  // 舊環境 fallback
  showContentImmediately();

}

CSS 功能也可以從 JavaScript 判斷:

if (CSS.supports("display", "grid")) {
  document.documentElement.classList.add("has-grid");
}
UA Sniffing 不是完全不能用。 少數無法以 feature detection 判斷、而且確實存在瀏覽器特定 bug 的情況,
才考慮瀏覽器判斷。
不要把它當成一般相容性策略。

八、最容易漏掉的問題:RWD、表單、字型、圖片與觸控

RWD 不要只測幾支熱門手機尺寸

很多網站測 RWD 時會固定選 iPhone、Pixel 幾個 DevTools Preset,
但真正要確認的是版面在「連續寬度」之間有沒有突然壞掉。

320px~大型桌機之間逐步拉動寬度
Portrait / Landscape
文字放大後是否溢出
Sticky Header 是否遮住內容
Modal 是否超出手機畫面
手機鍵盤彈出後表單能否操作

表單要測實際輸入,不只是看外觀

原生表單控制項由瀏覽器與作業系統共同呈現,
因此 Select、Date、File Upload、Autocomplete 等元件,
在不同裝置本來就可能長得不同。

比起硬把外觀做成完全一致,更重要的是保持正確的 HTML 結構

每個欄位有正確 Label、鍵盤能操作、錯誤訊息清楚,
對跨瀏覽器與無障礙都比較穩定。

不要忘記 Font 與內容高度

Windows、macOS、Android、iOS 即使使用同一組 CSS,
字型 fallback 與實際 glyph 渲染也可能不同。
因此按鈕、Tab、卡片標題不要依賴「文字一定剛好只有一行」。

.button {
  min-height: 44px;
  padding: 10px 18px;
  white-space: normal;
}

圖片與影片要準備合理 fallback

九、Chrome DevTools 模擬手機,不等於測過 Safari

Chrome Device Mode 與 iPhone Safari 真機測試差異

Chrome、Edge、Firefox、Safari 都有自己的開發者工具,
用來快速測 RWD 很方便。

工具 適合用途 不能取代什麼?
Chrome Device Mode 尺寸、DPR、觸控、CPU / Network 模擬 真正的 Safari / Firefox 引擎
Edge Device Emulation RWD、尺寸、裝置模擬 Safari / Firefox CSS 與 Web API 行為
Firefox Responsive Design Mode 尺寸、DPR、Touch、Network 真正 iPhone Safari
Safari Responsive Design Mode Safari / Apple 裝置相關測試 真機的完整使用情境

什麼情況我一定會拿真機測?

iPhone Safari

選單、表單、固定定位、滑動區域、虛擬鍵盤。

Android Chrome

觸控、表單、自動填入、圖片與實際網路速度。

登入 / 結帳

任何直接影響轉換與營收的流程,不只靠模擬器。

十、用 Playwright 做 Chrome、Edge、Firefox、WebKit 自動化測試

網站頁面多了之後,不可能每一次改 CSS 都人工把所有頁面點一遍。
這時可以把重要流程交給 Playwright。

例如把 Chromium、Firefox、WebKit、Google Chrome、 Microsoft Edge 都設定成測試 Project:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",

  projects: [
    {
      name: "chromium",
      use: {
        ...devices["Desktop Chrome"]
      }
    },

    {
      name: "firefox",
      use: {
        ...devices["Desktop Firefox"]
      }
    },

    {
      name: "webkit",
      use: {
        ...devices["Desktop Safari"]
      }
    },

    {
      name: "google-chrome",
      use: {
        channel: "chrome"
      }
    },

    {
      name: "microsoft-edge",
      use: {
        channel: "msedge"
      }
    }
  ]
});

表單測試範例

import { test, expect } from "@playwright/test";

test("聯絡表單可以正常操作", async ({ page }) => {

  await page.goto("https://example.com/contact");

  await page.getByLabel("姓名").fill("測試使用者");
  await page.getByLabel("電子郵件").fill("test@example.com");

  await page
    .getByRole("button", { name: "送出" })
    .click();

  await expect(
    page.getByText("感謝您的詢問")
  ).toBeVisible();

});
Playwright 的 WebKit 很有用,但它不是品牌版 Safari。
它適合放進 CI 提早抓 WebKit 類型的問題;
上線前如果 Safari 是你的主要客群,仍然要使用實際 Safari 驗證。

Safari 可以另外用 WebDriver

Apple 在 Safari 內提供原生 safaridriver
對登入、表單、購物流程等需要長期回歸測試的網站,
可以把 Safari 正式版也加入自動化。

十一、網站上線前跨瀏覽器相容性檢查表

Chrome Desktop

首頁、選單、表單、主要 CTA、Console 無重大錯誤。

Microsoft Edge

主要商業流程與 Windows 顯示正常。

Firefox Desktop

版面、CSS、互動與 JavaScript 功能正常。

Safari macOS

主要頁面、表單、動畫、圖片與互動正常。

iPhone Safari 真機

導覽、觸控、表單、虛擬鍵盤、固定元素正常。

Android Chrome 真機

RWD、觸控、表單與圖片載入正常。

HTML Validation

檢查無效標籤、錯誤巢狀結構與基本 markup 問題。

Keyboard

Tab 可移動、Focus 看得到、主要功能不用滑鼠也可操作。

Form

Label、Required、錯誤提示、Autocomplete、送出都正常。

不同 Viewport

不要只測 Preset,手動拉動寬度找 breakpoint 中間的問題。

圖片 / 影片 / 字型

Fallback、載入失敗與內容高度不會造成 Layout 崩壞。

商業轉換流程

聯絡、詢價、會員、購物車、付款依網站用途完整跑過一次。

跨瀏覽器相容性真正重要的不是「每個瀏覽器一模一樣」

如果 Chrome 的按鈕圓角是 8px,Safari 看起來有一點不同,
但使用者仍然看得到、點得到,而且功能正常,
這通常不是一個值得投入大量開發時間的問題。

反過來,如果 Safari 使用者打開詢價表單後,
因為一段 JavaScript 錯誤導致送出按鈕完全不能用,
那就是高優先級問題。

最高 功能壞掉

登入、表單、購物、付款不能使用。

內容不能讀

跑版、重疊、文字被切掉、按鈕無法點。

體驗差異

動畫不順、Spacing 或字型略有不同。

純視覺差異

不影響理解與操作的小型渲染差異。

這也是我們現在處理網站相容性的原則:
先保證功能,再保證閱讀與操作,
最後才處理像素級視覺差異。

網站跨瀏覽器相容性常見問題 FAQ

Chrome 正常,為什麼 Safari 還是會跑版?

Chrome 與 Safari 使用不同的瀏覽器引擎,
而且 Safari 與 iOS 還會受到 Apple 裝置、
Viewport、觸控與系統元件影響。
所以 Chrome Device Mode 只能幫你找一部分 RWD 問題,
不能當成真正 Safari 的完整替代品。

Chrome 和 Edge 都是 Chromium,還需要兩個都測嗎?

大部分一般網頁功能確實非常接近,
所以不必把所有頁面完整重測兩遍。
但正式上線前仍建議至少在 Edge 跑首頁、
導覽、表單、登入或購物等主要流程,
特別是企業與 Windows 使用者比例高的網站。

現在還需要寫 -webkit-、-moz- CSS Prefix 嗎?

不建議看到 CSS 就手動加入所有 Prefix。
標準化且廣泛支援的屬性直接寫標準語法即可。
專案若需相容較舊瀏覽器,
可以交給 Autoprefixer 搭配 Browserslist 自動處理。

可以用 JavaScript 判斷是不是 Safari 再修正嗎?

能避免就避免。比較穩定的方式是 Feature Detection,
例如檢查某個 API 是否存在,
或使用 CSS.supports() 判斷 CSS 功能。
只有碰到確定的瀏覽器特定 bug,
而且沒有其他偵測方法時,才考慮瀏覽器判斷。

Playwright WebKit 可以完全取代 Safari 真機嗎?

不行。Playwright WebKit 很適合 CI 與自動回歸測試,
可以提早抓出大量 WebKit 相容問題,
但它不是 Apple 品牌版 Safari。
重要商業流程仍建議在真正的 Safari 與 iPhone 上確認。

跨瀏覽器相容性會影響 SEO 嗎?

如果相容性問題造成 Google 能取得的內容不完整、
JavaScript 主要內容失敗、行動版無法正常操作、
內部連結失效或頁面體驗嚴重異常,就可能同時形成 SEO 問題。
因此跨瀏覽器測試不只是在修畫面,也是在降低網站技術風險。

網站在 Safari、Firefox 或手機上一直跑版?

益盛科技提供企業網站、RWD 網頁設計、網站效能與 SEO 技術檢查,
可協助檢查現有網站的瀏覽器相容性、前端結構與手機操作問題。

ABOUT THE AUTHOR

作者說明

本文由益盛科技 Ring 整理。
長期參與企業網站規劃、RWD 網頁設計、 Joomla 網站建置、網站維護與 SEO 技術優化,實務工作包含網站需求分析、 前端版面檢查、跨裝置測試、網站效能與搜尋引擎友善度調整。

文章內容以實際網站開發與維護情境為出發點,重點放在「網站能不能正常使用」,
而不是只追求不同瀏覽器之間像素完全一致。

官方參考資料

本文技術原則以 MDN、W3C、Google Chrome Developers、 Microsoft Edge Developer、Apple Safari Developer、 Mozilla 與 Playwright 官方文件為主要參考來源。

LINE