現代的跨瀏覽器相容性已經不是以前針對 IE6、IE7、IE8 寫一堆 CSS Hack,
而是從「支援哪些瀏覽器」開始,逐步檢查 HTML、CSS、JavaScript、RWD、
表單、字型、圖片與實際裝置操作。
網站跨瀏覽器相容性怎麼做?Chrome、Safari、Firefox、Edge 前端測試重點
做網站十幾年前最麻煩的事情之一,是同一段 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 連結可以點、
詢價表單可以填寫與送出;
電商網站則要確認商品選擇、加入購物車、
登入與結帳流程沒有因為瀏覽器不同而中斷。
版面 Layout
Grid、Flexbox、定位、Sticky、Overflow、RWD breakpoint 是否正常。
JavaScript
Console 是否報錯,互動元件、Dialog、選單、輪播、AJAX 是否能運作。
表單
Input、Select、Date、驗證訊息、Autofill 與送出流程是否正常。
媒體
圖片格式、影片、音訊、Lazy Loading 與不同裝置解碼能力。
操作方式
滑鼠、鍵盤、觸控、Hover、Focus、手機虛擬鍵盤都要考慮。
商業流程
登入、搜尋、詢價、購物車、付款等真正影響營收的流程優先測。
二、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 |
共用引擎可以減少大量差異,但正式品牌版、作業系統整合、
使用者設定與企業環境仍值得跑過關鍵流程。
三、先定義瀏覽器支援範圍,不要拿所有版本全部測一遍
跨瀏覽器測試最浪費時間的做法,就是一開始完全沒有支援政策,
然後看到什麼瀏覽器就測什麼。
正確做法是先看網站實際流量、客戶需求與系統限制,
再決定哪些瀏覽器是「完整支援」、哪些只要求基本功能可用。
益盛科技實務上會先問這四件事
先看 GA4 或其他流量資料,不要只看全球平均市占率。
B2B、政府、學校、企業內網可能有不同的裝置與瀏覽器環境。
結帳、登入、詢價要比裝飾動畫優先確保相容。
如果效果只是加分,就應該允許舊環境使用較簡單的 fallback。
Baseline 可以當第一層判斷
現在查 MDN 時,
很多 Web API、CSS 與 JavaScript 功能旁邊都會看到
Baseline 標示。
已經在主要瀏覽器維持一段時間的一致支援。
一般網站使用的風險相對低。
最新主要瀏覽器已經支援,但較舊裝置或瀏覽器可能還沒有。
還不是所有主要瀏覽器都有,正式使用前要準備 fallback 或重新評估。
但它不是 QA 報告。你的表單、JavaScript、第三方 API、
字型、動畫與真機操作仍然要自己測。
四、網站跨瀏覽器相容性測試完整流程
如果是企業官網或電商網站,我不建議等到全部做完才一次測。
比較有效率的方式是從開發階段就分層檢查。
先定支援矩陣
列出 Chrome、Edge、Firefox、Safari,以及桌機、Android、iPhone 哪些是正式支援環境。
先把 HTML 寫對
錯誤的巢狀標籤、重複 ID、表格結構或表單 markup,
有時會被不同瀏覽器以不同方式修正。
開發完成後先跑 HTML Validator。
確認 CSS / Web API 支援程度
新 CSS、JavaScript API 或瀏覽器功能先查 Baseline 與 MDN,
不要寫完才發現 Safari 或 Firefox 尚未支援。
桌機四大瀏覽器跑關鍵流程
Chrome、Edge、Firefox、Safari 都至少測首頁、導覽、
表單、搜尋、登入或購物流程。
手機模擬後,再用真機確認
DevTools 可以快速找 RWD 問題,但 iPhone Safari、
Android Chrome 的觸控、鍵盤、Viewport 與系統整合仍應用真機確認。
把重要流程加入自動化
登入、表單、購物車等流程可用 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");
}才考慮瀏覽器判斷。
不要把它當成一般相容性策略。
八、最容易漏掉的問題:RWD、表單、字型、圖片與觸控
RWD 不要只測幾支熱門手機尺寸
很多網站測 RWD 時會固定選 iPhone、Pixel 幾個 DevTools Preset,
但真正要確認的是版面在「連續寬度」之間有沒有突然壞掉。
表單要測實際輸入,不只是看外觀
原生表單控制項由瀏覽器與作業系統共同呈現,
因此 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、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 裝置相關測試 | 真機的完整使用情境 |
什麼情況我一定會拿真機測?
選單、表單、固定定位、滑動區域、虛擬鍵盤。
觸控、表單、自動填入、圖片與實際網路速度。
任何直接影響轉換與營收的流程,不只靠模擬器。
十、用 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();
});它適合放進 CI 提早抓 WebKit 類型的問題;
上線前如果 Safari 是你的主要客群,仍然要使用實際 Safari 驗證。
Safari 可以另外用 WebDriver
Apple 在 Safari 內提供原生 safaridriver。
對登入、表單、購物流程等需要長期回歸測試的網站,
可以把 Safari 正式版也加入自動化。
十一、網站上線前跨瀏覽器相容性檢查表
首頁、選單、表單、主要 CTA、Console 無重大錯誤。
主要商業流程與 Windows 顯示正常。
版面、CSS、互動與 JavaScript 功能正常。
主要頁面、表單、動畫、圖片與互動正常。
導覽、觸控、表單、虛擬鍵盤、固定元素正常。
RWD、觸控、表單與圖片載入正常。
檢查無效標籤、錯誤巢狀結構與基本 markup 問題。
Tab 可移動、Focus 看得到、主要功能不用滑鼠也可操作。
Label、Required、錯誤提示、Autocomplete、送出都正常。
不要只測 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 技術檢查,
可協助檢查現有網站的瀏覽器相容性、前端結構與手機操作問題。
官方參考資料
本文技術原則以 MDN、W3C、Google Chrome Developers、 Microsoft Edge Developer、Apple Safari Developer、 Mozilla 與 Playwright 官方文件為主要參考來源。

