我是 Paul Kinlan，負責 Chrome 的開發人員關係。我的工作內容之一，就是與一群充滿熱情的網頁推廣團隊合作，他們負責向產品和工程團隊傳達實際開發人員的觀點，並以提升開發人員滿意度為首要指標。
我們瞭解「滿意度」是難以追蹤及改善的客觀指標，因此會持續疊代，思考如何在重視開發人員需求的同時，提升滿意度。我們發現，與開發人員互動時，要以他們的角度出發是一項實用的指導原則。根據最近的 Stack Overflow 研究顯示，75% 的開發人員回報使用架構或某種抽象概念。因此，我們一直在思考，如何為那些已決定或無法控制技術堆疊的開發人員提供最佳服務？如何在不增加額外負擔的情況下，提高他們的工作效率？
Chrome 團隊中有一小組人員一直在進行名為 Aurora 的專案，目標是與網路平台的第三方抽象化項目 (例如架構和程式庫) 合作。他們的目標是直接將效能提升納入這些抽象層級，而非將負擔轉嫁給客戶 (網頁開發人員)。
在第三期 Chrome 開發人員內幕消息中，我與 Aurora 專案團隊的 Addy Osmani、Kara Erickson 和 Houssein Djirdeh 進行了對談，進一步瞭解他們如何處理這個專案，以及未來的發展方向。
內幕消息：使用第三方架構
讓我們從這個專案的起源開始談起。為什麼會發生這個問題？
Addy：Aurora 的初衷很簡單：讓我們與開發人員站在同一陣線，協助他們達成目標。舉例來說，我們會協助他們選擇的熱門技術堆疊提升效能。許多應用程式開發人員目前使用 React、Vue 或 Angular 建構應用程式，或是使用 Next.js 和 Nuxt 等元架構* (當然還有許多其他... Svelte、Lit、Preact、Astro。類似的例子不勝枚舉。我們不會要求這些開發人員成為專家 (例如效能專家)，而是會預設在這些堆疊中加入更多最佳做法，確保他們能順利完成開發工作。這樣一來，您只要為網路建構網站，就能間接獲得更優質的網站。
Aurora 會選擇幾個廣泛使用的架構和元架構進行合作，並記錄我們的學習成果 (例如如何建立優質圖片元件)，讓其他人可以快速跟進，並透過 Chrome 架構基金嘗試透過其他架構和工具擴大規模。雖然可以透過瀏覽器改善網頁體驗品質，但我們認為在某些情況下，也可以透過架構達成這項目標。我們希望這有助於我們達成為所有人提供更優質網頁內容的目標。
Kara：進一步來說，我們的想法是透過改善開發人員體驗，提升網頁效能。公布成效最佳做法是不夠的，因為這些做法經常變動，公司很難跟上腳步。他們有自己的業務優先事項，而這些事項可能會優先於成效。
因此，我們認為如果開發人員只有有限的時間專注於效能，那麼我們就應該讓他們更輕鬆 (且更快速) 建構效能優異的應用程式。如果我們與熱門的網路架構合作，就能在正確的抽象層級，透過高階元件、符合性警告等，改善開發人員體驗。凡是使用這些熱門工具的使用者，都能享有這些優勢。理論上，如果建議的建議有所變更，我們可以更新內部元件，開發人員不必擔心要保持最新狀態。
侯賽：我加入 Google 時擔任開發人員大使，幾年後轉換為軟體工程師。我先前的工作大多是教導網頁開發人員如何透過多種方式打造出色的使用者體驗。我們不斷提供相同的指導方針，提醒開發人員可能會影響網站效能和可用性的常見問題。在開始構思 Aurora 專案時，我們問自己：能否朝著「開發人員無須操心，因為工具鍊會為他們處理一切」的方向前進？
如果我沒理解錯，你的團隊有六位工程師嗎？我敢打賭，您無法使用所有可能的架構或程式庫。那麼，你會如何選擇合作對象？他們是誰？
Addy：網路在許多方面都像是蠻荒野的西部世界。您可以選擇所需的架構、束縛程式、程式庫和第三方。這會帶來多層複雜性，進而影響成效。如要提升成效，不妨找出那些願意表達個人意見的層級，並為他們提供更多意見。
舉例來說，網頁架構 (Next.js、Nuxt.js 和 Angular) 會嘗試納入更多意見和預設值，而非手動編譯的解決方案。這也是我們很樂意與他們合作的原因之一！在這些模型中，設定更強大的預設值，以便載入圖片、字型和指令碼，進而改善 Core Web Vitals 的做法，是合理的做法。
這也是確認現代最佳做法是否有效，或是否需要重新思考的絕佳方法，並可協助整個生態系統瞭解如何解決最佳化問題。
Kara：實際上，我們也必須考量受歡迎程度。如要盡可能在網路上發揮影響力，建議您使用擁有龐大開發人員社群的架構和程式庫。這樣一來，我們就能觸及更多開發人員和應用程式。但這並非唯一的考量。最終，這取決於熱門程度、程式庫的偏好程度，以及可用的功能組合。
舉例來說，如果只看受歡迎程度，React、Vue 和 Angular 是值得考慮的「三大」選擇。不過，我們最常使用 Next.js、Nuxt 和 Angular。這是因為 React 和 Vue 等檢視程式庫主要著重於轉譯，因此無法直接在這些程式庫中建構所需的所有功能。因此，我們會更密切地與 Next.js 和 Nuxt 等採用主觀元架構的架構合作。在這個抽象層級，我們可以建立內建元件。這些應用程式也內建伺服器，因此我們可以納入伺服器端最佳化功能。
您可能會發現 Angular 在深度合作夥伴清單中，但它並非元架構。Angular 是特殊情況，因為它相當受歡迎，但沒有像 React 和 Vue 那樣提供互補的元架構。因此，我們會直接與他們合作，並盡可能透過他們的 CLI 提供功能。
值得一提的是，我們與 Gatsby 等其他專案有許多持續合作關係，我們會定期同步設計，但不會積極提供程式碼。
那麼實際上會是什麼樣子呢？你是如何解決這個問題的？
Kara：實際上，我們有幾個合作密切的架構。我們會花點時間使用該架構分析應用程式，找出常見的效能痛點。接著，我們會與架構團隊合作，設計實驗性功能來解決這些痛點，並直接將程式碼提供給 OSS 存放區，以便實作這些功能。
我們非常重視驗證效能影響是否符合預期，因此也會與外部公司合作，在實際環境中進行效能測試。如果結果令人滿意，我們會協助這項功能達到「穩定」狀態，並可能將其設為預設功能。
這一切並非易事，到目前為止，您遇到哪些挑戰或學到哪些經驗？
Houssein：我們會盡力在許多競爭優先順序的熱門開放原始碼存放區中做出貢獻，這也是我們努力達成的重要目標之一。我們是 Google 團隊，但不代表我們的功能一定會優先推出，因此我們會盡力遵循提案和推出新功能的一般程序，避免踩到他人的「地雷」。我們很榮幸能與 Next.js、Nuxt 和 Angular 生態系統中樂於接受意見的維護人員合作。我們很高興他們願意傾聽我們對網路生態系統的疑慮，並願意以多種方式與我們合作。
我們合作的許多架構都有相同的整體目標：如何讓開發人員在享受優異的開發人員體驗的同時，也能獲得更優質的使用者體驗？我們瞭解並尊重社群有數百 (甚至數千) 位貢獻者和架構維護者，他們各自在不同的專案上進行交叉作業。
Kara：此外，我們很重視驗證效能影響，並根據資料採取行動，因此這項程序會花費較多時間。我們處於未知領域，因此有時會嘗試最佳化，但未能成功，最後也未能建構原先規劃的功能。即使功能確實可行，但審查成效的額外步驟仍會耗費時間，並延長開發時程。
尋找測試功能的實際使用者合作夥伴也是一大挑戰。如先前所述，他們是企業，有自己的優先事項，因此如果新計畫與必須優先處理的現有專案不相符，他們可能就難以配合。此外，最想尋求協助的公司通常已花時間投資成效，因此並非我們的目標對象。我們會盡力向社群中「無法」投資於成效的使用者收集意見回饋，但這類使用者最不可能與我們聯絡。
接著，您一直在著重哪些最佳化項目？
Houssein：分析數千個應用程式後，我們發現最大的效能問題通常是應用程式程式碼中的反模式，而非架構本身。舉例來說，您可能會發布不必要的大型圖片、過晚載入自訂字型、擷取過多會封鎖主執行緒的第三方要求，以及未處理非同步內容可能導致其他內容在頁面上移動的情況。無論您使用哪種工具，都可能發生這些問題，因此我們想知道，我們是否可以內建一些預設最佳化功能，以便妥善處理這些問題，同時提供簡潔的開發人員體驗，讓開發人員能順利地使用框架工具？
基於這項想法，我們已推出以下功能：
- Next.js 圖片元件。
- Next.js 指令碼元件。
- 在 Next.js 的建構程序中自動內嵌字體。
- Angular 圖片指令。
- Next.js 相容性 ESLint 外掛程式，為開發人員提供可行的指導方針。
我們的研究成果也啟發其他架構和工具實作類似的最佳化處理。這類情形包括但不限於：
- Nuxt 圖片模組
- Nuxt 字型指標覆寫值
- Nuxt 指令碼元件 (開發中)
- Gatsby 腳本元件
能否與這些玩家分享一些正面成果？
Houssein：許多網站的效能都因我們推出的最佳化功能而提升。我最喜歡的範例之一是 Leboncoin，他們改用 Next.js 圖片元件後，LCP 從 2.4 秒降至 1.7 秒。我們目前還有許多實驗和測試中的功能，並會在這個頁面持續分享相關的學習成果和成功案例。
好的，我知道您著重於最受歡迎的架構，但您目前未使用其他架構或程式庫，是否有其他方式可以讓這些架構或程式庫也能發揮效益？
Addy：Aurora 協同合作的許多效能最佳化項目，都可以由任何架構複製。舉例來說，我們在 Image 或 Script 元件方面的努力背後，通常會將現有的最佳做法編碼化。我們會嘗試記錄如何建構這類元件，以及這些元件在各個架構中的樣貌。希望這能為複製想法提供良好的開端。
我們曾經從一個生態系統 (例如 React 和 Next.js) 中學習，並將這些知識應用到其他生態系統，成效不錯。舉例來說，新的 Angular 圖片指令 (根據我們在建構 Next.js 圖片元件時所學到的知識所建構)，或是 Gatsby 提供的細部 JavaScript 分割作業方法。
同時，我們也瞭解，並非每個架構都有足夠的頻寬或經費，讓開發人員建立類似的效能功能，或投資其他他們認為對使用者重要的最佳化功能。Chrome Web Frameworks 基金是我們贊助 JavaScript 生態系統中效能工作的一種方式，讓專案能支付貢獻者的酬勞，並讓效能工作在生態系統中進一步擴大規模。
那麼，貴團隊未來的發展藍圖是什麼？
Kara：我們即將推出許多精彩的專案！以下列出幾項主要異動：
- 減少與字型相關的 CLS：載入並取代備用字型時，版面配置位移相當常見。我們正在研究使用字型指標覆寫值和「size-adjust」屬性，在 Next.js 中預設減少與字型相關的 CLS。我們也與 Nuxt 團隊進行諮詢，並計劃在明年將這項概念擴展至更多架構。
- 偵錯 INP：Interaction to Next Paint (INP) 指標已發布，我們正在與架構合作，為社群調查 INP 問題最常見的根本原因，並提供修正建議。我們一直與 Angular 密切合作，希望很快就能分享一些成果！
- 最佳化常見的第三方指令碼：在錯誤的時間載入第三方指令碼，可能會對效能造成重大負面影響。由於有幾個常見的第三方應用程式，我們正在研究是否可以為這些應用程式提供一些包裝函式，確保這些應用程式可透過框架最佳化載入，且不會阻斷主執行緒。我們會使用自己建構的 Next.js 指令碼元件，做為這項調查的起點。
開發人員可以前往這個網站追蹤進度。
媒體報導
在結束前，我想跟大家分享幾個 Google 內部架構的最新動態。
7 月，Chrome 團隊宣布為架構和工具基金提供最新一輪 50 萬美元的資助，這筆資金將用於資助旨在改善網站效能、使用者體驗和開發人員體驗的專案。日後的經費將考量新專案，因此請記得提交申請。
當然，社群中也發生了許多精彩的事件。這個生態系統已成熟，並提供 Deno 的 Fresh 等新架構，以及 Svelte 的新手上路教學課程等絕佳體驗，這不僅是瀏覽器內的示範，還可使用 Web Container API，在瀏覽器中原生執行 Node.js。好東西那麼多！
看到生態系統整合在一起，在瀏覽器中發揮所能，並協助開發人員打造適合所有人的產品，我感到非常興奮。網頁程式開發人員現在正處於令人振奮的時代。
下次再見，Hwyl fawr。
你對這期《Chrome 開發人員內幕》有何看法？提供意見回饋。