Cybozu 如何透過 Baseline 消除瀏覽器相容性負擔

Sakura Adachi

Yuriko Hirota

發布日期：2025 年 11 月 7 日

為日本境內超過 38,000 名企業客戶管理瀏覽器相容性並非易事。Kintone 每天要處理超過 150 萬個應用程式的重要業務作業，因此每個瀏覽器支援決策都至關重要。

Cybozu 是日本首屈一指的群組軟體公司，面臨一項基本挑戰：如何在產品中維持一致的網路標準，同時避免自訂瀏覽器支援矩陣的維護負擔。

解決方案？採用 Baseline 做為開發標準，這項舉動徹底改變了他們採用網頁平台功能的方式！

挑戰：瀏覽器支援與猜測

在 Baseline 推出前，Cybozu 是根據存取記錄和手動追蹤版本，自行維護瀏覽器支援條件。他們的標準是支援涵蓋前 98% 存取記錄的瀏覽器，而超出該門檻的瀏覽器使用者會看到瀏覽器更新提示。

每季，Cybozu 的工程團隊大約會花費一小時更新條件。不過，將條件整合至開發團隊的過程並不順暢，而且很常出現問題：何時可以使用新的 CSS 功能？何時可以移除新 JavaScript API 的 Polyfill？那麼，現在可以使用哪些功能？

Cybozu 的自訂條件不僅難以維護，開發人員也難以使用，而且他們發現，以使用者代理程式偵測和手動版本追蹤為基礎建構的條件，無法跟上現代網路的演進速度。

可以依據 User-Agent 字串嗎？

Cybozu 先前的方法是從 User-Agent 字串衍生瀏覽器名稱和版本，然後將這些結果匯總為「使用者」資料，但這樣真的能反映使用者的實際情況嗎？

User-Agent 是 HTTP 要求標頭，任何用戶端都可以聲稱自己是任何事物。產品存取記錄包含來自機器人、檢索器、攻擊者和其他來源的大量要求。部分用戶端會基於各種目的 (例如掃描安全漏洞)，刻意傳送舊版 User-Agent 字串。因此，存取記錄無法代表應支援的使用者。

User-Agent 無法反映可用的功能

瀏覽器版本不會對應到功能。視管道 (穩定版/Beta 版/開發人員版/Canary 版)、功能標記、Finch 實驗或企業政策而定，相同版本號碼可能會有不同功能。此外，不同瀏覽器實作功能的時間表也不盡相同，例如 CSS 巢狀結構在 Safari 16.5 (2023 年 5 月) 中推出，但 Chrome 112 (2023 年 4 月) 也有這項功能。User-Agent 字串不會指出功能是否可用。

自行負責支援瀏覽器版本

瀏覽器更新不只是為了提供新功能，定期發布的瀏覽器版本也包含重要的安全性修補程式和錯誤修正，以及新功能。如果支援舊版，不僅會導致使用者無法使用新功能，還會直接影響安全性。在企業環境中，部分使用者可能會遇到正當限制。例如：

• 貴機構可能設有嚴格的瀏覽器政策，禁止更新。
• 舊版硬體不支援更新至新版瀏覽器。
• 受管制產業的使用者，變更核准程序較慢。

不過，支援這些使用者也表示他們仍處於容易受到攻擊的狀態。

如果因舊版瀏覽器的已知安全漏洞而發生安全事件，以「使用者要求支援這個瀏覽器」為由，並非合理的解釋。如果攻擊擴散到其他正常更新瀏覽器的使用者，開發人員和其他專案利害關係人就必須承擔責任，因為他們未停止支援不安全的瀏覽器。

Cybozu 發現，如果使用者更新瀏覽器，這種做法會造成風險。單純根據記錄檔計數支援瀏覽器，無法進行適當的安全性驗證。這不僅代表您錯失新功能，更代表您未能善盡保護使用者的責任。

問題從「有多少使用者採用這個版本？」轉變為「我們是否應該根據瀏覽器版本為使用者提供支援？」

為何 Baseline 是 Cybozu 的正確答案

Cybozu 需要採用新方法，不僅要解決維護瀏覽器支援條件的作業負擔，還要解決舊方法的根本缺陷。Cybozu 提供的基準正是如此。

