CDN 到底在快什麼？拆解命中、回源與邊緣節點的加速機制

設想週一早上的主管會議：投放團隊報告著陸頁的體驗分數連兩週轉差，成交成本墊高；老闆滑著手機等官網首頁轉完圈，抬頭丟出一句「聽說上 CDN 就會快，找時間弄一下？」會議室安靜了幾秒，沒有人說得準這句話到底對不對。

答不出來，是因為問法本身有問題。CDN 從來不是「讓網站變快」的開關，它做的事只有一件：讓符合快取資格的內容（預設是圖片、樣式這類靜態檔案），改走離訪客較近的那條傳輸路。效果看得到或看不到，由命中、回源、訪客分布三個條件的交集決定。它大概也是被最多人推薦、被最少人診斷的工具，盲裝的代價往往不是月費，而是把真正的瓶頸蓋住，延誤真正該做的修整。

把你的處境攤開來檢驗：訪客在哪、資源長什麼樣、流量養不養得熱快取、成本划不划算。這四個檢查點過完，裝或不裝會有答案；就算結論是不裝，你也會帶著替代解法離開，不會空手收場。

快速重點：預設情況下，CDN 只讓符合快取資格的靜態資源，改由離訪客較近的邊緣節點送出；動態與未命中的請求轉向上游，上層快取也沒有副本時才回到來源主機。效果由快取資格、命中率與訪客分布共同決定，先診斷瓶頸再評估導入，才不會把預算花在錯的藥方上。

慢有很多種，CDN 只醫其中一種

先把管轄範圍畫清楚：CDN 不改造網站本身，只改變部分內容的送出路徑。符合快取資格的靜態資源，改由離訪客較近的邊緣節點送出；主機運算慢、資料庫查詢慢、程式碼肥大，這三種慢它一概不醫。期待它像換一顆更強的處理器那樣全面提速，這個期望從第一刻就放錯了位置。

把它當萬靈丹的人不少，因為身邊的推薦太多了：主機商的方案頁寫著「全球加速」，外掛市場的一鍵整合標榜立即見效，同行社團的討論裡，CDN 三個字幾乎等於速度問題的標準答案。這些推薦有個共同點，都假設你的慢出在傳輸距離，卻沒有人先問一句：你的慢，真的出在距離嗎？比較準確的理解，是把它當成需要診斷處方的藥：處方對了見效快；沒病吃藥，花錢之外還可能蓋住真正的病灶，下次回診時病情更難說清楚。

它到底做什麼，用一個金融業的場景說完就好。銀行不會要求每個客戶都到總行辦事：常規業務在住家附近的分行就能完成，分行辦不了的再回總行處理。CDN 之於你的主機，就是分行之於總行；主機仍然是內容唯一的出處，只是多數例行請求不必再大老遠跑一趟總行。

於是有一條貫穿全文的法則值得先記住：CDN 的效果，等於快取資格、命中率、訪客分布三個條件的交集。把法則展開看更具體：一個以圖文為主的內容頁，大部分體積是圖片與樣式，這些檔案符合資格、被重複請求的機會高，訪客又散布在多個地區，三個條件同時成立，邊緣的紅利就明顯；一個以會員狀態為核心的平台，回應因人而異、預設進不了快取，交集趨近於零，同一套服務上線後體感幾乎不變。同一條法則，解釋了兩種截然不同的下場。

支撐這一切的物理事實只有一個：距離花錢買不到。主機升級讓機器算得更快，卻不會讓海洋變窄；訪客與主機之間的往返時間，是零件升級移不走的地板。CDN 動的就是這塊地板，把副本放到訪客附近，讓該走的路變短。也只動這一塊，這是它的價值，也是它的邊界。

先別急著比較服務商，先找出瓶頸在哪

「網站很慢」不是一個問題，是三個問題的混稱。把測速報表攤開，慢通常長成三種樣貌：第一種，伺服器回應慢，等待第一個位元組的時間（TTFB）偏高；第二種，前端資源肥大，HTML 很快交出來，畫面卻被大圖與厚重指令碼拖住；第三種，跨區訪客距離遠，本地量測正常，特定地區的訪客始終偏慢。先提醒一件容易誤判的事：TTFB 偏高不等於主機慢，這個數字把域名解析、連線與加密交涉、網路往返、主機處理全部加總在內；常見病因確實在主機運算與資料庫查詢，跨區訪客多走的往返同樣會推高它，歸因前要先用瀑布圖拆開看。

