發布日期：2025 年 5 月 20 日
當所有瀏覽器都實作某項網路平台功能時，該功能就會成為「新近推出」的 Baseline。30 個月後，該功能就會成為 Baseline Widely available，也就是大多數網站都能採用該功能，不必擔心相容性問題。本指南說明如何使用 Baseline，以及如何根據網站使用者提供的資料選取 Baseline 目標。
什麼是基準目標？
基準目標是一組網頁功能，開發人員可根據基準狀態選擇支援。基準目標分為兩種：移動目標和固定目標。
「基準廣泛適用」或「基準新推出」等移動目標所含的功能組合可能會隨時間變更。如果您希望支援的功能集隨著新版瀏覽器發布而自動演進，那麼移動目標就很適合。
固定目標是指特徵集不會隨時間變更的目標。一般來說，固定目標是以日曆年為準。舉例來說，「2023 年基準」是固定目標，內含 2023 年成為「基準」的新網頁功能。2023 年基準不會納入 2023 年後成為基準的功能，也就是說，2023 年基準功能集永遠不會變更。
如果可預測性和確定性至關重要，固定目標就非常合適，但這類目標可能會隨著時間過時，因此使用固定目標時，建議定期重新評估目標。
為何要選擇目標？
由於相容性問題，網路上的功能採用率受到限制，這也阻礙了網路發展。Baseline 不僅能清楚說明瀏覽器支援哪些功能，還能協助您瞭解何時可以使用特定功能。選擇符合目標對象和需求的目標，即可放心使用該目標群組中的功能，不必逐一檢查個別功能。
根據資料選取基準目標
選取正確的基準目標時，應盡可能根據資料做出決策。有了這些資料，您就能更輕鬆且明智地決定要選取哪個目標。
如果您有網站的實際使用者監控資料，可以瞭解基準目標如何對應至使用者。舉例來說，如果您使用 Google Analytics，可以透過Google Analytics 基準檢查工具免費取得這項資訊。
如要使用這項功能，請在 Google Analytics 中建立新的探索，在報表中新增一些指標和維度，然後將報表匯出為 TSV 檔案。如要瞭解這個程序的詳細步驟，請參閱這些指示。將 TSV 檔案匯入檢查工具後，您應該會收到類似下列的輸出內容：
我們發現其他工具也開始支援 Baseline，可動態顯示有多少觀眾支持特定目標。舉例來說，RUMvision 資訊主頁會顯示有多少觀眾支援各個 Baseline 年份。
如果我的 Analytics 或 RUM 供應商尚未提供基準目標報表，該怎麼辦？
如果您使用的 Analytics 或 RUM 工具尚未提供 Baseline 目標報表，但有瀏覽器版本資料，可以將實際資料與 baseline-browser-mapping 模組中的瀏覽器版本對應資料合併。這個模組提供 JavaScript 函式 - getAllVersions()，可依名稱和版本將瀏覽器對應至 Baseline 年份和廣泛支援狀態。這些對應項目可以陣列、鍵控物件或 CSV 格式提供。舉例來說，Google Analytics 基準檢查工具會使用這個模組，將 Analytics 資料與基準目標彙整。
這項函式的輸出內容也會以代管 JSON 或 CSV 檔案的形式提供，且每天都會更新。all_versions_with_supports.csv 檔案包含的資料可與您的 Analytics 供應商瀏覽器版本資料相符，其中包含下列欄位：
browser：瀏覽器名稱，如baseline-browser-mapping中所用version：瀏覽器版本。部分瀏覽器只會使用主要版本號碼，其他瀏覽器則會使用「主要.次要」major.minor版本號碼。year：這個瀏覽器版本支援的基準年份功能集。如果瀏覽器版本是在 2015 年 7 月確定 Baseline 支援功能之前發布，這個欄位會包含pre_baselinesupports：如果瀏覽器版本支援這些功能集，這個欄位會包含widely或newly；如果瀏覽器版本不支援這些功能集，這個欄位會空白。支援「新推出」的所有瀏覽器版本，也支援「廣泛推出」。release_date：這個瀏覽器版本的發布日期 (如有)。engine：核心基準瀏覽器下游瀏覽器的引擎名稱。目前只會納入以 Blink 為基礎的瀏覽器，但未來可能會納入其他瀏覽器引擎。engine_version：這個瀏覽器版本實作的 Chromium 版本。這項資訊用於判斷下游版本支援的 Baseline 功能集。
隨著新版瀏覽器推出，以及不同瀏覽器的支援狀態改變，這個檔案也會頻繁更新。請務必每天更新資料。
如果沒有實際使用者的支援資料，該怎麼辦？
您可能會發現，對於 Baseline 功能，您無法取得真實的使用者資料。好消息是，您可以透過 RUM 封存深入分析，大致瞭解不同 Baseline 目標的支援情形，甚至可以篩選至國家/地區層級。雖然這項資料並非專為網站使用者提供，這項工具提供一般資訊，可證明下列假設通常是安全的：
- 較新的基準目標 (例如當年度或前一年) 的支援度可能最低。不過，與任何 Baseline 目標一樣，隨著時間推移，這些目標將獲得更完善的支援。
- 舊版基準目標 (尤其是「基準廣泛適用」) 將獲得完善支援。如有疑問，建議以「廣泛適用」為目標，這項目標會隨著 30 個月期限的進展而演變。
- 即使是更舊的基準目標 (遠遠超過 30 個月的「廣泛推出」期限)，也能獲得最佳支援。「廣泛適用」是良好的預設目標，但需要嚴格 SLA 的特殊用途。
即使您選取的 Baseline 目標超過五年，您可能還是可以採用目前未使用的功能。在最佳情況下，您可能已在使用這些功能，但可能不需要使用 polyfill。
如何在專案中強制執行所選的 Baseline 目標？
Browserslist 是常見的方法，可指定要支援的瀏覽器。在 Bundler 和其他相關工具 (例如 Babel 和 PostCSS) 中，系統會使用這項資訊來判斷是否需要轉換或甚至填補特定程式碼片段。
現在您可以使用 Baseline 和 Browserslist，選取 Baseline 目標時，可以將其指定為有效的 Browserslist 查詢。確保專案中的工具會根據所選目標轉換程式碼。詳情請參閱「搭配 Browserslist 使用 Baseline」。
如果功能未達到基準目標，該怎麼辦？
選取 Baseline 目標後，您可能想使用某些功能，但這些功能不屬於該目標。Baseline 不會告訴您該怎麼做，是否要考慮使用這些功能，取決於您要建構的網站類型和預期目標對象。
舉例來說，電子商務或 B2B 網站可能願意降低支援門檻，並在使用者支援時處理問題，而政府網站可能需要較高的支援門檻。 這裡有一項重要的經驗法則：並非所有網頁功能都會以相同方式失敗。您可以透過許多方式，根據功能故障情形進行分類，但其中一種實用的分類方式如下：
- 強化功能：如果使用者在不支援的瀏覽器中使用這項功能，體驗不會中斷。體驗可能會變差，但使用者可能不會注意到。例如：
loading="lazy"。 - 加成：這項功能可提供一些明顯的加成效果，例如網頁樣式或某些功能有所變更。如果瀏覽器不支援這項功能，使用者可能不會注意到差異，除非在支援的瀏覽器中進行比較。範例：Subgrid
- 重大：如果功能不受支援，使用者體驗會受到負面影響，甚至可能完全無法使用。示例：File System Access API 用於核心必要功能。
您也可能會發現，目標以外的特定功能比您想像中更受支援。您可以瞭解有多少使用者支援特定功能。Can I Use 可根據您的 Analytics 資料，檢查個別功能的支援情形。如果需要，RUMvision 也能深入探索功能層級的資料。
這樣一來，您就能使用 Baseline 目標，減少需要仔細考量的功能數量。目標內的所有內容都不必擔心。如果目標範圍外有一兩項特別實用的功能，您可以使用相關工具進一步探索，並決定是否要進行 Polyfill 或做為漸進式強化功能。
結論
每個網路應用程式都有不同的需求，從可容忍更多不相容問題的電子商務網站，到必須盡可能供更多使用者存取及運作的政府網站，不一而足。這些計算必須自行完成，Baseline 的目標並非告訴您採用新版網頁功能時應如何做決定，而是著重於如何採用。