重新導向延遲檢查

重新導向是一次完整的額外要求。瀏覽器必須查詢下一個主機、建立連線、為新網域進行 TLS 協商，並等待伺服器回應，然後才能要求網頁本身。同一主機上的一個躍點可能只需要幾十毫秒，但若經過短網址服務、追蹤網域和從 HTTP 導向 HTTPS 的規則，整條重新導向鏈很容易就多出半秒以上，在行動網路上更是如此。

重新導向的時間發生在所有其他步驟之前，因此會直接計入首位元組時間（Time to First Byte）和最大內容繪製（Largest Contentful Paint）。Lighthouse 和 PageSpeed Insights 也因此會標示主要文件上的重新導向。

對於每個躍點，TrueURL 會測量從送出要求到收到回應標頭的時間。需要建立新連線時，這段時間包含 DNS 查詢以及 TCP 和 TLS 連線的建立，再加上伺服器的處理時間，但不包含下載網頁主體的時間。瀑布圖會依序顯示各個躍點，讓最慢的那個一目了然。

測量是從執行檢查的 Cloudflare 資料中心進行的（通常是離您最近的那一個），而不是從您的裝置。結果顯示的是各伺服器的回應速度，但實際訪客在每個躍點上還會再加上自己的網路延遲。重複執行可以減少雜訊：第一次執行時，DNS 快取可能還沒有資料，連線也必須重新建立；之後的執行通常較接近穩定狀態。

以下是大略的參考標準，也是 TrueURL 為每個躍點的時間標示顏色時採用的分級：

• 每個躍點低於 200 ms：快速，通常是由 CDN 邊緣節點或簡單的網頁伺服器規則回應的重新導向。
• 200 到 600 ms：可以接受，常見於應用程式伺服器，或需要建立新 TLS 連線的跨網域重新導向。
• 600 ms 以上：緩慢。這類重新導向很可能是由負擔沉重的應用程式產生的，例如需要載入外掛程式或查詢資料庫的 CMS，而不是簡單的規則。

最好的最佳化方式，是直接移除躍點。其次，請盡可能在靠近訪客的位置回應重新導向：CDN 或邊緣規則的回應速度，遠快於只為了送出一個 301 就必須啟動的應用程式。

• 在您的網站以及電子郵件、廣告和社群個人檔案中直接連結到最終網址，讓大多數訪客根本不會碰到重新導向。
• 將 HTTP 導向 HTTPS、主機和斜線規則合併成單一躍點；HTTPS 重新導向檢查工具可以告訴您目前是否已經合併。
• 在 CDN、負載平衡器或網頁伺服器設定中處理重新導向，而不是在應用程式中處理。
• 送出 HSTS 標頭，讓回訪的訪客完全略過從 HTTP 導向 HTTPS 的重新導向。
• 避免將短網址服務和追蹤重新導向層層疊加。