Skip to main content

瀏覽器支援

一、使用者群體（目標族群）​

最優先考量：誰會使用你的網站？

  • 如果你的網站是面向一般消費者（B2C），那就應該根據目標地區常用的瀏覽器來決定。
    例如台灣的使用者以 Chrome、Safari、Edge 為主。

  • 若是企業內部系統（B2B 或內部系統），就要根據企業內部政策，有些機關仍使用舊版 IE 或特定版本的 Edge。

  • 可以透過 Google Analytics、Mixpanel 等分析工具了解實際使用者的瀏覽器分布，再據此設定支援範圍。

二、專案的技術需求與功能​

你要實現的功能，是否依賴新技術？

  • 若你的網站使用：

    • ES6 語法（例如箭頭函式、let、const）

    • CSS Grid、Flexbox、var()、clamp()

    • Web Components、Service Worker、WebSocket
      那麼就要考慮這些技術的瀏覽器支援度（可查 Can I use）。

  • 如果你的專案目標包含舊版 IE，就必須考慮 polyfill 或 Babel 編譯轉譯，否則會導致執行錯誤。

三、維護成本與開發效率​

支援越多舊瀏覽器，成本越高。

  • 需要額外撰寫相容性 CSS（例如 fallback 給不支援 flex 的瀏覽器）。

  • 必須加入 polyfill（例如 core-js、babel-polyfill）。

  • 測試時間增加、除錯困難。

因此，建議設定一個「最低版本」門檻，例如：

  • Chrome 90+

  • Edge 90+

  • Safari 14+

  • Firefox 90+
    這樣能兼顧多數現代使用者又不犧牲太多新技術。

四、法規與組織政策​

某些政府機關或公共服務網站會有明定支援 IE 或舊瀏覽器的規範。
如果是公部門或教育單位專案，請務必查閱業主的「資訊安全與相容性要求文件」。

五、工具與設定支援​

現代前端專案可透過工具控制瀏覽器支援範圍：

  1. browserslist 設定
    在 package.json 裡設定：

    "browserslist": [
      "> 1%",
      "last 2 versions",
      "not dead"
    ]

    • > 1%：支援全球使用率超過 1% 的瀏覽器。

    • last 2 versions：支援每個主流瀏覽器的最新兩個版本。

    • not dead：不支援已無維護的瀏覽器。

    這設定會被工具如 Babel、PostCSS、Autoprefixer 自動使用。

  2. 使用 Babel 轉譯 ES 語法

    • 根據 browserslist，自動轉換為對應的舊語法。

  3. 使用 Autoprefixer 處理 CSS 前綴

    • 自動幫你補上如 -webkit-、-moz- 等。

六、實際測試策略​

最後，即使設定了 browserslist，仍建議：

  • 在多平台測試（Windows、macOS、iOS、Android）。

  • 使用瀏覽器模擬器或 BrowserStack 這類雲端測試服務。

  • 測試不同裝置解析度與觸控支援。

七、建議流程總結​

  1. 分析使用者瀏覽器比例（依實際數據）。

  2. 確認法規或客戶要求。

  3. 檢查專案使用技術的瀏覽器支援度。

  4. 設定 browserslist 並加上 Babel、Autoprefixer 等工具。

  5. 進行跨瀏覽器實測與除錯。

  6. 在專案文件中明確列出支援範圍（方便未來維護）。