[{"data":1,"prerenderedAt":292},["ShallowReactive",2],{"blog-ttfb-diagnosis-steps":3,"blog-prev-ttfb-diagnosis-steps":118,"blog-next-ttfb-diagnosis-steps":201},{"id":4,"title":5,"author":6,"body":7,"canonical":102,"category":103,"cover":102,"date":104,"description":105,"draft":106,"extension":107,"keywords":102,"meta":108,"navigation":109,"noindex":106,"ogImage":102,"path":110,"seo":111,"seoDescription":102,"seoTitle":102,"stem":112,"tags":113,"updated":102,"__hash__":117},"blog\u002Fblog\u002Fttfb-diagnosis-steps.md","TTFB 超过 800 毫秒，先别急着换服务器","元析智能",{"type":8,"value":9,"toc":91},"minimark",[10,14,19,22,25,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76,79,82,85,88],[11,12,13],"p",{},"2026 年 6 月一个客户说 TTFB 到了 1.4 秒，要换服务器。我们让他先别换，拆开时间一看，后端处理只占 180 毫秒，剩下全是 DNS 和跨地域连接。换机器花钱，解决不了问题。",[15,16,18],"h2",{"id":17},"ttfb-由五段组成","TTFB 由五段组成",[11,20,21],{},"DNS 解析、TCP 连接、TLS 握手、请求排队、后端处理。这五段加起来才是 TTFB。",[11,23,24],{},"国内访问一个没做优化的站，DNS 可能 80 毫秒，TCP 加 TLS 又是 200 多毫秒，后端 300 毫秒，加起来就超过 600 了。",[11,26,27],{},"很多人只盯着后端，其实前三段在网络层，换服务器不一定能改善。",[15,29,30],{"id":30},"怎么把时间拆开",[11,32,33],{},"一条 curl 命令就够，加 -w 参数输出各阶段耗时，重点看 time_namelookup、time_connect、time_appconnect、time_starttransfer 四个值。",[11,35,36],{},"差值的含义很清楚：nameLookup 是 DNS，connect 减 nameLookup 是 TCP，appconnect 减 connect 是 TLS，starttransfer 减 appconnect 就是后端处理加首字节。",[11,38,39],{},"我们的习惯是同一个 URL 在不同城市测三次，取中位数。单次数据没意义，网络抖动太常见。",[15,41,42],{"id":42},"后端慢的三种情况",[11,44,45],{},"第一种，慢查询。列表页、搜索页、详情页，一个 SQL 没走索引就能把 TTFB 拖到一秒以上。",[11,47,48],{},"第二种，串行调用。服务端渲染时依次请求三个外部接口，每个 200 毫秒，加起来就是 600。",[11,50,51],{},"第三种，没缓存。每次请求都重新拼页面、重新查数据库，明明内容十分钟才变一次。",[15,53,54],{"id":54},"缓存能解决多少",[11,56,57],{},"页面缓存是最有效的，命中时 TTFB 能压到 50 毫秒以内。对象缓存次之，能省掉数据库查询。",[11,59,60],{},"但要看清缓存命中率。我们见过一个站配了 CDN 缓存，命中率只有 12%，因为缓存键里带了用户 ID，等于没缓存。",[15,62,63],{"id":63},"什么时候换服务器有用",[11,65,66],{},"三种情况：CPU 长期打满、单机磁盘 IO 成为瓶颈、用户和机房跨地域。",[11,68,69],{},"跨地域这条最容易被忽略。服务器在美西、用户在国内，TCP 和 TLS 的往返就有 300 毫秒起步，换更贵的机器也没用，得加节点或者用 CDN。",[15,71,72],{"id":72},"一次真实的拆段",[11,74,75],{},"2026 年 4 月我们给一个文档站拆 TTFB，总时长 1.2 秒：DNS 180 毫秒、TCP 220、TLS 260、后端 480。前三段加起来 660 毫秒，比后端还多。",[11,77,78],{},"换了 DNS 服务商、把 TLS 升到 1.3、加了一个国内节点之后，前三段降到 210 毫秒。后端一行代码没改，TTFB 变成 690 毫秒。",[11,80,81],{},"这件事的教训很直接：网络层和后端层要分开算账，不然会误以为要重写服务。",[15,83,84],{"id":84},"一个判断标准",[11,86,87],{},"TTFB 800 毫秒是我们的分界线。低于这个数，先把 LCP 里的图片和渲染问题解决；高于这个数，先拆时间，别急着动代码。",[11,89,90],{},"拆完你会发现，真正需要改代码的情况不到一半，大多数是网络路径和缓存策略的问题。这两件事改起来比重构便宜得多。",{"title":92,"searchDepth":93,"depth":93,"links":94},"",2,[95,96,97,98,99,100,101],{"id":17,"depth":93,"text":18},{"id":30,"depth":93,"text":30},{"id":42,"depth":93,"text":42},{"id":54,"depth":93,"text":54},{"id":63,"depth":93,"text":63},{"id":72,"depth":93,"text":72},{"id":84,"depth":93,"text":84},null,"技术SEO","2026-05-14","TTFB 由五段组成，换服务器只解决其中一段。这篇写怎么用 curl 把五段时间拆开、后端慢的三种典型情况，以及什么情况下换机器才有用。",false,"md",{},true,"\u002Fblog\u002Fttfb-diagnosis-steps",{"title":5,"description":105},"blog\u002Fttfb-diagnosis-steps",[114,115,116],"TTFB","服务器","页面体验","-mW0Tyot_vRvlXA9tFYpYcDh2gcp50w8k5XAdKCuP8o",{"id":119,"title":120,"author":6,"body":121,"canonical":102,"category":103,"cover":102,"date":190,"description":191,"draft":106,"extension":107,"keywords":102,"meta":192,"navigation":109,"noindex":106,"ogImage":102,"path":193,"seo":194,"seoDescription":102,"seoTitle":102,"stem":195,"tags":196,"updated":102,"__hash__":200},"blog\u002Fblog\u002Finternal-link-depth-four.md","内链深度超过四层，产品页基本抓不到",{"type":8,"value":122,"toc":181},[123,126,129,132,136,139,142,145,148,151,154,157,160,163,166,169,172,175,178],[11,124,125],{},"点击深度超过 4 层，抓取频次下降很明显；超过 6 层，基本只能靠 sitemap 兜底。这不是理论，是我们从 6 个客户站的日志里统计出来的。",[15,127,128],{"id":128},"深度和抓取的关系",[11,130,131],{},"把日志里的 URL 按路径层级分组，算日均抓取次数，6 个站的曲线形状都差不多：1 到 2 层是基准，3 到 4 层降到六成，5 到 6 层只剩两成，7 层以上约百分之五。不同站的绝对值差很多，但拐点都在 4 层附近。",[15,133,135],{"id":134},"_2025-年-12-月那个文档站","2025 年 12 月那个文档站",[11,137,138],{},"3000 个页面，功能文档的路径是 \u002Fdocs\u002F产品\u002F模块\u002Fv2\u002F指南\u002F页面，五层。点击深度平均 5.2 层，深层页面收录率 34%。",[11,140,141],{},"改了三处：版本号从路径里拿掉，版本切换做成页面内的选项；补了模块归档页；侧边栏加\"本模块全部文档\"的链接。深度压到 2.8 层，两个月后收录率 71%，长尾词进前 10 的多了 180 个。",[11,143,144],{},"内容一个字没改，纯结构调整。",[15,146,147],{"id":147},"怎么查",[11,149,150],{},"Screaming Frog 的 Crawl Depth 报告直接给每个页面的点击深度。日志可以按路径层级和请求量做交叉表。GSC 里按目录看收录率，哪个目录的收录率明显低，往往就是深度问题。",[15,152,153],{"id":153},"内链该加在哪",[11,155,156],{},"优先级：主导航和侧边栏 > 面包屑 > 相关文章\u002F相关文档（每篇 3 到 5 条）> 正文内链（每 500 字 1 到 2 条）。主导航的一条链接，权重抵得上正文里十条。",[15,158,159],{"id":159},"两个注意",[11,161,162],{},"别为压深度硬塞链接。相关性差的链接会稀释页面主题，蜘蛛也会降低对链接的信任。一个页面的内链超过 100 条，单条能传递的权重就很小了，还不如拆成两页。",[11,164,165],{},"还有，内链要跟着用户路径走。用户从文档点进产品页、从博客点进方案页，这种链接蜘蛛认，用户也真的会用。为了 SEO 硬造的\"相关阅读\"列表，长期看没什么价值。",[15,167,168],{"id":168},"一个反例",[11,170,171],{},"有个客户听说内链重要，在每篇文章底部塞了 30 条\"相关阅读\"，全是自动生成的同目录文章。结果这些链接互相指向，形成了一个内部小循环，蜘蛛在里面绕来绕去，反而更少去产品页。这是典型的\"内链数量上去了，结构更差了\"。",[11,173,174],{},"我们也遇到过另一种情况：客户把 200 个产品页全部放在首页导航里，点击深度都是 1 层，但首页只有 3 个产品卖得动。深度浅不等于布局合理，还要看用户会不会点。",[15,176,177],{"id":177},"立场",[11,179,180],{},"结构问题优先于内容数量。同样是写 100 篇文章，挂在一个深目录里，效果可能只有挂在浅目录、有归档页的一半。先修结构，再堆内容。",{"title":92,"searchDepth":93,"depth":93,"links":182},[183,184,185,186,187,188,189],{"id":128,"depth":93,"text":128},{"id":134,"depth":93,"text":135},{"id":147,"depth":93,"text":147},{"id":153,"depth":93,"text":153},{"id":159,"depth":93,"text":159},{"id":168,"depth":93,"text":168},{"id":177,"depth":93,"text":177},"2026-05-13","我们从 6 个站的日志里统计出点击深度和抓取频次的关系，4 层是分水岭。这篇讲怎么查深度、怎么用内链把重要页面拉浅，附一个文档站把深度从 5.2 压到 2.8 的改造数据。",{},"\u002Fblog\u002Finternal-link-depth-four",{"title":120,"description":191},"blog\u002Finternal-link-depth-four",[197,198,199],"内链","站点结构","抓取","aeSWyhDLtUWvn5-6Sxub98xpbt2DjW3txEEpkwwh4no",{"id":202,"title":203,"author":6,"body":204,"canonical":102,"category":280,"cover":102,"date":281,"description":282,"draft":106,"extension":107,"keywords":102,"meta":283,"navigation":109,"noindex":106,"ogImage":102,"path":284,"seo":285,"seoDescription":102,"seoTitle":102,"stem":286,"tags":287,"updated":102,"__hash__":291},"blog\u002Fblog\u002Fkeyword-cannibalization.md","关键词蚕食：两个页面抢同一个词，怎么判断、怎么处理",{"type":8,"value":205,"toc":272},[206,209,212,215,218,221,224,227,230,233,236,239,242,245,248,251,254,257,260,263,266,269],[11,207,208],{},"站内两个页面抢同一个词，表现是排名来回跳、流量没涨。我们查过 18 个站，平均每个站有 6 组蚕食。判断方法不复杂，麻烦的是处理。",[15,210,211],{"id":211},"怎么判断是不是蚕食",[11,213,214],{},"三个信号。第一，同一个词在排名监测里出现两个 URL，交替上榜。第二，两个页面的目标词高度重合，内容主题也重合。第三，两个页面互相内链，或者都被同一个栏目页链着。",[11,216,217],{},"我们的做法是把 GSC 里同一个查询对应的所有 URL 拉出来，按曝光排序，看前两名是不是都在自己站内。",[11,219,220],{},"一个客户搜\"项目管理工具\"时，首页和一篇博客同时出现在前 20，交替上下，三个月都是这样。",[15,222,223],{"id":223},"三种处理方式",[11,225,226],{},"第一种，合并。两个页面主题高度重合，把内容并到一个页面，另一个 301 过去。最彻底，也最常用。",[11,228,229],{},"第二种，分工。两个页面面向不同意图，把目标词拆开：一个主打\"是什么\"，一个主打\"怎么选\"，内链互相指向，各自做自己的词。",[11,231,232],{},"第三种，降权。把次要页面从导航和内链里拿掉，或者 noindex，让它退出竞争。适合那个页面本来就没价值的情况。",[15,234,235],{"id":235},"一个常被误判的情况",[11,237,238],{},"不是所有\"两个页面都有排名\"都是蚕食。如果一个页面排第 5、另一个排第 40，那不叫蚕食，叫正常的长尾覆盖。",[11,240,241],{},"真正的蚕食是：两个页面都排在前 20，而且排名交替。处理之前先确认这一点，别把正常的长尾结构改坏。",[15,243,244],{"id":244},"一次处理后的数据",[11,246,247],{},"2026 年 2 月，一个做数据平台的客户，产品页和博客页抢\"数据仓库选型\"这个词。产品页排 11，博客排 14，交替了两个月。",[11,249,250],{},"我们判断博客页的内容更深、外链更多，决定合并：把博客里的选型标准并进产品页，博客 301 到产品页。",[11,252,253],{},"第 3 周产品页排到第 6，第 6 周第 4。流量涨了 2.1 倍，因为原来两个页面分着的点击，现在集中到一个。",[15,255,256],{"id":256},"处理时的两个注意",[11,258,259],{},"第一，合并前看外链。两个页面都有外链的，要保留外链多的那个 URL，或者做 301 把权重接住。",[11,261,262],{},"第二，合并后别马上改内链。观察两周，确认新页面的排名稳定，再统一改内链。",[15,264,265],{"id":265},"一句判断",[11,267,268],{},"蚕食是内容增长到一定阶段的必然问题，不是错误。定期查、及时处理，比一次查完更重要。我们已经把这项检查固定进了每季度的内容复盘。",[11,270,271],{},"我们现在的做法是每季度查一次，把蚕食当成内容维护的常规项。",{"title":92,"searchDepth":93,"depth":93,"links":273},[274,275,276,277,278,279],{"id":211,"depth":93,"text":211},{"id":223,"depth":93,"text":223},{"id":235,"depth":93,"text":235},{"id":244,"depth":93,"text":244},{"id":256,"depth":93,"text":256},{"id":265,"depth":93,"text":265},"SEO","2026-05-15","站内两个页面抢同一个词，表现是排名来回跳、流量没涨。我们查过 18 个站，平均每个站有 6 组蚕食。判断方法、三种处理方式和一次处理后的数据都在这篇，也附了一个常被误判的情况，照着查能少走弯路。",{},"\u002Fblog\u002Fkeyword-cannibalization",{"title":203,"description":282},"blog\u002Fkeyword-cannibalization",[288,289,290],"关键词蚕食","站内竞争","内容结构","UsIUvZReVSeEhio_77pnEcwSgA51bzcJ4tgZPWmsTgk",1794088105980]