每次使用者造訪您的網頁時，他們都會發起一場盡快接收內容的競賽。效能是影響訪客與您的網站互動方式的關鍵因素。有些人可能認為在全球範圍內移動內容會帶來顯著的延遲，但實際上，網路傳輸速度已經接近其理論極限。從這個角度來看，Cloudflare 上的資料可以在大約 76 毫秒內完成紐約和倫敦之間 11,000 公里的往返——這比眨眼還要快。
然而，由於處理請求、回應和設定的複雜性，載入網頁的延遲仍然存在。除了推動連線建立、壓縮、硬體和軟體方面的進步之外，我們還建立了一種新方法，透過預測訪客將如何與給定網頁互動來減少頁面載入延遲。
今天，我們非常高興與大家分享速度的最新飛躍：Speed Brain。它依賴 Speculation Rules API 來預先擷取使用者下一次可能導覽的內容。Speed Brain 的主要目標是在使用者導覽到網頁之前將網頁下載到瀏覽器快取，從而在實際導覽發生時幾乎可以立即載入頁面。
我們的初始方法使用一種保守模型，在使用者開始接觸或發生點擊事件時預先擷取下一個頁面的靜態內容。到 2024 年第四季及 2025 年，我們將推出更積極的推測模型，例如推測性預先轉譯（不僅是在導覽頁面前擷取頁面內容，而是完全轉譯頁面），以提供更快的體驗。最終，Speed Brain 將學會如何消除靜態網站的延遲（此過程無需任何設定），並與瀏覽器合作，確保盡可能快速地載入。
為了說明這一點，可以想像一個銷售服裝的電子商務網站。利用我們的全球請求記錄中的深入解析，我們可以高精度預測典型訪客在檢視父頁面「男士 > 服裝」時可能會點擊「襯衫」。基於此，我們可以在購物者點擊「襯衫」連結之前開始提供靜態內容，例如影像。因此，當他們確實點擊該頁面時，頁面會立即載入。最近對我們積極的載入模型實作進行的實驗室測試顯示，最大內容繪製 (LCP) 減少了 75%，LCP 是最大可見元素（如影像、影片或文字區塊）載入和轉譯所需的時間。
最棒的一點是什麼？我們將立即向所有方案類型免費提供 Speed Brain。只需從儀表板或透過 API 為您的網站開啟 Speed Brain 功能即可。這感覺就像魔法一樣，但在幕後，它需要大量巧妙的工程設計。
我們已經在所有免費網域上預設啟用 Speed Brain，並且發現成功預先擷取時 LCP 減少了 45%。Pro、Business 和 Enterprise 方案網域需要手動啟用 Speed Brain。此外，我們還強烈建議您透過儀表板啟用真實使用者測量 (RUM)，以便看到網頁效能的新改善。作為額外的好處，為您的網域啟用 RUM 將幫助我們在不久的將來為您的網站提供改進和自訂的預先擷取和預先轉譯規則。
瀏覽器運作方式一覽
在討論 Speed Brain 如何幫助快速載入內容之前，我們需要回顧一下在瀏覽器上載入內容的複雜性。每次使用者導覽至您的網頁時，都必須完成一系列請求和回應週期。
在瀏覽器與伺服器建立安全連線後，它會傳送 HTTP 請求以擷取網頁的基本文件。伺服器處理請求、構建必要的 HTML 文件並在回應中將其傳送回瀏覽器。
當瀏覽器收到 HTML 文件時，它會立即開始剖析內容。在此過程中，可能會遇到對外部資源的引用，例如 CSS 檔案、JavaScript、影像和字型。這些子資源對於正確呈現頁面至關重要，因此瀏覽器會發出額外的 HTTP 請求來擷取它們。但是，如果這些資源在瀏覽器的快取中可用，則瀏覽器可以本機擷取它們，從而顯著減少網路延遲並縮短頁面載入時間。
當瀏覽器處理 HTML、CSS 和 JavaScript 時，轉譯引擎開始在螢幕上顯示內容。顯示頁面的視覺元素後，使用者互動（例如點擊連結）會提示瀏覽器重新啟動此過程的大部分內容，以便為下一頁擷取新內容。此工作流程是每個瀏覽工作階段的典型工作流程：在使用者導覽時，瀏覽器會不斷擷取並轉譯新的或未快取的資源，導致在新頁面完全載入之前產生延遲。
以使用者瀏覽上述購物網站為例。隨著購物者從首頁移至網站的「男裝」區段，再到「服裝」區段，再到「襯衫」區段，擷取後續每個頁面所花費的時間會累積起來，最終導致購物者在完成交易之前離開網站。
理想情況下，在點擊每個連結時，瀏覽器中都存在預先擷取和預先轉譯的頁面，這將消除大部分的網路延遲影響，讓瀏覽器能夠立即載入內容並提供更順暢的使用者體驗。
等等，這種說法我之前就聽說過（我們是如何實現 Speed Brain 的？）
我們知道您在想什麼。我們已經使用預先擷取很多年了。過去甚至有過幾次推測性的預先擷取嘗試。您之前已經聽說過這些。那現在和以前有什麼不同呢？
當然，事實如此。多年來，開發人員和瀏覽器廠商一直在努力最佳化頁面載入時間並增強使用者的 Web 體驗。人們已經開發了許多技術，涵蓋網際網路堆疊的各個層——從最佳化網路層連線，到在更靠近用戶端的位置預先載入應用程式內容，等等。
早期的預先擷取：缺乏資料和靈活性
Web 預先擷取這一技術已經存在了十多年。它基於這樣一個假設，既然在不久的將來可能需要某些子資源，那麼為什麼不主動擷取它們呢？這可以包括使用者在導覽網站時可能需要的任何內容，從 HTML 頁面到影像、樣式表或指令碼等等。實際上，預測執行的核心概念並不新鮮，因為它是一種在電腦科學的各個領域廣泛應用的通用技術，已經存在多年，CPU 中的分支預測就是一個很好的範例。
在 Web 發展的早期，出現了幾種自訂預先擷取解決方案來提高效能。例如，2005 年，Google 推出了 Google Web Accelerator，這是一款旨在加快寬頻使用者瀏覽速度的用戶端應用程式。儘管具有創新性，但由於隱私和相容性問題，該專案的壽命很短暫（我們將在下面介紹 Speed Brain 的不同之處）。當時的預測性預先擷取缺乏用於擷取使用者行為的資料深入解析和 API 支援，尤其是那些處理刪除或購買等敏感動作的行為。
靜態清單和手動工作
在過去，預先擷取是透過使用 <link rel="prefetch"> 屬性作為資源提示之一來完成的。開發人員必須在每個頁面上為他們希望瀏覽器搶先擷取並快取在記憶體中的每個資源手動指定屬性。這種手動工作不僅費力，而且開發人員通常對於應預先擷取哪些資源缺乏深入瞭解，這降低了指定提示的品質。
同樣，Cloudflare 自 2015 年開始提供 URL 預先擷取功能。Cloudflare 允許客戶將靜態資源清單預先擷取到 CDN 快取中，而不是在瀏覽器快取中預先擷取。此功能允許在實際需要資源之前預先擷取資源，通常是在空閒時間或網路條件有利時進行。然而，CDN 預先擷取也存在類似的問題，因為客戶必須手動決定對於他們擁有的每一個網頁，最好應預先擷取哪些資源。如果設定錯誤，靜態連結預先擷取可能會帶來麻煩，導致網頁載入時間實際上變慢。
伺服器推送及其困境
HTTP/2 的「伺服器推送」是另一種提高 Web 效能的嘗試，方法是在請求資源之前將其推送到用戶端。理論上，這樣可以消除未來資產的額外往返需求，從而減少延遲。這種以伺服器為中心、獨斷專行地將資源「推送」到用戶端的做法帶來了重大挑戰，這主要是因為缺乏瀏覽器中已快取內容的上下文。這不僅浪費頻寬，而且由於轉譯頁面時瀏覽器擷取的競爭條件，這還可能減慢關鍵資源（如基礎 HTML 和 CSS）的交付速度。提議的快取摘要解決方案本可以將用戶端的快取內容告知伺服器，但從未廣泛實施，導致伺服器只能盲目地推送資源。2022 年 10 月，Google Chrome 取消了伺服器推送支援，Firefox 於 2024 年 9 月跟進。
Early Hints 向前邁進了一步
作為繼任者，Early Hints 在 2017 年被指定，但直到 2022 年才被廣泛採用，當時我們與瀏覽器和重要客戶合作進行了部署。此功能提供了更有效的替代方案，透過「提示」用戶端要載入哪些資源，以根據瀏覽器的需求更好地進行優先排序。具體來說，伺服器會傳送 103 Early Hints HTTP 狀態碼，以及一個瀏覽器應在準備主要回應時開始載入的關鍵頁面資產清單。這使瀏覽器能夠提前一步擷取必要的資源，並避免在資源已經快取的情況下進行多餘的預先載入。儘管 Early Hints（尚）不能因應使用者行為或動態頁面條件，但它的用途主要限於預先載入特定資產而不是完整網頁——特別是在伺服器需要長時間「思考」來產生 HTML 的情況下。
隨著 Web 的發展，能夠處理複雜、動態使用者互動的工具將變得越來越重要，以便在推測執行的效能提升與其對終端使用者的潛在缺點之間取得平衡。多年來，Cloudflare 一直在提供基於效能的解決方案，例如 Argo Smart Routing、Smart Tiered Cache 和 Smart Placement，這些解決方案會因應使用者行為並努力在網際網路上平衡速度和正確性決策。今天，我們朝著建立可快速提供內容的適應性架構邁出了新的一步。
Speed Brain 登場：是什麼讓它與眾不同？
Speed Brain 提供了一種可靠的方法，可根據我們伺服器傳回的規則集直接在瀏覽器中實作預測性預先擷取策略。透過基於先前嘗試的經驗教訓，它將資源預測的責任轉移給用戶端，從而基於使用者互動（例如將游標懸停在連結上）及其裝置功能進行更動態和個人化的最佳化。瀏覽器不再無所事事地等待使用者請求下一個網頁，而是從使用者與頁面的互動方式中獲取線索，並在使用者完成對連結的點擊之前開始請求下一個網頁。
在幕後，這個堪稱魔法的過程是透過 Speculation Rules API 實現的，這是 Google 在 Web 效能領域推出的一個新興標準。啟用 Cloudflare 的 Speed Brain 功能時，會向網頁回應新增一個稱為 Speculation-Rules 的 HTTP 標頭。此標頭的值是代管固定 Rules 設定的 URL。此設定指示瀏覽器啟動預先擷取請求，為將來的導覽做好準備。Speed Brain 不會改善造訪網站上第一個頁面的頁面載入時間，但可以改善在同一網站上造訪的後續網頁的頁面載入時間。
這個想法似乎很簡單，但預先擷取會帶來挑戰，因為一些預先擷取的內容可能永遠不會被使用。隨著 Speed Brain 的初始發佈，我們設計了一種帶有防護機製的解決方案，解決兩個重要但截然不同的問題——過時的預先擷取設定和不正確的預先擷取，這兩個問題限制了之前的推測工作。我們為此初始版本選擇的 Speculation Rules API 設定經過了精心設計，能夠在預先擷取的安全性和維持規則對整個網站的廣泛適用性之間取得平衡。
過時的預先擷取設定
由於網站隨著時間的推移不可避免地發生變化，靜態預先擷取設定通常會變得過時，從而導致效率低下或無效的預先擷取。對於 rel=prefetch 屬性或靜態 CDN 預先擷取 URL 集等技術而言尤其如此，這些技術要求開發人員手動維護其網站每個頁面的相關可預先擷取 URL 清單。大多數靜態預先擷取清單是基於開發人員的直覺而不是真實的使用者導覽資料，可能會錯過重要的預先擷取機會或在不必要的預先擷取上浪費資源。
不正確的預先擷取
由於預先擷取請求除了帶有 `sec-purpose` HTTP 請求標頭外，與普通請求一樣，因此會在用戶端、網路和伺服器上產生相同的開銷。然而，關鍵的區別在於，預先擷取請求是對使用者行為的一種預測，其回應可能最終不會被使用，因此所有這些開銷可能會被浪費。這使得預先擷取準確性極為重要，也就是說，最大化預先擷取的頁面最終被使用者檢視的百分比。不正確的預先擷取可能會導致效率低下和不必要的成本，例如快取不需要的資源，或浪費頻寬和網路資源，這對於按流量計費的行動網路或低頻寬環境尤其重要。
防護機製
在 Speed Brain 的初始版本中，我們設計了一種具備重要副作用防護機制的解決方案，完全消除了過時的預先擷取設定的可能性，並最大限度地降低了不正確的預先擷取的風險。這種固定設定是透過利用 Speculation Rules API 中的文件規則和急切性設定來實現的。我們選擇的設定如下所示：
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*", "relative_to": "document" },
]
},
"eagerness": "conservative"
}]
}
文件規則
文件規則在設定中由 "source": "document" 和 "where" 表示，允許在整個網頁上動態套用預先擷取。這樣就無需用於預先擷取的預先定義靜態 URL 清單。因此，也就消除了過時的預先擷取設定的問題，因為預先擷取候選連結是根據作用中的頁面結構確定的。
我們在 where 子句中使用 "relative_to": "document" 來指示瀏覽器將預先擷取限制為相同網站的連結。這樣做還有一個好處，就是我們的實作能夠避免跨來源預先擷取，從而避免對使用者的隱私權產生影響，因為它不會在 Web 上追踪使用者。
急切性
急切性控制瀏覽器預先擷取內容的積極程度。有四種可能的設定：
immediate：在頁面載入時盡快使用——通常，一旦瀏覽器看到這個規則值，就會立即開始預先擷取下一頁。
eager：與上面的「immediate」設定相同，但預先擷取觸發器還額外依賴輕微的使用者互動事件，例如將遊標移向連結（即將推出）。
moderate：當游標在連結上停留超過 200 毫秒時進行預先存取（或者取決於 pointerdown，以更早者為準；後者也適用於沒有懸停事件的行動裝置）。
conservative：在指針觸及連結時預先擷取。
Speed Brain 的初始版本利用 conservative 的急切性值，來最大程度地降低不正確的預先擷取的風險，該風險可能導致意外的資源浪費，同時會顯著提高您的網站速度。雖然我們錯過了更積極的急切性設定所提供的潛在效能改進，但我們選擇了這種謹慎的方法，將使用者的安全放在首位。展望未來，我們計劃為可以從更開放的設定中受益的網站探索更多動態的急切性設定，我們還將擴展規則以包括預先轉譯。
我們實施的另一項重要保護措施是僅接受已儲存在 CDN 快取中的靜態內容的預先擷取請求。如果內容不在快取中，我們會拒絕預先擷取請求。直接從 CDN 快取中擷取內容來完成預先擷取請求，讓我們無需擔心其快取資格。這樣做的理由很簡單：如果頁面不符合快取的條件，我們不希望它在瀏覽器快取中預先擷取，因為這可能會導致意外後果和增加來源伺服器的負擔。例如，預先擷取登出頁面可能會在使用者實際完成其動作之前過早登出。具狀態預先擷取或預先轉譯請求可能會產生不可預測的影響，可能會針對用戶端未確認的動作變更伺服器的狀態。透過僅允許預先擷取已在 CDN 快取中的頁面，我們確信這些頁面不會對使用者體驗產生負面影響。
這些防護措施是為了在注重效能的環境中工作而實施的。我們在 2024 年 7 月初測量了基準保守部署模型對 Cloudflare 開發人員文件中所有頁面的影響。我們發現，我們能夠預先擷取正確的內容，使用者在 94% 的時間裡確實會導覽到這些內容，同時，我們還將 p75 分位數處的 LCP 降低了 40%，提高了導覽效能，而沒有引起任何意外的副作用。這個結果非常驚人！
說明 Cloudflare 的實作
我們的全球網路遍及 330 多座城市，可在 50 毫秒內與 95% 的網際網路連線人口連線。這種廣泛的覆蓋範圍使我們能夠為客戶顯著提高可快取資產的效能。透過 Speed Brain 利用此網路進行智慧預先擷取，Cloudflare 可以直接從 CDN 快取中提供預先擷取的內容，從而將網路延遲減少到幾乎即時的水準。
憑藉在網路上的獨特位置，我們能夠自動啟用 Speed Brain，無需客戶對其來源伺服器設定進行任何變更。操作非常簡單，只需打開開關即可！我們的第一個版本 Speed Brain 現已上線。
在接收到啟用了 Speed Brain 的網頁請求後，Cloudflare 伺服器會傳回一個額外的「Specification-Rules」HTTP 回應標頭。此標頭的值是代管固定 Rules 設定（如上所述）的 URL。
當瀏覽器開始剖析回應標頭時，它會擷取我們的 Speculation-Rules 設定，並將其作為網頁的一部分載入。
該設定會根據訪客與頁面的互動情況，指導瀏覽器何時從 Cloudflare 預先擷取訪客可能瀏覽的下一個頁面。
當使用者動作（例如將滑鼠下移到下一個頁面連結上）觸發 Rules 應用程式時，瀏覽器會傳送帶有「sec-purpose: prefetch」HTTP 請求標頭的該頁面的預先擷取請求。
我們的伺服器會剖析請求標頭以識別預先擷取請求。如果所請求的內容存在於我們的快取中，我們會將其傳回；否則，我們會傳回 503 HTTP 狀態代碼並拒絕預先擷取請求。這樣就不必向不知道預先擷取的來源或 Cloudflare Workers 傳送請求，從而避免了由此帶來的不安全副作用的風險。只有在快取中存在的內容才會被傳回。
在成功回應時，瀏覽器會將內容成功地預先擷取到記憶體中，當訪客導覽至該頁面時，瀏覽器會直接從瀏覽器快取中載入網頁，實現即時呈現。
常見疑難排解模式
對 Speed Brain 的支援依賴於 Specsumption Rules API（一種新興的 Web 標準）。截至 2024 年 9 月，對這一新興標準的支援僅限於基於 Chromium 的瀏覽器（v121 或更高版本），例如 Google Chrome 和 Microsoft Edge。隨著 Web 社群就 API 標準化達成共識，我們希望看到其他瀏覽器廠商更廣泛地採用這一標準。
預先擷取本質上不適用於動態內容，因為此類內容的狀態可能會變更，可能導致向終端使用者提供過時的資料，以及增加來源伺服器負載。因此，Speed Brain 僅適用於在我們網路上快取網站的非動態頁面。這對動態頁面的載入沒有影響。為了充分利用 Speed Brain，我們建議利用快取規則來確保您網站上的所有靜態內容（尤其是 HTML 內容）都有資格進行快取。
當瀏覽器在發出推測性預先擷取請求（由 sec-purpose: prefetch 標頭標記）後，如果收到 503 HTTP 狀態代碼，則會取消預先擷取嘗試。儘管瀏覽器主控台中出現 503 錯誤可能看起來令人擔憂，但對於取消預先擷取請求來說是完全無害的。在我們的早期測試中，503 回應代碼引起了一些網站擁有者的擔憂。我們正在與合作夥伴合作，對此進行反覆運算以改善用戶端體驗，但目前請遵循規格指南，其中建議瀏覽器使用 503 回應來安全地捨棄推測性要求。根據早期 Beta 版測試人員的意見反應，我們正在與 Chrome 進行積極的討論，並認為使用新的無錯誤專用回應碼會更合適，能減少混淆。同時也請放心，與 Speed Brain 相關的預先擷取要求的 503 回應記錄沒有危害。如果您的工具難以忽略這些要求，您可以暫時停用 Speed Brain，直到我們與 Chrome 團隊達成更好的解決方案。
此外，當一個網站同時使用其自訂的推測規則和 Cloudflare 的 Speed Brain 功能時，兩個規則集可以同時運作。Cloudflare 的防護機制會將推測規則限制為可快取頁面，這對於使用現有實作的使用者來說可能是意料之外的限制。如果您觀察到此類行為，請考慮為您的網站停用其中一種實作方式，以確保行為的一致性。請注意，如果您的來源伺服器回應包含 Speculation-Rules 標頭，則不會被覆寫。因此，發生規則集衝突的可能性主要適用於預先定義的內嵌推測規則。
如何查看 Speed Brain 的影響？
一般而言，我們建議您在啟用 RUM 效能測量工具的情況下使用 Speed Brain 和大多數 Cloudflare 效能功能。我們的 RUM 功能可協助開發人員和網站營運商瞭解其終端使用者的應用程式效能體驗，並提供以下方面的可見度：
載入：內容需要多長時間才能提供？
互動性：當使用者與網站互動時，網站的回應速度如何？
視覺穩定性：載入時頁面移動了多少？
啟用 RUM 後，您可以導覽到儀表板中的 Web Analytics 區段，以查看有關 Speed Brain 如何幫助減少 Core Web Vitals 指標（如最大內容繪製 (LCP) 和載入時間等）中延遲的重要資訊。
一個網站的 RUM 儀表板範例，該網站具有大量可預先擷取的內容，並在 9 月 16 日左右啟用了 Speed Brain。
到目前為止，我們在推出過程中有什麼發現？
我們在所有 Free 方案中預設啟用此功能，並觀察到以下情況：
網域
Cloudflare 目前有數千萬個使用 Speed Brain 的網域。我們測量了這些網站第 75 分位數 (p75) 的 LCP，發現這些網站的改進介於 40% 和 50% 之間（平均值在 45% 左右）。
這種改善是透過比較同一組網域的導覽預先擷取和正常（非預先擷取）頁面載入進行比較得出的。
請求
在啟用 Speed Brain 之前，Cloudflare 上免費網站的 LCP p75 值大約為 2.2 秒。啟用 Speed Brain 後，這些網站 LCP 延遲顯著減少。總體而言，Speed Brain 每次成功預先擷取可節省大約 0.88 秒至 1.1 秒的時間！
適用的瀏覽器
目前，Speculation Rules API 僅在 Chromium 瀏覽器中可用。從 Cloudflare Radar 中，我們可以看到，大約 70% 的訪客請求來自 Chromium（Chrome、Edge 等）瀏覽器。
在整個網路中
Cloudflare 每天看到數千億個 HTML 內容請求。在這些請求中，大約一半是快取的（確保您的 HTML 可快取！）。這些請求中約有 1% 是訪客進行了導覽預先擷取。對於啟用了 Speed Brain 的網站的訪客而言，這代表著每天可節省大量時間。每 24 小時裡，Speed Brain 可以節省相當於超過 82 年的延遲！
接下來是什麼？
我們今天推出的 Speed Brain 產品只是一個開始。邁入 2025 年，我們會探索和發佈許多令人興奮的新功能。
利用機器學習
我們在網際網路上的獨特地位為我們提供了有關 Web 瀏覽模式的寶貴見解，我們可以利用這些見解來提高 Web 效能，同時維護個人使用者隱私。透過採用通用的資料驅動機器學習方法，我們可以為使用者頁面定義更準確且特定於網站的預先擷取預測器。
我們正在開發一種自適應推測模型，該模型可大大改進我們目前的保守產品。該模型使用隱私保護方法，根據相同網站的 Referer 標頭為每個網站產生使用者周遊圖。對於透過導覽躍點連接的任何兩個頁面，我們的模型會使用從彙整流量資料中提取的深入解析，預測典型使用者在它們之間移動的可能性。
使用此模型，我們能夠針對您網站上每個相關的下一頁連結，定制具有自訂急切性值的規則集。對於模型預測的使用者有較高可能瀏覽的頁面，系統將積極地預先擷取或轉譯它們。如果模型不為頁面提供規則，則會預設採用我們現有的保守方法，從而保持基準 Speed Brain 模型的優勢。這些訊號指導瀏覽器預先擷取和預先轉譯適當的頁面，協助加快使用者的導覽速度，同時保持我們目前的安全防護措施。
在實驗室測試中，我們的 ML 模型將 LCP 延遲改進了 75%，並且預測訪客導覽的準確度達到約 98%，從而確保預先擷取正確的頁面以防止浪費使用者的資源。在我們逐步擴展此解決方案的同時，我們將著重定期訓練模型，以適應不斷變化的使用者行為和不斷發展的網站。使用線上機器學習方法將大大減少任何手動更新的需求和內容漂移，同時保持高精度——Speed Brain 載入解決方案將隨著時間的推移變得越來越聰明！
透過 RUM 獲得更精細的可觀察性
正如我們之前提到的，我們認為，我們的 RUM 工具可提供有關 Speed Brain 如何幫助提高網站效能的最佳解析。未來，我們計劃提供按導覽類型篩選 RUM 工具的功能，以便您可以比較預先擷取內容與非預先擷取內容的瀏覽器呈現情況。
預先轉譯
我們目前提供對可快取內容進行預先擷取的功能。預先擷取會在使用者導覽之前下載頁面的主要文件資源，但不會指示瀏覽器預先轉譯頁面或下載任何其他子資源。
將來，Cloudflare 的 Speed Brain 產品會將內容預先擷取到我們的 CDN 快取中，然後與瀏覽器協同工作，以瞭解預先轉譯的最佳前景。這將有助於讓靜態內容更接近即時呈現。
Argo Smart Browsing：Speed Brain 與 Smart Routing
Speed Brain 在初始實作中提供了令人難以置信的效能提升，同時在實作中仍然保持保守：從急切性和資源消耗的角度而言都是如此。
如貼文先前所述，在實驗室測試更積極的模型（由機器學習和更高的急切性值驅動）後，LCP 降低了 75%。我們正在研究將這種更積極、額外的 Speed Brain 實作與 Argo Smart Routing 捆綁到一款名為「Argo Smart Browsing」的產品中。
Cloudflare 客戶可以繼續使用 Speed Brain，但想要進一步提升效能的客戶則可以一鍵啟用 Argo Smart Browsing。Argo Smart Browsing 採用更積極的模型，不僅可將可快取靜態內容在瀏覽器中的載入速度加快 75%，而且在內容無法快取且必須將請求傳送到來源伺服器的時候，它將透過效能最佳的網路路徑發送，使效能平均提高 33%。效能最佳化幾乎套用至請求生命週期的每個階段，無論內容是靜態還是動態、是否已快取。
結論
若要開始使用 Speed Brain，請在 Cloudflare 儀表板中導覽至速度 > 最佳化 > 內容最佳化 >Speed Brain 並啟用它。如此即可！該功能也可以透過 API 啟用。對於 Free 方案網域，會預設啟用 Speed Brain。
我們強烈建議客戶同時啟用 RUM（可在儀表板的同一區段中找到），以深入瞭解 Speed Brain 以及其他 Cloudflare 功能和產品所提供的效能改進。
我們很高興能繼續建立使 Web 效能可靠、快速的產品和功能。如果您是工程師，並有意為所有人提高 Web 效能，歡迎加入我們！