新的 HTTP 回應標頭，用於限制全網域指令碼，以及要求瀏覽器的專屬資源。
Origin-Agent-Cluster 是新的 HTTP 回應標頭，可指示瀏覽器防止在相同網站跨來源網頁之間進行同步指令碼存取。瀏覽器也可能會使用 Origin-Agent-Cluster，提示來源應取得專屬的獨立資源，例如專屬程序。
瀏覽器相容性
目前 Origin-Agent-Cluster 標頭僅適用於 Chrome 88 以上版本。這項計畫與 Mozilla Firefox 的代表密切合作，他們已經將其標示為值得進行原型設計，且在 Safari 使用瀏覽器引擎 WebKit 的代表方面初步認同。
但同時，目前也沒有將 Origin-Agent-Cluster 標頭部署至所有使用者的問題。無法理解該內容的瀏覽器只會忽略它。此外，origin-keyed 代理程式叢集中的網頁實際上可執行的工作比網站鍵 (預設) 「少」，因此無須擔心互通性問題。
瀏覽器無法自動隔離相同網站來源的原因
網頁版是根據同源政策建立而成，該政策是一種安全性功能，可限製文件和指令碼與其他來源的資源互動的方式。例如，由 https://a.example 代管的網頁也與 https://b.example 或 https://sub.a.example 不同。
瀏覽器會在背景採用以不同方式分隔的來源。在以往，即使不同的來源無法存取彼此的資料，他們仍會共用作業系統執行緒、程序和記憶體配置等資源。這表示如果其中一個分頁速度較慢，其他所有分頁的速度就會變慢。或者，如果一個分頁使用過多記憶體，整個瀏覽器都會當機。
現今的瀏覽器變得更精密，也會嘗試將不同來源區分至不同的程序。實際運作方式因瀏覽器而異：大部分瀏覽器在分頁之間會經過一定程度的區隔，但單一分頁中不同的 iframe 則可能會共用處理程序。此外，由於程序會佔用一些記憶體負擔，因此會使用經驗法則來避免產生過多資源：例如 Firefox 對使用者可自行設定的程序限制，而 Chrome 的行為在電腦 (記憶體空間豐富) 和行動裝置 (稀有的) 之間有所不同。
這些經驗法則並非完美無缺。此類限制具有一項重要的限制：由於相同來源政策允許 https://sub.a.example 和 https://a.example 等子網域互相通訊，因此瀏覽器無法自動區隔子網域。
這種預設行為稱為「site-keyed 代理程式叢集」：瀏覽器會根據其「網站」將網頁分組。新的 Origin-Agent-Cluster 標頭會要求瀏覽器變更指定網頁的預設行為，將其放入索引鍵具有索引鍵的代理程式叢集，如此只會與來源完全相同的其他頁面歸為一組。具體來說，系統會將同網站跨來源的頁面從代理程式叢集中排除。
這種選擇分離的做法可讓瀏覽器為這些新的 origin-keyed 代理程式叢集提供他們專屬的資源，但這類資源並未與其他來源的叢集合併使用。舉例來說，這類網頁可以取得自己的程序，或是為個別執行緒進行排程。將 Origin-Agent-Cluster 標頭新增至網頁，即表示您向瀏覽器知道網頁可使用這類專屬資源。
但為了執行區隔作業並獲得這些好處，瀏覽器必須停用部分舊版功能。
來源索引鍵頁面無法使用的功能
如果您的網頁位於 origin-keyed 代理程式叢集，即具備與先前可用的相同網站跨來源網頁通訊的功能。請特別注意以下幾點：
您無法再設定
document.domain。這是一項舊版功能，通常可讓相同網站的跨來源頁面同步存取彼此的 DOM，但在 origin-keyed 代理程式叢集中，這是停用的。您無法再透過
postMessage()將WebAssembly.Module物件傳送至其他的相同網站跨來源頁面。(僅限 Chrome) 您無法再將
SharedArrayBuffer或WebAssembly.Memory物件傳送至其他同網站但不同來源的頁面。
使用 origin-keyed 代理程式叢集的時機
最適合使用 Origin-Agent-Cluster 標頭的來源包括：
盡可能使用專屬的資源，發揮最佳成效。例如，需要耗用大量效能的遊戲、視訊會議網站或多媒體製作應用程式。
含有資源密集型 iframe，這些 iframe 來源不同但來源相同。舉例來說，如果
https://mail.example.com嵌入https://chat.example.comiframe， origin-keyinghttps://mail.example.com/可確保即時通訊團隊撰寫的程式碼不會意外幹擾郵件團隊編寫的程式碼，並提示瀏覽器提供不同的程序，讓這些程式碼獨立排程，並減少彼此對效能的影響。預期會嵌入不同來源的相同網站網頁，但知道自己會耗用大量資源。舉例來說，如果
https://customerservicewidget.example.com預期會使用大量的視訊通訊資源，並且將嵌入至https://*.example.com的多個來源中，則維護該小工具的團隊可以使用Origin-Agent-Cluster標頭，嘗試降低對嵌入程式的效能影響。
此外，您也必須確定自己能夠停用上述鮮少使用的跨來源通訊功能，且您的網站使用 HTTPS。
但最後，這些只是指南。確認 origin-keyed 代理程式叢集可能對您的網站有所助益。建議您評估網站體驗指標 (和可能的記憶體用量)，看看來源鍵定義造成哪些影響。(尤其是記憶體用量可能會受到關注，因為增加執行中的程序數量可能會導致每個程序的記憶體負擔增加)。不要只推出來源鍵，並追求最佳品質。
這與跨來源隔離有何關聯？
透過 Origin-Agent-Cluster 標頭使用代理程式叢集的 origin-keying 是相關的，但與透過 Cross-Origin-Opener-Policy 和 Cross-Origin-Embedder-Policy 標頭進行的跨來源隔離是分開的。
凡是自行跨來源隔離的網站，也將停用與使用 Origin-Agent-Cluster 標頭時相同的相同網站跨來源通訊功能。不過，Origin-Agent-Cluster 標頭在跨來源隔離上仍能發揮效用，做為瀏覽器修改資源配置經驗法則的額外提示。因此，即使網頁已跨來源隔離，我們仍建議您套用 Origin-Agent-Cluster 標頭並評估結果。
如何使用 Origin-Agent-Cluster 標頭
如要使用 Origin-Agent-Cluster 標頭，請設定網路伺服器來傳送下列 HTTP 回應標頭：
Origin-Agent-Cluster: ?1
?1 的值是布林值 true 值的結構化標頭語法。
請務必在來源的「所有」回應中傳送這個標頭，而不只是部分網頁。否則，您可能會取得不一致的結果，因為瀏覽器會「記住」 origin-keying 要求，而即使網頁不要求提供 origin-key。相反地：如果使用者造訪的第一頁不含標頭，瀏覽器就會記住並不希望來源做為起點，並忽略後續頁面的標頭。
之所以會計算這種「記憶體」，是為了確保來源的索引鍵一致性。如果來源上的某些網頁是 origin-key，而其他網頁則不是，那麼系統可能會將兩個相同來源頁面置於不同的代理程式叢集，導致彼此無法相互通訊。這對網頁程式開發人員和瀏覽器內部來說都是很奇怪。因此，如果 Origin-Agent-Cluster 的規格與先前在特定來源所看到的標頭不一致，則系統會忽略該標頭。在 Chrome 中，這會導致控制台出現警告。
這項一致性範圍僅限於瀏覽內容群組，也就是一組分頁、視窗或 iframe，而這些群組都可以透過 window.opener、frames[0] 或 window.parent 等機制相互連結。也就是說，設定來源或網站鍵後 (當瀏覽器看到或不顯示標頭)，如要變更來源，就必須開啟全新的分頁，而非以任何方式連結至舊分頁。
測試 Origin-Agent-Cluster 標頭時，則務必掌握這些詳細資料。您第一次將這段程式碼加入網站時，重新載入頁面將會無法運作。您必須關閉分頁並開啟新分頁。
如要檢查是否已套用 Origin-Agent-Cluster 標頭，請使用 JavaScript window.originAgentCluster 屬性。如果標頭 (或其他機制，例如跨來源隔離) 導致 origin-keying，這會是 true；如果不是，則為 false；在未導入 Origin-Agent-Cluster 標頭的瀏覽器中，則會使用 undefined。將這項資料記錄到您的分析平台，可以提供有價值的檢查，確認伺服器設定是否正確無誤。
最後請注意，Origin-Agent-Cluster 標頭僅適用於安全內容 (即 HTTPS 網頁或 http://localhost)。非 localhost HTTP 網頁「不」支援 origin-keyed 代理程式叢集。
Origin-keying 並非安全防護功能
雖然使用 origin-keyed 代理程式叢集可以將您的來源與跨來源的跨來源頁面同步存取隔離，但無法為安全性相關標頭 (例如 Cross-Origin-Resource-Policy 和 Cross-Origin-Opener-Policy) 提供防護。尤其是對於 Spectre 等側邊通道攻擊，這並非可靠的保護方式。
這部分可能會令人感到意外，因為來源鍵有時會導致來源取得自己的程序，而獨立的程序也是抵禦旁路攻擊的重要方式。不過請注意，Origin-Agent-Cluster 標頭只是相關提示。瀏覽器沒有義務為來源提供獨立的程序，可能的原因有很多，包括：
瀏覽器可能不支援這項技術。舉例來說，目前 Safari 和 Firefox 可將個別分頁放入各自的處理程序中，但 iframe 目前尚未支援該功能。
瀏覽器可能認為此值不值得獨立處理程序的開銷。例如，在記憶體不足的 Android 裝置或 Android WebView 中，Chrome 會盡量減少使用程序。
瀏覽器可能希望依循
Origin-Agent-Cluster標頭所指出的要求，但也可採用與程序不同的隔離技術。舉例來說，Chrome 會使用執行緒探索，而非處理這種效能隔離的程序。使用者 (或在其他網站上執行的程式碼) 可能已前往來源上的網站索引鍵網頁，導致一致性保證會啟動，並完全忽略
Origin-Agent-Cluster標頭。
因此，請不要將 origin-keyed 代理程式叢集視為安全功能。而是指出來源受益於專屬資源，且您願意以特定方式交換特定功能，協助瀏覽器優先處理資源分配的優先順序。
意見回饋：
如果您正在使用或考慮使用 Origin-Agent-Cluster 標頭，Chrome 團隊很樂意提供意見。您的公眾利益和支援可協助我們決定各項功能的優先順序，並向其他瀏覽器廠商展示他們的重要性。在 @ChromiumDev 發表推文，並讓 Chrome DevRel 分享您的想法和經驗。
如果您對規格或功能細節有其他疑問，可以前往 HTML 標準 GitHub 存放區回報問題。如果您在 Chrome 實作時遇到問題，可以在 new.crbug.com 中回報錯誤，並將「Component」欄位設為 Internals>Sandbox>SiteIsolation。
瞭解詳情
如要進一步瞭解 origin-keyed 代理程式叢集，請參閱下列連結中的詳細資料：