開發人員經常向我們表示，很難掌握網路上的變化，也無法瞭解這些變化的原因。今天，我們將推出全新系列「Chrome 開發人員內幕」，分享 (1) 有趣且值得報導的內容、(2) 我們如何針對重要主題 (例如 變更 FLOC) 或在生態系統中進行工作 (例如 Interop 2022) 做出決策，以及 (3) 您需要瞭解的任何重要資訊 (例如 使用者代理程式字串的變更)。
我們將分享目前正在進行的工作，並以 2022 年的四大重點為背景：
- 提供出色的使用者體驗：無論是效能、交易、身分或轉換，都應讓使用者能輕鬆操作。
- 提升網頁功能：支援網頁的不斷演進角色，從內容消費平台轉型為提供多元體驗的平台，包括需要深度整合作業系統和硬體的體驗。
- 簡化網站開發：讓決策更容易，並提高開發人員的工作效率。
- 改善網頁隱私權：在開發人員的追蹤和指定目標功能日益精密的情況下，滿足網頁使用者對更完善資料隱私權保護的期望。
最新消息：Interop 2022
在規劃路線圖時，我們會參考開發人員意見回饋，瞭解網站開發人員最常遇到的問題和需求。其中一個重複出現的主題是瀏覽器相容性，也就是讓使用者在不同瀏覽器中獲得相同的體驗。過去一年，我們一直與生態系統合作，以便針對這個主題進行討論，這也是我們「簡化網頁開發」優先目標的一部分。
去年，Microsoft、Chrome 和生態系統業者宣布推出 Compat 2021，所有熱門瀏覽器引擎 (Chromium、Gecko 和 WebKit) 在當年確定的五大重點領域中，皆獲得 90% 以上的分數。除了其他功能外，Compat 2021 也為強大功能奠定了穩固基礎，例如 CSS 格線 (使用率 12%，且持續成長) 和 CSS 彈性容器 (使用率 77%)。
上個月，Apple、Bocoup、Google、Igalia、Microsoft 和 Mozilla 共同成為支援者，解決網頁開發人員指出的瀏覽器相容性問題，並達成共識，訂定共同基準。這項計畫的成果就是 Interop 2022，其目標是讓平台更加一致。基準測試著重於開發人員認為可提升工作效率的 15 個優先領域。
內幕消息：與瀏覽器同業合作
為了深入瞭解 Interop 2022 的相關資訊，我與 Robert Nyman 和 Philip Jägenstedt 進行了對談，希望能從他們的角度瞭解這項活動。以下是編輯人員剪輯的版本。
這項計畫的起源為何？
Robert：一切要從 2019 年進行的 MDN DNA 2019 問卷調查說起。相容性問題顯然是開發人員在為網頁建構時遇到的主要問題，我們在 MDN 瀏覽器相容性報告 2020 中進一步追蹤這項問題。這為我們提供了足夠的資訊和可操作資料，讓我們能開始進行 2021 年相容性計畫，並進一步透過 Interop 2022 擴大計畫範圍。
Philip：我也想提一下 web-platform-tests 和 CSS 2021 年狀態。我們與其他瀏覽器供應商合作多年，共同使用 WPT 進行測試，因此希望能繼續合作。這些功能的測試大多已編寫完成，因此我們只需要審查測試，並新增缺少的涵蓋率。Google 在 wpt.fyi 上投入了大量心力，但我們也要感謝 Mozilla 讓 WPT 獲得今天的成就。當然，Mozilla 也大力參與 MDN DNA 問卷調查。除了這些之外，還有 2021 年 CSS 現況。為了進行 Interop 2022 這類計畫，我們需要網頁開發人員的需求相關新資訊，因此我們與問卷調查維護者 Sacha 合作，加入了一些關於瀏覽器相容性問題的新問題。這對 Interop 2022 的規劃過程非常有幫助。
是否有任何 2021 年相容性研究心得或意見回饋？
Robert：評估並取得各瀏覽器引擎表現的評分和洞察資料非常實用，我們可以追蹤進度，並確保討論及解決不清楚或需要優先處理的問題。我們也很快意識到，「Interop」是這項計畫的最佳名稱。相容性和互通性這兩個詞彙通常由瀏覽器供應商區分，其中相容性是指網站相容性，而互通性是指兩個或多個瀏覽器的行為相同。在該術語中，這項工作是關於互通性，因此專案名稱也與此相符。
我們的願景是什麼？
Robert：為了讓網路保持開放，瀏覽器和轉譯引擎的多樣性至關重要。不幸的是，這會讓開發人員付出高昂的代價，因為他們必須持續追蹤各個引擎對各項功能的支援程度。我們的願景是讓開發人員將網頁平台視為最可行且最符合需求的選擇，並專注於打造最佳體驗，而非花費大量時間解決互通性問題。很明顯，要達成這個目標，我們必須將最常要求的功能納入所有主要瀏覽器引擎，才能真正讓開發人員在網路平台上取得成功。
當瀏覽器 (有時) 有不同的目標時，我們如何共同推動進展？
Philip：我們的做法是尋找共同興趣領域，找出目標大致一致的雙贏合作機會。我們會優先處理同時進行的少數工作，專注於這些領域，進而加快進度並提升品質，而非單獨處理。就是這個意思。
我認為，我們必須瞭解這種以共識為基礎的方法有其限制，如果目標不夠一致，我們就需要以其他方式前進。有時提供更多有關網頁開發人員或使用者需求的證據可能會有所幫助，但瀏覽器供應商最終可能會推出不受廣泛認同的功能。在最佳情況下，網頁開發人員會嘗試這項功能，發現它能滿足需求，並要求在所有瀏覽器中提供相同功能，進而證明這項功能的價值。
回到 Interop 2022，我們是否會在某個時間點看到非設計或版面配置功能進入管道？
Philip：沒錯！Interop 2022 不只限於樣式和版面配置功能，但最終還是偏向 CSS。部分原因是因為 CSS 2021 的狀態是新鮮的，但另一個原因是網頁程式開發人員告訴我們，他們在瀏覽器之間的差異方面遇到最多問題。除了 CSS 之外，我們也將焦點放在表單和對話方塊元素等多個領域，並且針對編輯 API 和指標與滑鼠事件進行調查。我希望在 Interop 2023 中，我們能取得更多網路開發人員需求的最新資料，並在相關工作中納入更多這類功能。
近期重要異動
這一系列文章的其中一個用意，就是讓開發人員提前得知即將發生的重要變更，這些變更對於改善使用者體驗和平台功能至關重要。
下列時間表說明這些異動預計何時發生。不過，功能的發布版本可能會有所變動。
使用者代理程式縮減
User-Agent 標頭及其相關的 JS 介面不僅會傳送實用的瀏覽器和裝置資訊，還會傳送舊版的系譜和不正確的資訊。除了 UA 字串剖析錯誤幾乎無窮無盡，更令人頭痛的是，所有導覽和子資源要求都會被動傳送至伺服器。這代表大約 10 位元熵，可讓伺服器在使用者瀏覽網頁時建立穩定的追蹤 ID。
我們目前的計畫是繼續提供低熵瀏覽器主要版本、平台名稱和mobileness，並凍結高熵資訊，藉此減少現有的 UA 字串。如果使用情境需要比標頭中包含的資訊更多資訊，我們自 Chrome 89 起就提供 User-Agent Client Hints API。
我們進行了 6 個月的 Origin 試用，以進行實驗並收集意見回饋，很高興發現在超過 200 位參與者中，我們並未收到任何與破損相關的意見回饋。
- 時間表：在 Chrome 101 中，我們將繼續執行所謂的第 4 階段：將 UA 字串中的
MINOR.BUILD.PATCH資訊縮減為0.0.0。我們會繼續提前通知網站，讓他們有時間為第 5 階段及後續階段做好準備。我們也建立了企業政策，讓使用者可以選擇不採用這些變更，並將在 Chrome 113 版前進行淘汰試驗，讓網站有更多時間準備因應這些變更。 - 行動號召： 將網站遷移至通用 Analytics 用戶端提示，或參與淘汰前測試。
Local Fonts Access API
Chrome 即將推出 Local Font Access API。雖然網站早已可以使用本機字型，但這個 API 會列舉本機字型清單，並提供字型資料本身的存取權。這項功能可讓使用者在網路設計和其他應用程式中使用所有字型。
本機字型向來是指紋辨識的媒介，雖然這個新 API 不會增加使用字型進行指紋比對的功能，但 Chrome 會要求使用者為網站授予新的 "local-fonts" 權限，才能使用新的 Local Font Access API。
日後，我們將要求使用任何提供本機字型存取權的 API 前，必須先授予相同的「local-fonts」權限。
讓 BFCache 與 Cache-control: no-store 搭配運作
我們發現有重大機會可以改善往返快取的即時返回/前進瀏覽功能。這項變更會影響 BFCache 在使用 Cache-control: no-store HTTP 標頭 的網頁上運作的方式。我們提出了公開提案，旨在透過監控各種信號 (例如在 HTTP-only Cookie 變更時，從 BFCache 中移除網頁) 和特殊情境的豁免條款 (例如企業/教育機構客戶的群組政策)，避免發生重大意外。這是複雜但令人振奮的機會，我們非常歡迎進一步的審查和意見回饋！
- 時程：鎖定 Chrome 104 (2022 年 7 月)，前提是沒有重大變動。
- 行動呼籲：請參閱提案，進一步瞭解如何啟用正在進行的導入作業，以及分享意見回饋的方式，例如我們的方法會在哪些實際情境下造成新的障礙。
透過這個系列，我希望能讓開發人員社群更瞭解我的團隊和他們的工作，進而讓他們更專注於目標。敬請密切關注這個空間，以便掌握最新消息。
在此之前，請盡情享受網路世界。
你對第一期《Chrome 開發人員內幕》有何感想？提供意見。