外部維護，不斷演進的準則

Baseline 並非每季手動重新評估瀏覽器版本，而是提供由 W3C WebDX 社群群組維護的移動目標，而非由個別公司任意決定。也就是說，瀏覽器供應商和標準機構的輸入內容會自動演變為標準。

Kintone 不再需要自行管理版本門檻，因為基準會自動演進，無須採取任何行動。功能基準狀態會明確回答可用性問題，並隨著平台演進自動更新答案。

特徵層級精確度

Baseline 並非試圖追蹤個別瀏覽器的情況，而是採取截然不同的做法。

「廣泛支援」代表主要瀏覽器已支援網頁功能 30 個月以上。這個時間範圍是根據「開發人員信號、瀏覽器發布採用率隨時間變化、高總市占率支援的估計值，以及 WebDX 社群團體的最佳判斷」而定。設定這個門檻後，Baseline 就不會追蹤無法觀察到的個別瀏覽器狀況。

開發人員可透過 Baseline 直接瞭解特定功能在各瀏覽器中的適用情形。「我們可以使用 CSS 容器查詢嗎？」現在可以回答這個問題了。開發人員可立即在 MDN 或其他文件中查看 Baseline 狀態，不必交叉參照相容性矩陣。

融入安全考量的設計

Cybozu 採用 Baseline Widely available 做為標準，將支援政策與瀏覽器供應商的支援週期自然相關的時間範圍保持一致。仍在積極維護的瀏覽器將支援所有廣泛可用的功能，同時也會接收重大安全性更新。

以存取記錄為依據的條件可能會讓支援服務停留在舊版瀏覽器，進而降低使用者更新的意願。採用 Baseline 後，我們不僅能放心使用新版功能，隨著網路平台不斷進步，使用舊版瀏覽器的使用者自然也會發現需要更新。

Baseline 不會明確排除有安全漏洞的瀏覽器，而是提供自然誘因，鼓勵使用者更新瀏覽器。

採用基準

採用 Baseline 後，Cybozu 必須改用新的版本管理方式。這表示 Cybozu 必須確信 Baseline 運作無虞，不會造成重大缺點。瞭解受影響的使用者百分比，對企業級採用至關重要。

Google Analytics Baseline Checker 是一項工具，可分析從 Google Analytics 匯出的資料，顯示支援各 Baseline 年份功能的使用者百分比。這項工具可協助 Cybozu 檢查選擇 Baseline 目標對使用者的實際影響。執行基準檢查工具後，Cybozu 發現了驚人的結果：

基準檢查工具顯示，98.8% 的 Cybozu 使用者使用的瀏覽器支援 Baseline Widely available 目標。這項涵蓋範圍比 Cybozu 先前的內部標準 (至少 98% 的使用者) 更廣。根據提供的資料，可以分析以下三個重點：

• 先前支援的瀏覽器不受影響。
• 先前不支援的瀏覽器：約有 0.8% 的瀏覽器符合 Baseline Widely available 條件，但不再顯示瀏覽器更新提示。
• 其餘瀏覽器仍會像以往一樣收到瀏覽器更新提示。

這項做法可有效消除誤判，也就是說，即使使用者使用支援的瀏覽器，也不會再看到不必要的警告 (約占 0.8%)。同時，也不會因為警告先前支援的使用者而出現誤判。

有了這項資料，Cybozu 就能放心地採用廣泛適用的 Baseline 做為目標。

實際使用基準帶來的影響

採用 Baseline 做為政策是一回事，但要讓這項政策實際運作，則需要建構工具和程序。我們必須確保開發人員不會在未手動檢查 Baseline 狀態的情況下，意外使用不支援的功能。

根據 ESLint 設定進行靜態分析

@cybozu/eslint-config 是以 OSS 為基礎的設定，適用於所有 Cybozu 產品。從css-baseline預設集開始，系統就會在建構時根據 Baseline 檢查 CSS 功能：

// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';

export default [
  ...cybozuEslintConfigBaseline.map((config) => ({
    ...config,
    files: ['**/*.css']
  })),
];

開發人員使用尚未廣泛支援的 Baseline 功能時，ESLint 會立即提供意見回饋：

