我是 Paul Kinlan，目前擔任 Chrome 的開發人員關係部門主管我的工作過程中，我與一群充滿熱忱的網路產品提倡者團隊合作，工作人員的任務是將真實開發人員的觀點，轉介給 Google 產品和工程團隊，並根據北極星指標提高開發人員的滿意度。
我們瞭解「滿意度」是追蹤及改善指標的宏大且主觀指標，因此我們會持續不斷改進，致力於提升開發人員需求的影響力。我們發現一項實用的指導原則：「隨時隨地與開發人員互動」。最近一項 Stack Overflow 研究顯示，75% 的開發人員回報使用架構或某種摘要。因此，我們一直在問如何為已做出決定或無法掌控自家技術堆疊的開發人員提供最完善的服務？我們該如何提升它們的工作效率，又不增加花費？
Chrome 中的一個小型團隊正在籌備名為 Aurora 的專案，目標為與網路平台 (例如架構和程式庫) 的第三方抽象化技術合作。他們的目標是將效能直接導入這些抽象化機制，而非讓網頁程式開發人員面臨繁重的負擔。
在第三版 Chrome Dev Insider 中，我與 Aurora 團隊聊聊 Addy Osmani、Kara Erickson 和 Houssein Djirdeh，進一步瞭解他們如何進行這項計畫，以及他們的未來發展。
行家專欄：採用第三方架構
我們先從這項專案的想法開始說起。過去如何？
Addy：Aurora 的想法始於簡單的概念：讓我們與開發人員交流互動，協助他們到達所需目的地。舉例來說，你可以協助他們選擇的熱門技術堆疊來改善成效。近來，許多應用程式開發人員都使用 React、Vue 或 Angular 建構應用程式 (或是 Next.js 和 Nuxt 等中繼架構*)，當然還有更多其他應用程式開發人員... Svelte、Lit、Preact、Astro。名單已經！我們不預期這些開發人員一定是深厚的專家 (如性能)，而是依預設將更多最佳做法導入這些堆疊，確保開發人員能做到這點。如此一來，品質更佳的網站只不過是打造網路環境。
Aurora 選擇幾個廣泛使用的架構和中繼架構來合作，並記錄了我們的學習成果 (例如建構優質圖片元件)，讓他人能夠快速掌握過程，並設法透過 Chrome 架構基金與其他架構和工具調整規模。雖然透過瀏覽器改善網頁體驗的品質是可行的，但我們認為在某些情況下，您也可以透過架構實現這個目標。我們希望這能幫助我們實現為所有人打造高品質網路的目標。
Kara：為了進一步探討這項功能，這個做法的目的是提升開發人員體驗，提升網頁效能。隻公開展現成效的最佳做法還不夠，因為這類做法往往會不斷變化，因此公司很難跟上腳步。廣告客戶可能有自己的業務優先要務，可能會在成效出現前行。
我們的想法是，如果開發人員的時間有限，讓他們能輕鬆、更快速地建構高效能的應用程式。如果我們與熱門的網路架構合作，就會採用最適當的抽象層，透過高階元件、符合性警告等機制改善開發人員體驗。凡是使用這些熱門工具的使用者，都能享有這些好處。理論上，如果建議的建議有所改變，我們就能在背景更新元件，而開發人員也不需煩惱更新問題。
Houssein：我以開發人員服務代表的身分加入了 Google，但幾年後我才改成擔任軟體工程職務。在我先前的工作中，大部分的作業方式都牽涉到教導網頁開發人員的各種不同方法，協助開發人員打造絕佳的使用者體驗。為了讓開發人員瞭解有哪些常見問題可能會影響網站的效能和可用性，相同的指南有多種版本可供選擇。開始思考 Aurora 專案時，我們問自己：我們是否可以不必告訴開發人員該做什麼，因為他們的工具鍊會完成所有工作？
如果我理解正確，代表你是負責團隊的六位工程師。我無法與所有可能的架構或程式庫搭配運作。如何挑選合作對象？他們的身分為何？
Addy：網路的用途很多，例如野生西部。您可視需求選擇任何架構、軟體包、程式庫和第三方。這會增加幾個複雜度，可能會導致效能良好或不佳。想要提升成效，最好的方法之一就是找出大家都給予的意見，並據此添加更多意見。
例如，網路架構 (Next.js、Nuxt.js 和 Angular) 會嘗試以更多人為意，而非以手動方式建構的解決方案。這也是我們喜愛與他們合作的原因之一！在這些模型中，如果能夠載入圖片、字型和指令碼等更嚴格的預設值，就能讓 Core Web Vitals 更加合理。
這項工具也很適合用來確認現代最佳做法在哪裡有效或可能需要重新思考，還能幫助整個生態系統瞭解如何解決最佳化問題。
Kara：說到底，我們必須將熱門程度納入考量。如果您希望盡可能提高網路影響力，可以採用現有開發人員社群眾多的架構和程式庫。進而觸及更多開發人員和更多應用程式。但這不能只是人氣影片。我們最終將瞭解熱門話題、圖書館的評價如何，以及可用的功能組合。
舉例來說，如果光看熱門程度，React、Vue 和 Angular 便是應考量的「三大要素」。不過，我們最常使用 Next.js、Nutxt 和 Angular。這是因為 React 和 Vue 等檢視畫面程式庫主要著重於轉譯，因此無法直接建構所有想要的功能。因此，我們與以 Next.js 和 Nuxt 為共同建構而成的原則式架構更加密切合作。在這個抽象層中，我們可以建立內建元件。該公司也內建伺服器，因此我們可以納入伺服器端最佳化設定。
您可能會發現 Angular 列在深厚的合作夥伴關係清單中，但這並非中繼架構。Angular 是一種特殊案例，因為它很受歡迎，但由於 React 和 Vue 沒有相輔相成的中繼架構。因此，我們直接與這些案例合作，並盡可能透過其 CLI 提供功能。
值得注意的是，我們已與其他專案 (如 Gatsby) 建立好幾個關係，以便定期在設計上同步處理，但不會積極提供程式碼。
那麼，實務上該怎麼做呢？您是透過什麼方式解決這個問題？
Kara：實務上，我們有幾個架構可以密切合作。我們需要一些時間來運用該架構剖析應用程式，並釐清常見的效能問題點。接著，我們會與架構團隊合作設計實驗功能來解決這些問題，並直接提供程式碼至 OSS 存放區進行實作。
驗證成效影響非常重要，因此我們也與外部公司合作，在實際工作環境中測試效能。如果實驗結果令人振奮，我們會協助這項功能恢復為「穩定」，且可能預設為預設狀態。
用聲音聽起來就很難。貴公司目前為止遇到了哪些挑戰或學到的經驗？
Houssein：我們盡其所能盡最大努力，為熱門的開放原始碼存放區做出許多競爭優先考量。Google 團隊不一定會優先提供功能，因此會盡量配合一般的提案和推出新功能流程，完全不必動手。我們非常開心能與 Next.js、Nuxt 和 Angular 生態系統的接受專責維護人員合作。他們樂於傾聽我們對網路生態系統的擔憂，也樂於透過多種方式與我們合作。
在我們使用的許多架構中，整體任務是相同的。開發人員該如何從一開始就獲得更優質的使用者體驗，同時享有優質的開發人員體驗？我們知道社群貢獻者與架構維護人員有數以百計甚至數千名的維護人員，各自執行彼此相關的專案，我們深知並尊重這一點。
Kara：此外，由於我們非常重視驗證成效，並根據資料採取行動，因此需要更多時間。因為我們目前的所在地區不容易規劃，所以有時為了做的最佳化工作不會變動，因此不會建立任何預定的功能。即使某項功能已省略，但在評估效能時仍須完成幾個額外步驟，並延長發布時程。
尋找可測試各項功能的製作合作夥伴並不容易。如前所述，他們是企業，有自己的優先要務，因此如果公司無法與現有的專案達成共識，他們可能會難以投入新的計畫。此外，最有意協助的公司通常已花時間提升成效，因此他們並不是我們的目標對象。我們歡迎各位社群成員向我們收集意見，看看這些社群「無法」提升廣告成效，卻是最不容易觸及我們的行為。
請問您目前重視的最佳化類型為何？
數百個應用程式：在分析數千個應用程式後，我們發現最大的效能問題通常是應用程式程式碼內的反模式，而非架構本身。例如傳送不必要的大型圖片、太晚載入自訂字型、擷取過多會封鎖主執行緒的第三方要求，以及未處理非同步內容造成網頁上其他變動的方式。無論你使用什麼工具，可能都會發生上述所有問題，因此我們想試試看一些預設最佳化功能，幫助我們妥善處理問題，並提供優質開發人員體驗，使其與架構工具完美契合？
我們秉持這樣的思維提供：
- 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 進行的效能最佳化作業大多都能透過任何架構複製。讓我們看看我們的「圖片」或「指令碼」元件成果。這些例子通常可以寫出現有的一組最佳做法。我們嘗試記錄建構這類元件的「方法」以及每個架構的呈現方式。希望以上說明能有效複製提案。
我們從單一生態系統 (例如 React 和 Next.js) 中學到的經驗獲得了不錯的成效，並且將這些資料應用在其他市場上，舉例來說，新的 Angular 圖片指令 (以我們建構 Next.js 圖片元件為學習重點) 或 Gatsby 採用我們精細的 JavaScript 區塊處理做法。
同時我們也瞭解，並非每個架構都有資金或資金協助提供者建立相似的效能功能，或投資他們認為對使用者至關重要的其他最佳化措施。我們可以透過 Chrome Web Framework Fund 贊助 JavaScript 生態系統中的成效，讓專案能夠向貢獻者支付費用，並推動效能在生態系統中擴大規模。
貴團隊的發展藍圖中有什麼項目？
Kara：我們即將推出許多令人期待的專案！以下列出幾項主要異動：
- 減少與字型相關的 CLS：一般來說，載入網路字型時版面配置會位移，並取代備用字型，是很常見的情況。我們正在探索如何使用字型指標覆寫值和「size-adjust」屬性，藉此減少 Next.js 的預設字型相關 CLS。我們也持續諮詢 Nuxt 團隊，好讓這個構想在明年能推廣到更多架構。
- 對 INP 進行偵錯：現在，「與下一個顯示的內容互動」(INP) 指標已經發布，我們正在與相關架構合作，針對社群調查 INP 問題的最常見根本原因並建議修正方式。我們與 Angular 密切合作，希望很快就能分享結果！
- 最佳化常見的第三方指令碼：在錯誤的時間載入第三方指令碼，可能會對效能產生重大負面影響。由於部分第三方相當常見，我們正在調查能否提供這類包裝函式，確保這類包裝函式能以最佳方式載入，而且不會封鎖主執行緒。我們將以我們打造的 Next.js 指令碼元件為調查對象，
開發人員可以追蹤我們在這個網站的進展。
話題地點
結束前，我想和您分享一些 Google 架構最新消息。
Chrome 團隊在 7 月宣布了最新一輪的 Frameworks 和工具基金募集了 $50 萬美元的資金，主要是資助專案，以期提升網路效能、使用者體驗和開發人員體驗。未來資金會考慮新專案，因此請記得提交要求。
當然，社群中也有一些很棒的事這個生態系統充滿了 Deno 的 Fresh 等新架構，以及 Svelte 的新手上路教學課程等絕佳體驗，不僅提供瀏覽器內示範，也會使用 Web Container API 在瀏覽器中以原生方式執行 Node.js。有這麼多優質東西！
我真心期待這個生態系統齊聚一堂，除了實現瀏覽器無限可能，還能協助開發人員打造適合所有人的產品。現在對網頁程式開發人員來說是興奮的時刻。
直到下一位行家為止，小李的衝擊。
您對這個版本的 Chrome Dev Insider 有何看法？歡迎提供意見。