三種慢對三種藥：TTFB 拆解後若確認落在主機處理那段，先處理主機端快取與查詢最佳化；資源肥，先做圖片與程式碼的瘦身；只有第三種，加上部分流量保護的需求，才是 CDN 的主戰場。報表裡最有用的視圖是瀑布圖，每個請求排成一列，起訖與等待一目了然。看圖先找 HTML 那一條：從發出到回應的等待長，問題在伺服器端；HTML 快、後面的資源拖長龍，問題在前端體積；單點量測分不出來的第三種，要靠換測試節點的位置來暴露，同一頁在機房同城量得漂亮、換到跨境節點就變形，距離瓶頸才現形。先看 TTFB、再看資源載入，順序顛倒，很容易把伺服器的帳算到距離頭上，藥就下錯了。

誤診的代價不只是月費。團隊把 TTFB 的問題當成距離問題，上了 CDN、體感沒變，這筆帳會在下次的會議裡變成「速度優化做過了，沒用」，之後要再爭取任何改善預算，都得先爬出這個坑。診斷做在前面，花的時間比想像少：工具怎麼挑、報表怎麼讀，測速工具的挑選與判讀有完整的比較；已經確定慢、還不知道慢在哪一層的人，照著變慢時的完整診斷流程走一遍，多半一個下午就能把自己歸進三種慢的其中一種。

量測本身也有紀律，這是整趟決策的地基。測速節點的位置要貼近真實訪客的分布，節點離主機太近，量出來的是「節點到主機」的成績，不是訪客的體感；數字要分地區、分指標記錄下來，這份基準線是日後驗收的對照組。少了它，上線之後的一切「感覺比較快」都無從檢驗，你只能選擇相信，而驗收不能靠相信。

從名稱解析到節點：路線怎麼決定、哪些檔案會被留下

動工之前值得把機制看懂，因為四個檢查點的每一條判準，都從這套機制長出來。一個請求從訪客到內容，中間只有兩個問題：被帶進哪個節點，以及那個節點給不給得出來。前者問路線，後者問資格。

請求怎麼被導向節點

路線是這樣決定的：你把網域的 DNS 指向 CDN 之後，多數服務以 Anycast 這類路由方式運作，同一組位址在多個節點同時公告，訪客的請求被網路送進其中一個入口。有兩個常見的過度簡化要在這裡修正：其一，不是每個節點都存有你網站的副本，節點上的快取靠實際流量一份一份累積，並非全球同步的鏡像；其二，訪客被送進的節點也不保證是地理上最近的一個，實際位置由當下的路由判斷決定。DNS 接入與路由方式的完整說明，可以對照 Cloudflare 的 CDN 參考架構文件。

這兩個修正對決策很實際。節點總數再可觀，你的內容沒有被那個節點的流量養出快取，訪客照樣得走遠路；聽到「全球幾百個據點」這類宣傳時，該問的是你的目標市場有沒有被蓋到、那裡的快取養不養得熱；總數字的比大，回答不了這兩個問題。覆蓋是地圖問題，不是算術問題。

快取資格

第二個問題是資格。以 Cloudflare 這類主流服務為例，CDN 的預設行為通常只保存圖片、CSS、JavaScript、字型這類靜態檔案；HTML 預設不在快取範圍，要另行訂定規則才會進邊緣。這條線各家服務畫的位置不盡相同，Cloudflare 在預設快取行為的官方說明裡把自家的預設寫得很清楚，導入時對著所用服務的文件核對，別把單一服務的預設當成通則。這條線同時是效果的邊界：進得了快取的內容才吃得到距離紅利，進不去的照樣回源。所以同一套服務在不同網站上的表現可以差很遠，關鍵變數是快取策略，不是品牌名號。

實務上這條線由規則畫定：副檔名與路徑是最常見的判準，查詢字串與回應標頭也常被納入判斷。規則是你定的，責任就在你身上；把會員頁放進快取的，永遠不會是服務商，而是設定的人。這也是後面事故一節會反覆出現的主題。

HTML 進邊緣最知名的歷史特例是 AMP。Google 曾為這個格式建了專屬快取，把 AMP 頁面預存在全球各地的節點，並從搜尋結果這一端代為送出；2021 年起，Google 搜尋不再把 AMP 當成部分曝光機會的必要條件，這條以專屬格式換取整頁預存的路線，吸引力自此大幅消退，但格式與快取機制本身並未消失，官方文件至今仍有完整說明。它是「HTML 要另訂規則才進得了邊緣」的極端版本：規則曾經存在，後來放寬，來龍去脈在AMP 的專文解析裡有完整對照。