這樣一來，就能避免相容性問題影響正式版。開發人員可以在開發過程初期做出明智的決策：等待這項功能廣泛推出，或實作漸進式強化功能，確切瞭解哪些使用者會受到影響。(進一步瞭解 ESLint 的 CSS 和 Baseline 支援)。

設定轉譯器，以「廣泛支援的基準」為目標

新式建構工具已開始支援以基準設定檔為目標。舉例來說，Vite 會自動以正式版中廣泛可用的基準為目標，不必進行額外設定。Browserslist 現在也支援 Baseline。

使用各種編譯器設定可確保 JavaScript 和 CSS 只在必要時轉譯，避免對已廣泛支援的功能進行不必要的轉換和 Polyfill。

免除手動維護條件和使用者意見回饋瀏覽器偵測系統

最大的維護優勢是免除手動追蹤瀏覽器版本。Cybozu 現在會依據公開維護的 @web-platform-dx/baseline-browser-mapping套件來回答這些問題，不必再召開每季會議，討論要支援哪些瀏覽器版本。

Cybozu 也建構了自動瀏覽器偵測功能，可向使用舊版瀏覽器的使用者顯示升級提示。

瀏覽器偵測功能會直接從 @web-platform-dx/baseline-browser-mapping 封裝擷取相容的瀏覽器版本。

這項程序會在建構期間執行，並產生警告橫幅，供所有產品團隊共用。隨著 Baseline 廣泛適用期涵蓋的瀏覽器越來越新，系統會自動偵測到這些變更，不需要手動介入。

簡化溝通流程

其中一項最重要但出乎意料的好處是，Baseline 簡化了跨團隊通訊。先前討論瀏覽器相容性時，需要具備公司專屬的網域知識，例如我們支援哪些瀏覽器、版本，以及目前可用的功能。新進人員需要時間學習內部標準。現在，我們採用了網頁社群廣泛認可的相容性標準，

這也有助於在工程團隊和更廣大的網路社群中，建立共同的詞彙。討論功能採用情形時，大家都會參考相同來源的相同資料，因此不必解釋內部政策，也不必在不同的相容性架構之間進行轉換。

開發工具也已跟上：Visual Studio Code 和 Chrome 開發人員工具中的「樣式」面板現在會直接顯示 Baseline 相容性資訊。開發人員不必再持續查看 MDN 或「我可以使用嗎？」來確認功能是否可安全使用。工具會立即通知他們。

確保產品能為所有人提供優質體驗

有了 Baseline，我們就能從根本上改變對瀏覽器相容性的想法，從管理負擔轉變為信任基礎。我們的實作策略以各階段的自動化為中心：

1. 開發期間意見回饋：靜態分析和基準狀態資訊卡。
2. 建構時間驗證：轉譯器會自動以 Baseline Widely available 為目標。
3. 執行階段偵測：針對使用 baseline-browser-mapping 的不支援瀏覽器，向使用者顯示警告。
4. 持續更新：與基準資料自動同步，免除手動維護作業。

行銷成果不證自明：

• 瀏覽器版本維護作業完全不需耗費時間。
• 使用者涵蓋率維持在 98.8% 以上，且功能層級的確定度高。
• 即時且自動回覆常見問題，例如「我們可以在這個瀏覽器版本中使用這項功能嗎？」
• 工程團隊共用詞彙。
• 更明確的功能採用路徑會提示團隊討論新功能整合，以及移除 Polyfill 的時間 (如有必要)。

對於考慮採用 Baseline 的機構，瞭解這項轉移對使用者的影響至關重要。Google Analytics 基準檢查工具等工具可讓您更輕鬆地進行這項評估，並取得相關說明。確認資料無誤並決定採用 Baseline 後，您就可以使用不斷擴大的 Baseline 生態系統，整理開發工作流程。

網路平台比以往更強大、更一致、更可靠，且發展速度更快。有了 Baseline，我們就能在實際工作環境中放心運用這項強大功能。

資源

• 日文原文：プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
• Cybozu ESLint 設定：@cybozu/eslint-config (GitHub 連結)
• Google Analytics 基準檢查工具：Google Analytics 基準檢查工具
• 基準瀏覽器對應：@web-platform-dx/baseline-browser-mapping
• 瞭解 Baseline：MDN 上的 Baseline