靜態網站國內訪問慢怎麼辦：先診斷再改善，GitHub Pages、Vercel、Cloudflare Pages 通用
靜態網站國內訪問慢，很多時候慢的不是託管平臺本身，而是頁面裡引用的外部資源：境外字型、統計指令碼、公共 CDN 上的 JS 庫。動手改之前，先把一次頁面載入拆成 DNS、TLS 握手、首位元組、資源下載幾段，看清時間花在哪一段，再對症處理。如果確實需要中國大陸境內的節點，就要辦 ICP 備案，並且透過持證服務商接入，這一步沒有合規的捷徑。
下面的步驟對 GitHub Pages、Vercel、Cloudflare Pages 和其他靜態託管都適用。本文不討論“優選 IP”、改 hosts 指向非官方節點這類做法：它們效果不穩定，也可能違反平臺條款。
為什麼“換個平臺”往往解決不了問題？
網上 2020–2024 年的帖子結論經常互相矛盾，一篇說某平臺快，另一篇說慢。原因很簡單：測試者的運營商、地區、時間段不同，而且大多數人只看了“整頁開啟用了幾秒”，沒有分段。
一個典型的部落格頁面，載入過程大致是：
- 解析你的域名（DNS）
- 和託管平臺的邊緣節點建立 TCP 與 TLS 連線
- 等伺服器返回 HTML 的第一個位元組（TTFB）
- 下載 HTML，再併發請求 CSS、JS、圖片、字型
- 載入第三方域名上的資源，每個新域名都要重複第 1、2 步
第 5 步往往最慢。主題模板裡自帶的字型連結、評論系統、統計程式碼，各自連一個境外域名，只要其中一個阻塞渲染，頁面就會白屏好幾秒。這時候換託管平臺不會有改善，因為慢的那個請求根本不發往託管平臺。
第一步：用瀏覽器 Network 面板看是哪個請求慢
用國內直連網路（關掉代理和加速工具）開啟 Chrome 或 Edge 的開發者工具：
- 開啟 Network 面板，勾選 Disable cache。
- 重新整理頁面，等載入結束。
- 看 Waterfall 列裡哪幾條橫條最長。
- 點開最慢的請求，切到 Timing 標籤。
Timing 裡的欄位可以這樣判讀：
| Timing 欄位 | 含義 | 這一項長說明什麼 |
|---|---|---|
| Queueing / Stalled | 瀏覽器排隊等待 | 同域名併發過多，或前面有阻塞資源 |
| DNS Lookup | 域名解析 | 解析伺服器遠、解析結果異常，或域名解析本身受干擾 |
| Initial connection / SSL | TCP + TLS 握手 | 到邊緣節點的網路路徑長或丟包 |
| Waiting for server response (TTFB) | 首位元組等待 | 回源慢、邊緣快取未命中，或節點離你遠 |
| Content Download | 內容下載 | 檔案太大，或鏈路頻寬受限 |
有兩種情況要特別留意：
- 請求一直 pending，最後失敗或超時：通常是這個域名在你的網路下無法連通。如果它是
<head>裡同步載入的 CSS 或 JS，整頁都會被拖住。 - 主 HTML 很快，但頁面遲遲不顯示：多半是渲染阻塞資源（字型、外鏈 CSS、同步指令碼）的問題，和託管平臺無關。
測之前，最好先確認自己確實是國內直連。如果系統裡開著全域性代理或分流規則，測到的是代理出口的情況。可以用 /ip 的大陸分流檢測看當前屬於“國內直連”“大陸分流”還是“全域性代理”，原理見國內網站如何看到你的真實 IP。
第二步：用命令列把主站的時間拆開
Network 面板受瀏覽器快取、擴充套件和連線複用影響。對主站域名，可以用 curl 再測一次，排除這些干擾：
curl -o /dev/null -s -w \
'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP: %{http_code}\nIP: %{remote_ip}\n' \
https://your-blog.example.com/
這幾個值是累計時間，相鄰兩項相減才是單段耗時：
Connect - DNS約等於一次 TCP 往返TLS - Connect是 TLS 握手TTFB - TLS是發出請求到收到第一個位元組的時間，包含一次網路往返和伺服器（或邊緣快取）的處理時間
建議在不同時段多跑幾次（例如上午和晚高峰各測 5 次），只看一次的結果容易被偶然的波動誤導。
再看解析結果是否正常：
dig +short your-blog.example.com
dig +short your-blog.example.com @223.5.5.5
dig +short your-blog.example.com @1.1.1.1
如果不同解析伺服器給出的地址差別很大，或者返回了明顯不屬於託管平臺的地址，就要先排查解析問題，方法見 DNS 汙染和 DNS 劫持有什麼區別。如果握手階段特別慢、偶爾超時，可以用 mtr 看路徑上哪一段開始出現丟包，讀法見 traceroute 和 mtr 結果怎麼看。
第三步：對照第三方資源，看看是不是它們拖慢的
在 Network 面板的表頭上右鍵，勾選 Domain 列，再按這一列排序，就能看到頁面引用了哪些外部域名。常見的幾類：
- 網頁字型：主題模板預設引用的境外字型服務，在大陸網路下經常載入很慢甚至失敗。
- 公共前端 CDN：jsDelivr、unpkg、cdnjs 這類公共 CDN 上的庫檔案，在國內的可用性和速度會隨時間變化。
- 統計與廣告指令碼：境外統計服務的指令碼通常不阻塞渲染，但會佔連線，也會拖慢
load事件。 - 評論系統、嵌入內容：評論框、影片、社交分享按鈕，有時會在首屏同步載入。
公共前端 CDN 在你所在網路的表現，可以直接在 cdnping 線上測速 裡看。它在瀏覽器裡測 9 個公共前端 CDN，給出兩個指標：
- 首次連線：包含 DNS 解析和 TLS 握手，對應使用者第一次訪問時的體驗；
- 往返：連線複用後 3 次請求的中位數，對應同一頁面裡後續資源的載入。
首次連線很慢但往返正常，說明問題主要出在解析或握手，資源合併到少數幾個域名、減少新連線就能改善；兩個指標都慢，說明這條線路本身質量差，應該換源或自託管。更多資料可以看 CDN 速度榜，選型的思路見如何選擇適合國內訪問的公共 CDN。
診斷結果對照表：慢在哪，就改哪
| 診斷現象 | 大機率原因 | 優先嚐試的做法 |
|---|---|---|
| 某個第三方請求 pending 後失敗，頁面白屏 | 外部資源在當前網路不可達，且阻塞渲染 | 自託管該資源，或改成非同步載入 |
| 字型請求很慢，文字遲遲不出現 | 境外字型服務慢 | 字型檔案放到自己站點下，加 font-display: swap，按需子集化 |
| 公共 CDN 上的 JS 庫慢 | 公共 CDN 在當前網路表現差 | 換成測速結果更好的源，或打包進自己的構建產物 |
| 主站 DNS 解析慢或結果異常 | 解析鏈路問題 | 檢查 DNS 記錄和解析服務商，參考 DNS 排查文章 |
| 主站 TLS 握手慢、TTFB 高 | 到託管平臺邊緣節點的路徑長 | 繫結自定義域名、提高快取命中率；仍不夠再考慮境內節點（需備案） |
| 重複訪問依然很慢 | 快取頭沒配好，每次都重新下載 | 給帶雜湊的靜態檔案設長快取 |
| 大圖片下載時間長 | 圖片體積大 | 壓縮、轉 WebP/AVIF、按螢幕尺寸輸出 |
不需要備案就能做的改善
這些改動只涉及你自己的程式碼和配置，在任何託管平臺上都能做：
1. 把外部依賴收回到自己的域名下
字型、圖示庫、JS 庫下載到倉庫裡，跟著站點一起部署。這樣頁面只需要連一個域名，少了好幾次 DNS 和 TLS 握手，也不會被某個第三方拖住。注意遵守字型和庫的許可證。
2. 讓渲染不再被阻塞
非關鍵指令碼加 defer 或 async；統計、評論這類元件放在首屏渲染之後再載入；首屏用到的關鍵 CSS 可以內聯到 HTML 裡。
3. 配好快取頭
構建工具生成的帶內容雜湊的檔案（如 app.3f9a1c.js）可以設 Cache-Control: public, max-age=31536000, immutable；HTML 本身設短快取或 no-cache，保證更新能及時生效。各個指令的區別見 Cache-Control 快取頭怎麼配。大多數靜態託管平臺都支援在配置檔案裡寫響應頭，具體寫法以平臺官方文件為準。
4. 繫結自定義域名
用自己的域名，以後想換託管平臺或接入 CDN 時，只要改 DNS 記錄，不用改站內連結和外部引用。如果在託管平臺前面再套一層 CDN，要注意 SSL 模式配置，否則容易出現重定向迴圈，參考 Cloudflare 重定向次數過多怎麼解決。
5. 減小資源體積
壓縮圖片，刪掉主題裡沒用的 JS，開啟 Brotli 或 gzip（多數平臺預設開啟，可以在響應頭的 content-encoding 裡確認）。
做完以後，用同一網路、同一時段再跑一遍第二步的 curl 和第一步的 Network 面板，前後對比，確認改動確實有效。
什麼時候需要境內節點？備案的邊界在哪裡
如果第三方資源都已經處理乾淨，主站的 TLS 握手和首位元組在國內依然明顯偏慢，那麼剩下的瓶頸就是物理距離和跨境線路。這一段靠前端最佳化解決不了，只能讓內容由離使用者更近的節點提供。
這裡有一條明確的邊界：在中國大陸境內的伺服器或 CDN 節點上提供網站服務，需要先辦 ICP 備案，並且要透過持有相應資質的服務商接入。 境外託管平臺和境外 CDN 的“亞太節點”通常部署在大陸以外，離使用者近一些，但並不等於境內加速。
可以這樣判斷：
- 個人部落格、文件站：多數時候前面那些不備案的改善已經夠用。
- 面向國內使用者的業務站、對首屏時間有明確要求的站點：建議評估備案，再選用持證服務商的境內 CDN。
cdnping 的 Edge 邊緣加速介紹頁也寫明瞭這一點：它基於 Cloudflare 全球網路提供邊緣加速，而中國大陸境內的加速同樣需要 ICP 備案並經由持證服務商。
邊緣網路本身也會出故障。cdnping 每 15 分鐘同步一次 Cloudflare 官方狀態頁，記錄顯示 2026-10-10 04:13（UTC）釋出過一條名為 “Elevated Errors in China Network Colos” 的事件，影響等級為 minor。所以如果某天站點在國內突然變慢，在懷疑自己的配置之前，先去平臺的官方狀態頁看一眼，例如 Cloudflare Status，或者 cdnping 的 API 狀態頁。
一份可以照著走的排查清單
- 確認測試網路是國內直連（用 /ip 看分流狀態）。
- Network 面板禁用快取後重新整理，找出最慢的 3 個請求，記下域名和 Timing 中最長的那一段。
- 對主站域名跑 curl 計時，不同時段至少各測 5 次。
- 用
dig對比幾個解析伺服器的結果，排除解析異常。 - 用 cdnping 線上測速 看頁面依賴的公共 CDN 在當前網路的首次連線和往返。
- 自託管或非同步化阻塞渲染的第三方資源。
- 配好靜態檔案的快取頭，壓縮圖片。
- 複測並對比改動前後的資料。
- 主站本身仍然慢、且業務需要時，再評估 ICP 備案和境內節點。
如果你的問題不只出在網站訪問上，還包括開發環境整體的網路狀況，可以接著看開發者網路自檢清單（2026 版）。