至於瀏覽器快取與主機端頁面快取，跟 CDN 是分層而立的三件事：一個省訪客的重複下載，一個省主機的重複運算，一個縮短傳輸的距離。三層各自管轄什麼、怎麼疊在一起，快取分層的完整說明拆得更細，這裡不重複。

把視角拉回訪客按下 Enter 的那一刻，同一個頁面會拆成兩種走法：圖片、樣式表、指令碼這類靜態資源，在邊緣節點已有副本時就近送出，這是命中走的近路；未列入快取規則的 HTML、會員資料、購物車內容這類動態回應，仍然要回到來源伺服器那一端；節點上還沒有副本的未命中請求，同樣轉向上游，上層快取也沒有時才落到來源主機，這些是回源的遠路。靜態走近、動態走遠，兩條路同時發生在同一個頁面上，訪客感受到的快慢，由走上近路的請求占比決定。如同分行辦得了的業務不必回總行，辦不了的，還是得排總行的隊。

為什麼同一頁，第一個訪客常常比較慢？

先校正一個常見的想像：邊緣節點不是早就替你備好一切，也不是永遠離訪客最近。內容第一次被某個地區請求時，節點上沒有副本，它得先向上游取一份再轉交，上游可能是上一層快取，也可能一路回到來源伺服器，多出來的這段路程與等待，由第一個訪客承擔；快不快，取決於快取資格、命中狀態與路由的實際組合，Cloudflare 的快取入門文件對這套行為有逐項說明。

這就是冷暖快取的差別。副本是靠請求養出來的：流量大的站，熱門資源隨時有人要，快取自然熱；流量小的站，同一個檔案隔了許久才被第二次請求，中間早已過期，訪客每次都像第一個。這種養不熱的體質，是檢查點三的主角，低流量站的導入評估繞不開它。

「第一個訪客」的處境還比字面上更常見：每次部署新版、每次手動清除快取、每個還沒有訪客足跡的地區，都會重新回到冷起點。改版越頻繁的團隊，冷快取的懲罰越常發生；清除快取不是免費的按鈕，按下去的當下，一批訪客又回到冷起點，得多走一段遠路。

因應的做法叫預熱：上線後主動把關鍵頁面與資源各請求一輪，讓副本先進節點，真實訪客抵達時走的才是近路。快取是跟著節點建立的，預熱因此有範圍限制：從單一定點發出的請求，通常只養得熱那個定點被路由到的節點，主要市場在哪，就該從那個地區的測試節點分別做一輪；有分層快取的服務，下層未命中還能由上層就近供應，未命中不等於回源。這件事對低流量站尤其有意義，因為你不等流量，流量短期內也不會來；不過預熱只能攤平第一波，副本到期後的重新回源仍會發生，把它當保養動作看待，別期待一勞永逸。

副本可以放多久（TTL）與什麼時候主動清除（purge），是一組兩面的設定：期限太短，節點留不住東西，反覆回源讓近路形同虛設；期限太長，改版後舊內容繼續在外頭流浪。這組取捨的災難現場留到善後一節展開，這裡先記住它有兩面，設定時兩邊都要看。

回源還有一個成本特性：多跑的那段路，乘上的是內容的體積。圖片沒壓、指令碼沒減，回源搬的就是肥肉；先把內容瘦身，路徑縮短才有意義。這句話是替代解法一節的伏筆，先記在這裡。

裝或不裝，讓四個檢查點說話：地域、資源、命中、成本

機制看完了，回到會議室裡的問題：到底裝不裝。別急著問同行、比方案，先把四個檢查點逐一過一遍；多數項目偏向邊緣受益才值得導入，否則預算該移往主機與前端，那是另一條更短的路。

檢查點一是訪客的地理分布。打開分析工具的地區報表，看跨境流量占了多少：主機所在地區的訪客走的是短距離，CDN 對他們幾乎沒有可縮短的路；跨境訪客占比越高，能被邊緣節點照顧到的請求才越多。地點只是四個檢查點的第一關，資源的長相、快取養不養得熱、管理成本划不划算，同樣握有否決權，接著逐一檢視。

