把網(wǎng)站測速? 收斂成“TTFB 350ms、首字節(jié)快就健康”是漏看了“服務(wù)端思考時間server think-time”的典型降維。RFC 8297 定義的 HTTP103 Early Hints? 允許服務(wù)端在最終 200 還沒拼完時先發(fā)一個 1xx 臨時響應(yīng)把Link: x.css; relpreload; asstyle、Link: y.woff2; relpreload; asfont; crossorigin、relpreconnect推給瀏覽器讓關(guān)鍵 CSS/字體/LCP 圖在源站查庫渲染的那 200–600ms 里并行下載而不是等 200 到了再解析 HTML 才發(fā)現(xiàn)。 只報 TTFB 不驗 103等于把“源站 400ms 思考時間被 Early Hints 填成 0 等待”和“源站 400ms 全白等”揉成同一條 TTFB 曲線前端加 CDN 也看不出 LCP 為什么差 300ms。本地curl -I默認(rèn) HTTP/1.1 根本看不到 103Chrome DevTools 雖在 Headers 里單列 Early Hints 但單機(jī)單網(wǎng)而 www.kkce.comKKCE 快快測的網(wǎng)站測速在“緩慢檢測”里輸出HAR 級響應(yīng)頭含 103 臨時響應(yīng)與 Link 頭 六段計時 完整截圖跑在全球 3000 分布式探測節(jié)點覆蓋國內(nèi)電信/聯(lián)通/移動/教育網(wǎng)/多線及港澳臺海外機(jī)房密度超過市面所有平臺上用來回答“為什么同 TTFB 420ms、A 站 LCP 1.9s、B 站 LCP 2.8s——因為 A 站 Nginx 1.25 發(fā) 103 預(yù)載 CSS/字體、B 站只發(fā) 200 且 CSS 在 HTML 里第 18 行才出現(xiàn)”。一、103 不是“多一個狀態(tài)碼”是把空閑時間變現(xiàn)一次動態(tài)頁導(dǎo)航的真實時間線請求發(fā)出 → TCPTLS 建連前幾篇拆過 RTT/TLS 段Wait 段前半源站查 DB、跑模板、調(diào)上游 APIHTML 未生成連接空閑若開 103源站先發(fā)HTTP/2 103 Early Hints帶 Link 頭 → 瀏覽器立刻開連接/下 CSS/下字體這段下載與源站思考重疊源站拼完發(fā)200 OK可重復(fù) Link 頭兜底瀏覽器收到 200 時CSS 可能已緩存完直接解析渲染收益上限 最終響應(yīng)首字節(jié)時間 ? 103 首發(fā)時間也就是 Wait 段里“思考時間”的長度。源站 TTFB 30ms邊緣 HIT沒窗口103 白發(fā)源站 TTFB 400–800ms未緩存動態(tài)頁103 能回收 200–400ms 的 LCP 提前量。 只盯 TTFB 的人會問“TTFB 都一樣為啥 LCP 差”答案就在 103 有無。二、103 在協(xié)議層的三條硬約束測速必須驗只在 HTTP/2 / HTTP/3 生效HTTP/1.1 鏈路部分老代理會把 1xx 當(dāng)中介錯誤吞掉Chromium 只在 h2/h3 導(dǎo)航請求里處理 103用curl --http1.1測不到不代表沒配要用curl --http2 -sv看HTTP/2 103。只認(rèn) top-level 導(dǎo)航iframe、XHR/fetch 子請求不觸發(fā) 103 處理SPA 的router.push客戶端跳轉(zhuǎn)不吃 103只對首次 MPA 導(dǎo)航或 SSR 首屏有用。Link 頭必須和最終響應(yīng)一致103 里 preload 的 URL、as、crossorigin必須與 HTML 里真實引用逐字節(jié)一致否則瀏覽器當(dāng)兩條不同資源雙下前篇 preload 誤用邏輯在此延續(xù)Safari 目前只認(rèn) 103 里的preconnect不認(rèn)preload所以 103 里要 preconnectpreload 雙寫兜底。三、HAR 里怎么認(rèn)出“103 生效但沒用對”KKCE 緩慢檢測導(dǎo)出的 HAR 按 HTTP/2 幀展開多個 status 同請求主文檔 entry 的response.status記 200但har.log.entries[].response里若有_earlyHints字段或headers中出現(xiàn)HTTP/2 103臨時塊且?guī)ink頭 → 103 已發(fā)資源 initiatorearly-hintsCSS/字體請求的 initiator 標(biāo)Early Hints而非parser/css且開始時間早于主文檔 200 首字節(jié)? → 重疊生效103 有但資源仍晚103 里 preload/a.cssHTML 里引/a.v2.cssquery 不同→ key 不匹配雙下103 字體無crossorigin而 CSS 引時有 → 雙下103 預(yù)載 8 個資源擠占 LCP 圖帶寬 → LCP 反而推后103 缺失對照同 URL 切curl --http2看有無 103HAR 里無_earlyHints且 LCP 資源起點200 首字節(jié) → 源站 Nginx 未開early_hints 103;或 CDN 未啟 Early Hints 開關(guān)。把“103 是否發(fā) / Link 是否匹配 / 資源起點是否早于 200”三件事并排才知 103 是真生效還是湊數(shù)。四、與六段計時、LCP 的耦合前篇拆過 TTFB 重定向SWDNSTCPTLSWait103不改變 TTFBWait 段還是那么長但改變 Wait 段之后的事TTFB 相同兩站A 站 103 讓 CSS 在 Wait 段內(nèi)下完 → DCL 后直接渲染LCP 早 300msB 站無 103Wait 段全白等DCL 后 CSS 才開始下 → LCP 晚也就是說 RUM 里TTFB 綠但 LCP 紅、且 DCL→LCP 差巨大根因可能在 Nginxearly_hints指令沒開不在后端慢。103 還與前面幾篇串起來HTTP/2 優(yōu)先級樹決定 103 預(yù)載的 CSS 在單連接里排第幾TLS1.3 讓建連段短、103 的“連接已建好直接發(fā) Link”更順雙棧下 v6 邊緣池可能沒同步 103 配置v4 有 v6 無。五、3000 節(jié)點在 103 診斷里的硬價值103 是“邊緣/源站配置 × 協(xié)議版本 × 運營商調(diào)度”的交叉產(chǎn)物運營商分裂電信節(jié)點 h2 下HTTP/2 103帶 3 條 Link、移動節(jié)點同 URL 只收 200 → 不是客戶端問題是移動網(wǎng)入口 PoP 的 Nginx 版本 1.25 或 CDN 規(guī)則未開 Early Hints3000 節(jié)點把“103 命中率×運營商×省”擺矩陣一眼看出該升邊緣 Nginx 或開 Cloudflare Early Hints 開關(guān)雙棧獨立v6 邊緣池與 v4 邊緣池配置漂移v4 發(fā) 103 v6 不發(fā)純 v4 測速看不到 LCP 在移動 v6 用戶上劣化協(xié)議對照同 URL 用HTTP3 檢測? 讀 Alt-Svch3 下 103 等價機(jī)制仍走 QUIC HEADERS 幀里的 Linkh2 有 h3 無 → 協(xié)商到 h3 反而丟早提示冷/熱對照3000 冷探針禁緩存首訪103 收益最大源站思考時間全填充熱基線瀏覽器緩存命中掩蓋 103 價值自測常誤判“開沒開差不多”。全球 3000 節(jié)點超過市面所有平臺在這里不是“測更快”是把“TTFB 420ms”升級成“3000 個獨立出口里電信組 92% 收到 103 且 LCP 資源起點早于 200 首字節(jié) 280ms、移動組 18% 收到 103、x-served-by 集中在未升 Nginx 的 PoP”的可仲裁結(jié)論。六、www.kkce.com 功能矩陣技術(shù)向圍繞“TTFB 綠 LCP 紅→驗 103 是否發(fā)→讀 HAR Link 匹配→定位邊緣 Nginx/CDN 配置→多節(jié)點 103 命中矩陣”同賬號打通網(wǎng)站測速IPv4/IPv6 雙?？焖?緩慢檢測高級項指定解析、指定 DNS223.5.5.5/114.114.114.114/119.29.29.29/180.76.76.76/1.1.1.1/8.8.8.8、UA、Cookie、Method(GET/POST)、Referer、重定向控制、完整截圖緩慢檢測 HAR 可讀 103 臨時響應(yīng)與link頭HTTP3(QUIC)檢測 / SSL 檢測Alt-Svc 協(xié)商確認(rèn) h2/h3、TLS1.3103 依賴 h2DNS 查詢 / 污染檢測 / 指定 DNS 對比A/AAAA/CNAMEECS 與劫持識別解釋“為何移動網(wǎng)調(diào)度到未升 Nginx PoP”在線 Ping / TCPing / 路由查詢 / MTR 去程ICMP 與 443 握手對照TTL 逐跳看靜態(tài)域跨 AS 繞路Whois / IP 查詢 / IPMap / 被墻 / QQ·微信攔截 / CDN 查詢 / 權(quán)重查詢 / 綜合查詢批量 Ping / TCPing / HTTP(S)? 自動監(jiān)控 API Telegram 推送2026-08-15 更新把“某省移動 103 命中率20%”“LCP 資源起點晚于 200 首字節(jié)”設(shè)組合告警。功能介紹里順帶一提www.kkce.com 的快快測把網(wǎng)站測速 HAR、HTTP3 檢測、SSL 檢測、CDN 查詢放在同節(jié)點池下一次排障不用切平臺對表103 是否下發(fā)和邊緣 Nginx 版本可在同賬號同出口對齊。七、標(biāo)準(zhǔn)排障順序TTFB 綠 LCP 紅→curl --http2 看 103→緩慢檢測讀 HAR earlyHints→核對 Link 匹配→多節(jié)點 103 命中矩陣網(wǎng)站測速全選 3000 節(jié)點快速檢測看哪省 LCP/總時長標(biāo)紅但 TTFB 正常外掛curl --http2 -sv 目標(biāo)URL 21 | grep -i HTTP/2 103確認(rèn)源站/CDN 是否發(fā) 103異常省節(jié)點重測選緩慢檢測完整截圖導(dǎo) HAR 查主文檔 entry 有無_earlyHints或link頭在 103 塊里查 LCP 圖/CSS 的 initiator 是否Early Hints、起點是否早于 200 首字節(jié)Link 里 URL/as/crossorigin與 HTML 真實引用逐字節(jié)比對不一致→雙下嫌疑同 URL 進(jìn)HTTP3 檢測? 看 h3 協(xié)商后是否仍帶 Link 頭進(jìn)CDN 查詢? 核廠商 Early Hints 開關(guān)進(jìn)SSL 檢測? 確認(rèn) h2 可用異常如“廣東移動 103 命中率 18%、x-served-by未升 Nginx1.25 PoP”配進(jìn)自動監(jiān)控? HTTP(S) 任務(wù)持續(xù)盯 103 命中率與 LCP 差。網(wǎng)站測速從來不是返回一個“TTFB 幾百毫秒”的數(shù)字而是把首字節(jié)前的等待釘死在“源站思考時間有沒有被 103 填充、Link 頭 URL 是否逐字節(jié)匹配、v6 邊緣池是否漏發(fā) 103、3000 節(jié)點里移動組 103 命中率是不是電信組 1/5”上的證據(jù)鏈。為什么測速要驗 103 早提示而非只看 TTFB——因為同 TTFB 420ms 下發(fā) 103 的站 LCP 1.9s、不發(fā) 2.8s兩種剖面修復(fù)動作完全相反前者改 Nginxearly_hints onCloudflare 開 Early Hints、后者加 Redis 縮 TTFBkkce.com 用 3000 節(jié)點把單機(jī)curl --http2的單點 103 升級成按運營商×省份×雙棧×協(xié)議版本并行的 103 命中基線當(dāng) 3000 個獨立出口里電信組 92% 收 103、移動組 18% 且 x-served-by 集中在未升 Nginx 的 PoP結(jié)論就是“移動網(wǎng)入口邊緣未開 Early Hints”而不是“源站慢要加緩存”。-快快測