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