跨境占比過關，下一步做節點對照：把分析工具裡的流量地圖，攤在候選服務的節點地圖上，看主要市場是否被覆蓋。Cloudflare 把全球網絡的分布公開成地圖，AWS CloudFront 的功能頁也列出邊緣據點的分布方式；要看的是「你的市場有沒有被蓋到」，不是節點總數的軍備競賽。

檢查點二是資源的長相。翻開頁面的請求清單，算一下圖片、樣式、指令碼這類可快取的靜態檔占了多少體積：占比越高，邊緣紅利越大，因為走向訪客的內容裡，有越多比例有資格改走近路。一個首頁如果有大型圖片輪播、影片縮圖與整包樣式框架，這一關通常輕鬆過。

反過來的情況要誠實面對：個人化內容多、登入狀態重的站，例如會員專區、即時報價、購物車與結帳流程，回應因人而異，預設進不了快取。這類站不是不能導入，而是要先設計分流：可快取的走邊緣、不可快取的直回源站，個人化的部分交給 Cookie 或客戶端處理。這層設計沒做，導入只是放大出錯的機會，速度沒換到，風險先進門。

檢查點三是命中的預期。延續冷暖快取的邏輯：日流量有限的站，快取養不熱，訪客經常落在「第一個」的位置，加速幅度自然有限。把每月訪客數與熱門頁面的資源分布盤一遍，命中率才有得估：哪些頁面吃掉大部分流量、那些頁面的資源被重複請求的頻率多高。這份盤點給不出精確的命中率，那個數字要上線後才量得到；它回答的是方向問題：熱門資源兩次被請求的間隔夠不夠短、副本再度被用到時還留在節點上的機率高不高。方向偏熱，加速的期待可以正常設定；方向偏冷，預期就該同步調低。

估不出來也不要硬估。命中的預期沒有把握時，效果就只能靠上線後的複測驗證，導入決策也該更保守：先用有免費層或按量計費的方案小規模試，數據說話了再談長期。這一關要防的，是把「別人說很快」當成自己的命中預期。

檢查點四是成本與風險。計費模型常見三種形態：按流量、按請求次數、包月，對照自己的流量形態算一輪；波動大的站要特別留意超出預估後的費率，以及能不能設定用量警示。管理成本也要計入：多一層服務，就多一個後台、一套規則與一個出事時要檢查的環節，團隊越小，這個成本越真實。

動手前也先盤點主機方案：不少代管主機已把邊緣快取包進方案裡，Cloudways 這類代管服務的整合方式值得先翻一遍，確認手上已經有什麼，避免重複付費買到已經存在的東西。

訪客集中在同地區的站，還有一種再評估的情境（建構情境，非實例）：一頁式活動報名頁被社群大量轉貼，短時間湧入的重複請求多數指向同一批靜態資源，邊緣吸收這些重複請求後，主機才有餘裕處理表單寫入與金流確認。這種韌性價值與訪客地理無關，說明地域不是唯一的受益條件；但若常態流量撐不起成本，事前壓力測試加頁面靜態化是更輕的解法，替代解法一節會接到。

四關走完，結論的形狀很單純：多數過關，進入前置檢查；多數不過，把預算移往真正卡住的那一層。決策靠的是你自己的流量數字，不是別人網站的見證。

過關之後：動工前的四項檢查

決定導入，先別急著動 DNS。四項檢查各自對應一種出事樣貌：中斷、混合內容、資料錯置、假上線；風險前置做完再開工，出事時才有路可退。

檢查一，DNS 切換的演練與回滾。名稱伺服器的切換不是全網同步生效，各地解析更新的時間不一，這段期間最怕「改了卻說不準誰看到什麼」。動工前記下原本的 DNS 設定、備妥回滾路徑，改動時段避開流量高峰，需要對外公告的活動頁也先打好招呼；網域解析的完整邏輯，DNS 與網域的設定說明有專門的整理。

檢查二，回源加密要設到最強，Cloudflare 的語彙叫 Full (strict) 模式。以 Cloudflare 的 SSL 選項為例：Flexible 只加密訪客到邊緣那一段，CDN 到主機仍走明文，混合內容警告與重新導向迴圈常從這裡長出來，是最常見的坑。各家服務的名稱與選項不盡相同，原則相同：兩段都要加密，來源端裝好有效憑證，讓全程加密成立。憑證的取得與安裝見SSL 憑證的實作指南，兩種連線形態的差異可對照HTTP 與 HTTPS 的比較。

