頁面打開慢，很多人的第一反應是内容太長、图片太大，却很少先看一眼服務器给出的第一個回應有多慢。首字节時間（TTFB，Time To First Byte）指的是從發起請求到收到第一個字节之間的耗时，它包含了 DNS 解析、连接建立、服務器處理、後端渲染等环节。它不直接决定頁面能不能被抓取，但會明顯影响訪問体驗，也會影响蜘蛛在一段時間内能走完多少頁面。
先搞清楚自己在测什么
同一個地址，在不同的條件下测出来的數字可能差好几倍。所以在動手優化之前，先確認這几種情况有没有被混在一起：
- 静態文件直接返回，還是经過後端程序渲染；
- 命中了缓存，還是每次都要回源重算；
- 走没走 CDN，請求落到了哪個节点；
- 測試机與服務器之間的網絡距离；
- 是首頁、栏目頁、内容頁，還是带查询參數的列表頁。
把這几個變量分開记錄，後面的判断才有依據。
一份可执行的自查清單
- 用命令行工具或浏览器開發者工具的計时面板，把 DNS、连接、等待、下载几段耗时分別看一遍，別只记住一個總數。
- 在未登入、清過本地缓存的狀態下再测一次，避免被浏览器缓存誤導。
- 按模板分類测：首頁、栏目列表頁、内容詳情頁、站内搜尋頁各取几個样本，看是不是只有某一類明顯偏慢。
- 留意有没有出現等待超過两三秒的頁面，這類頁面優先處理。
- 查看服務器基础资源：CPU、内存、磁盘讀寫、並發连接數，確認不是整体吃紧。
- 检查資料库慢查询日誌和外部接口調用，很多慢頁面卡在這里。
- 確認後端渲染過程中有没有同步等待第三方服務，比如統計、推荐、评论拉取。
- 核對缓存策略與 CDN 回源規則，看缓存是否按预期生效、過期時間是否合理。
- 检查是否加载了用不到的模块、插件，日誌級別是否開得過高。
- 连續几天在相近時間段采样，只看一次資料容易得出错誤结论。
常见的三類拖慢原因
後端處理慢
資料库缺少合适索引、查询寫得過重、模板里嵌套循环取數，都會让等待時間變長。這類問题往往集中出現在某几個模板上，按模板分類對比就能較快定位。
網絡與鏈路問题
服務器带宽被打满、跨境线路抖動、DNS 解析慢，都會体現在连接阶段。如果同類頁面在不同地区表現差异很大，基本可以往這個方向查。
缓存没有生效
規則寫错、參數變化導致缓存键不一致、更新後没有预热，都會让本该命中缓存的請求回源。可以先用同一地址连續請求几次，看响應時間是否稳定下降。
首字节時間是一個体检指标，不是開關。把它控制在合理区間、保持稳定就够了，不必為了追求极限數字反复折腾配置。
處理顺序與驗證
建议先動影响面大的部分，比如缓存策略、明顯的慢查询、不必要的同步外部調用；再做逐個模板的细調。每改一項，就在同一位置、同一時間段复测一次，並把改動内容和前後資料记在一起。這样出了問题能回退，也能看清哪一步真正起了作用。
把观察固定下来
速度問题多半是慢慢累积出来的，與其等用戶反馈才排查，不如每周固定時間抓一组样本：几個主要模板的首字节時間、服務器负载、缓存命中情况。資料不用很复杂，能看出趋势就行。当某天數字突然變差，你至少知道它之前是什么样子。