檢查三，快取排除路徑清單。後台登入、購物車、結帳流程、會員專區，凡帶個人化狀態的路徑逐一列進排除清單，上線前逐條核對。這一步防的是最貴的一種事故：A 看到 B 的資料；清單寧可先嚴後鬆，也不要上線後再補。

檢查四，生效驗證的方法先備妥。判斷流量有沒有經過邊緣，主要證據是回應標頭裡的快取狀態欄位（例如 cf-cache-status）：看得到這個欄位，回應便是經過邊緣這一層轉出來的；欄位值也要會讀，HIT 代表副本由節點直接送出，MISS、BYPASS、DYNAMIC 標示的是回源或被排除的狀態，冷啟後頭幾次看到 MISS 屬於正常，值會隨快取養熱而變化。跨地區複測是輔助觀察，不是生效的證明：兩地數字有別，路由與線路差異同樣做得到；跨境節點的 LCP 朝預期方向移動，只能當旁證。狀態欄位先看、複測佐證在後，免得帳號開好了、流量照舊走老路。

沒過關的網站，還有這些替代解法

診斷的價值在於：結論為「不裝」時，你同時知道自己該做什麼。按投入成本與見效速度排，大致是下面的順序；每一項都不與日後導入 CDN 衝突，先做的基本功，到時候都是加分項。

最便宜也最快的是主機端頁面快取：把動態產出的頁面存成靜態回應，直接壓低 TTFB，主機的運算負擔同步下降。它與邊緣服務是兩層，做了不等於放棄日後導入；反過來說，日後上了 CDN，這一層照樣在運作，兩者各司其職。整體的速度工程怎麼排，網站速度優化的完整路線有地圖可循。

接著是內容瘦身：圖片壓縮與格式轉換、字型子集化、指令碼精簡與延遲載入，傳輸體積與回源成本一起下降。這一步的回報不依賴任何地理條件，本地訪客也吃得到；用 WordPress 架站的人，可以照WordPress 提速的逐項做法往下走，資料庫的清理與索引，也排在這一梯次。

做到盡頭仍不夠，問題多半在主機本身：方案等級，或機房位置。升級或搬家前把需求寫清楚，流量形態、尖峰時段、目標市場，再對照主機端方案的挑選考量逐一過濾；運算慢的病根，換主機比加一層邊緣更對症，因為它動到的是機器本身，不是路。

活動型的峰值需求另有輕解法：一年幾次的檔期著陸頁，別為了尖峰常態化導入，事前壓力測試、把頁面靜態化、尖峰時段做分流，活動結束就收，這樣更輕。為一年一次的峰值常駐一套基礎設施，帳多半算不過來；峰值管理是專案思維，常態加速才是架構思維，兩者別混用。

CDN 對 Google 排名的影響，比傳言的小

會議室裡的另一個期待也要處理：上了 CDN，排名會不會跟著變好？誠實的答案是，速度是真實存在的排名訊號，但位階低於內容相關性，而且對 CDN 來說是間接的。Google 在說明速度訊號用途的公告中指出，網頁速度自 2018 年起計入行動搜尋的排名考量；頁面體驗訊號的評估說明則讓 Core Web Vitals 成為排名系統的一環；至於行動優先索引的定案說明，講的是檢索與索引都以行動版內容為準，並非多出來的速度紅利。三份文件合起來讀，訊號的相對位置很清楚：相關性與內容品質在前，體驗分數在後。

落到指標上，Core Web Vitals 三項受 CDN 影響的程度不同：距離確實是瓶頸時，從近處送出的資源直接縮短 LCP 的等待；互動回應與版面穩定，主要取決於瀏覽器端的執行與版面設定，CDN 只能說沾到邊。三項指標的定義與量法，web.dev 的指標說明與站上的Core Web Vitals 解析都查得到，快速對照如下。

所以準確的期待是：瓶頸在傳輸距離時，CDN 改善 LCP 這類指標與訪客的等待感，屬於技術基礎的一環；它不會讓內容變得更相關，也不該被當成排名對策來採買。速度訊號在排名裡的位置，網頁速度與搜尋排名的關係講得更完整；技術面與頁面面的基礎工程，分別見技術性 SEO 的整備與頁面上的優化基礎。

行為指標要脫鉤看：等待變少，流失可能跟著變少，這是商業價值；但跳出率的解讀方式提醒我們，後台的行為數字不能直接等同排名訊號，把指標改善敘述成排名證據，是簡報裡常見的越權推論。速度為什麼值得投資，web.dev 對速度價值的說明給的是使用者行為的論據，不是排名保證。

誤判、善後與退場時機

上線後出狀況，先別急著拆掉。把每種事故放回請求旅程上看是哪一站出錯，修法自然浮現；出錯的位置大概有三種：資格、失效、連線信任。歸因對了，多數狀況半天內就能善後。

歸因有三個動作可用：讀回應標頭，看快取狀態與連線路徑，確認請求到底走到哪裡；暫時繞過 CDN 直連主機複測，症狀還在，問題在網站本身，症狀消失，問題在邊緣層；分地區比較數據，單一地區的異常指向路由，全面性的異常指向設定。三個動作做完，幾乎所有事故都能定位到一站，不用猜。

資格站出錯：動態頁被快取。症狀是會員頁出現別人的資料、結帳金額對不上，這是資安等級的事故，代價遠超速度。修法是把帶個人化狀態的路徑逐一加進排除清單，清完快取、用兩組帳號交叉複測，確認每種登入狀態看到的都是自己的畫面才收工。

失效站出錯：TTL 與清除時機。期限設太短，節點留不住副本，回源頻率把近路變成遠路，整體比直連還慢；設太長或改版後沒清，訪客繼續看到舊圖舊價格，客服的工單比速度報表先到。修法是把清除動作併進部署流程，改版即觸發，TTL 依更新頻率分級：靜態資產放長，常改的頁面縮短。

連線信任出錯：SSL 模式。Flexible 讓回源那一段走明文，混合內容與重新導向迴圈多半從這裡來，修法回前置檢查二，來源憑證加 Full (strict)。這一站的特色是症狀飄忽，時而出現時而正常，繞過直連複測最快現形。

還有一種安靜的假上線：服務註冊了、網域加了，DNS 卻沒有真的切過去，後台數字空空、流量根本沒經過邊緣。這種狀況不會出事，因為什麼都沒發生，它騙走的是時間與預算；讀一次回應標頭就能戳破，這也是前置檢查四存在的理由。

該退場的三種訊號

多數狀況善後就好，三種訊號站穩時，該認真考慮退場：排除路徑怎麼調都擋不住資料錯置；快取養熱、設定檢查完畢後，量測仍輸給直接連線；管理投入持續高於量到的效益。退場不是失敗，是條件變了：流量起來、市場擴張，都值得再進場重評。這個決策是循環，不是判刑。

上線之後的驗收：讓數據說話

回到開場場景的另一種結局：CDN 上線了，下個月的會議有人舉手，「分數跟上一版差不多，是不是沒效？」分數沒變，不代表什麼都沒發生。先分清楚手上是哪一種數字：實驗室測速（Lighthouse 這類）的分數是各項指標的加權平均，量的是單一節點、單一時刻的表現，測試節點離主機近，邊緣的改善根本量不到，測的當下快取是冷是熱，也直接改寫數字；頁面另併列的實際使用者實地資料，則是跨訪客彙整的結果，特定地區的改善會被其他地區稀釋。兩種口徑各有盲區，驗收要做的，是讓這些變因現形，別對著一個說不出量測條件的分數表態。

公平的複測有幾個條件，缺一個，前後數字就不可比：

1. 等流量把快取養熱再量，別拿剛上線的冷快取數字當基準。
2. 避開尖峰時段，伺服器與網路的負載會干擾待測指標。
3. 固定測試節點與工具，換了量尺，比較就失去意義。
4. 暖快取前後各測一輪 LCP 與完整載入時間，分地區記錄。

複測之外，再打開 CDN 後台對照命中率與回源量：分區指標改善、命中率站穩、回源量下降，三組數據指向同一個方向，驗收才算通過；只有單一總分在動，什麼都證明不了。這套驗收也回頭校準了當初的診斷：改善落在跨境地區、本地持平，正是距離瓶頸被移走後該有的長相。

整趟流程至此閉環：量測、診斷、四個檢查點、導入或替代、驗收、再量測。CDN 在其中補的，始終是其他手段都補不到的那一塊，距離；該裝的時候不要猶豫，那塊地板沒有別的工具撬得動；不該裝的時候不要跟風，蓋住瓶頸的代價，遲早會在下一次會議的報表裡現形。裝與不裝都有成本，差別在於一筆花在對症，另一筆浪費在誤診；帶著自己的流量數字回去過四個檢查點，那張會議桌上的問題，下次你答得上來。