[{"data":1,"prerenderedAt":272},["ShallowReactive",2],{"blog-ssr-vs-static-ttfb":3,"blog-prev-ssr-vs-static-ttfb":90,"blog-next-ssr-vs-static-ttfb":167},{"id":4,"title":5,"author":6,"body":7,"canonical":74,"category":75,"cover":74,"date":76,"description":77,"draft":78,"extension":79,"keywords":74,"meta":80,"navigation":81,"noindex":78,"ogImage":74,"path":82,"seo":83,"seoDescription":74,"seoTitle":74,"stem":84,"tags":85,"updated":74,"__hash__":89},"blog\u002Fblog\u002Fssr-vs-static-ttfb.md","SSR 和静态生成哪个 TTFB 更低，我们测了三类软件站","元析智能",{"type":8,"value":9,"toc":65},"minimark",[10,14,18,21,24,27,31,34,37,40,43,46,50,53,56,59,62],[11,12,13],"p",{},"同一个页面，静态生成的 TTFB 是 90 毫秒，SSR 是 480 毫秒，纯客户端渲染的首字节只要 120 毫秒但 LCP 会差一截。这是我们在三类软件站上测出来的结果，测试时间是去年 10 月到 12 月。结论是内容页静态化，个性化部分交给客户端。",[15,16,17],"h2",{"id":17},"测的三类站",[11,19,20],{},"文档站：内容按版本发布，天然适合静态生成。我们把一个 800 页的文档站从 SSR 改成静态生成加 CDN，TTFB P75 从 610 毫秒降到 95 毫秒，服务器成本降了四成。",[11,22,23],{},"营销站：一周改两次，用增量静态再生成就够。首页原来每次请求都走 Node 服务，改成静态加 10 分钟缓存，TTFB 从 540 到 130 毫秒。",[11,25,26],{},"后台控制台：登录后才能看，SSR 没法省。这类页面我们没动渲染方式，只在服务端做了接口并行和数据预取。",[15,28,30],{"id":29},"为什么-ssr-慢","为什么 SSR 慢",[11,32,33],{},"三个原因：每个请求都要跑一遍框架渲染、接口调用在服务端串行、没有缓存层。第一项省不掉，后两项能改。",[11,35,36],{},"一个客户做了接口并行加 60 秒数据缓存，SSR 的 TTFB 从 700 毫秒降到 280 毫秒。这个投入产出比挺高，比换框架现实得多。",[15,38,39],{"id":39},"静态化的边界",[11,41,42],{},"静态化不是万能的，两个前提：内容不因人而异、更新可以延迟。定价页如果按地区显示不同价格就得小心；用户中心如果静态化，页面会串号。",[11,44,45],{},"我们的做法是\"壳静态加数据客户端\"：HTML 里只有布局和文案，个性化数据用接口补。代价是首屏数据晚一点到，对内容页来说无所谓。",[15,47,49],{"id":48},"cdn-命中率才是分水岭","CDN 命中率才是分水岭",[11,51,52],{},"静态生成只是第一步，页面能不能落到离用户最近的节点，取决于缓存命中率。同样两个用静态生成的站，命中率 95% 的 TTFB 是 90 毫秒，命中率 40% 的 TTFB 是 380 毫秒，差别比 SSR 到静态生成这一步还大。",[11,54,55],{},"所以我们改静态生成的时候，会同时把 CDN 的规则和预热一起做。不预热的话，发布后第一批用户仍然要走回源，那几分钟的 TTFB 和没改一样。",[15,57,58],{"id":58},"一条判断清单",[11,60,61],{},"内容页（文档、博客、案例、术语表）走静态生成。营销页（首页、功能、定价）走静态加短缓存。后台和工具走 SSR，重点优化接口。这条线我们用了两年，没出过大问题。",[11,63,64],{},"给文档站上 SSR 还配不好缓存的，我见过好几个。这是纯粹的资源浪费，也是 TTFB 优化最常见的弯路。文档站的核心诉求是\"任何地方都快手可及\"，静态页面加 CDN 就是答案，不需要更复杂的东西。",{"title":66,"searchDepth":67,"depth":67,"links":68},"",2,[69,70,71,72,73],{"id":17,"depth":67,"text":17},{"id":29,"depth":67,"text":30},{"id":39,"depth":67,"text":39},{"id":48,"depth":67,"text":49},{"id":58,"depth":67,"text":58},null,"技术SEO","2026-01-10","同一页面，静态生成 TTFB 90 毫秒、SSR 480 毫秒、纯客户端渲染首字节 120 毫秒但 LCP 差一截。文档站、营销站、后台各该用哪种，附一条判断清单。",false,"md",{},true,"\u002Fblog\u002Fssr-vs-static-ttfb",{"title":5,"description":77},"blog\u002Fssr-vs-static-ttfb",[86,87,88],"SSR","静态生成","TTFB","rhoGNDUQNAoHPLWDPoeHWXaKgDQLPxE3XKD-wfEQMVA",{"id":91,"title":92,"author":6,"body":93,"canonical":74,"category":75,"cover":74,"date":156,"description":157,"draft":78,"extension":79,"keywords":74,"meta":158,"navigation":81,"noindex":78,"ogImage":74,"path":159,"seo":160,"seoDescription":74,"seoTitle":74,"stem":161,"tags":162,"updated":74,"__hash__":166},"blog\u002Fblog\u002Fstructured-data-tool-errors.md","结构化数据检测报的错，一半不用改",{"type":8,"value":94,"toc":149},[95,98,101,104,107,110,113,116,119,122,125,128,131,134,137,140,143,146],[11,96,97],{},"2026 年 1 月我们给一个 SaaS 站跑结构化数据检测，340 条报错，逐条看完真正需要动手的只有 27 条。剩下的是插件自动注入的标记、已经不展示的类型，以及工具之间的口径差异。把 340 条全修一遍，两周就没了。",[15,99,100],{"id":100},"报错分三类",[11,102,103],{},"第一类是致命错误，必填字段缺失。Article 缺 headline、Product 缺 offers、Breadcrumb 的 item 顺序错了，这类会影响富媒体展示，必须修。",[11,105,106],{},"第二类是警告，建议字段缺失。比如 Article 没写 author、Organization 没写 logo。这类不影响展示，有精力再补。",[11,108,109],{},"第三类跟你的页面没关系。很多 CMS 和营销插件会自动注入 Organization、WebSite 标记，字段填得一塌糊涂，检测工具照样报错。这类要么去插件设置里关掉，要么忽略，别手动改模板。",[15,111,112],{"id":112},"两个工具为什么结论不同",[11,114,115],{},"Rich Results Test 测的是你输入的那个 URL 的当前快照，Schema Markup Validator 测的是标记语法本身，GSC 的增强报告看的是线上抓取到的版本。三个来源的时间点不一样，GSC 的报告通常滞后 3 到 7 天。",[11,117,118],{},"我遇到过一个页面上线当天测全部通过，一周后 GSC 报错误，原因是部署时模板回滚了。所以别用测试工具的结果当最终结论，以 GSC 为准。",[15,120,121],{"id":121},"我们只修哪些",[11,123,124],{},"影响富媒体展示的优先修：Article、Breadcrumb、Product、SoftwareApplication、Video。这些能在搜索结果里多占一行，或者让实体更明确。",[11,126,127],{},"已经不展示的类型不用管。FAQ 类富媒体结果在 2023 年 8 月被收缩到少数站点，很多站还在拼命补 FAQ 标记，白费功夫。HowTo 也类似。",[11,129,130],{},"还有一类值得做但不叫修错误：给软件产品页加 SoftwareApplication 标记，写清楚名称、操作系统、价格区间。它不一定带来富媒体，但能让搜索引擎和 AI 搜索更清楚你是什么产品。",[15,132,133],{"id":133},"修的顺序",[11,135,136],{},"先看 GSC 增强报告里错误级别的类型分布，按影响页面数从多到少排。每类先修 5 个页面，等一周看报告有没有变化，确认修对了再全量。",[15,138,139],{"id":139},"两个容易漏的检查",[11,141,142],{},"第一个是 URL 的写法。Schema 里的 item、@id、breadcrumb 的 item 都要用绝对地址，写成相对路径时检测工具不一定报错，但解析会出问题。我们抽查时会专门搜一遍有没有 href=“\u002F” 这种写法。",[11,144,145],{},"第二个是标记和页面内容要一致。价格改了但标记没同步，搜索结果里显示的价格和落地页差一倍，用户点进来就觉得被骗。每次改价、改套餐名，顺手检查一下标记。",[11,147,148],{},"我自己踩过的坑是一次性改了 800 个页面的模板，改错了一个字段名，等 GSC 报出来已经过了十天。批量改之前一定先用 5 个页面验证，这个习惯省钱省时间。",{"title":66,"searchDepth":67,"depth":67,"links":150},[151,152,153,154,155],{"id":100,"depth":67,"text":100},{"id":112,"depth":67,"text":112},{"id":121,"depth":67,"text":121},{"id":133,"depth":67,"text":133},{"id":139,"depth":67,"text":139},"2026-01-08","一个站 340 条标记报错，真正影响展示的只有 27 条。这篇写三类报错怎么区分、两个检测工具为什么结论不同，以及我们按什么顺序修。",{},"\u002Fblog\u002Fstructured-data-tool-errors",{"title":92,"description":157},"blog\u002Fstructured-data-tool-errors",[163,164,165],"结构化数据","Schema","富媒体结果","glBBuEiVB6mx8ppzB86A74wJSWo6k6nZXjUFRKyPBYA",{"id":168,"title":169,"author":6,"body":170,"canonical":74,"category":260,"cover":74,"date":261,"description":262,"draft":78,"extension":79,"keywords":74,"meta":263,"navigation":81,"noindex":78,"ogImage":74,"path":264,"seo":265,"seoDescription":74,"seoTitle":74,"stem":266,"tags":267,"updated":74,"__hash__":271},"blog\u002Fblog\u002Feeat-software-proof.md","软件公司的 E-E-A-T 靠三样东西证明，不靠头衔",{"type":8,"value":171,"toc":250},[172,175,179,182,185,189,192,195,199,202,205,208,211,214,217,220,223,226,229,232,235,238,241,244,247],[11,173,174],{},"E-E-A-T 是一套评估框架，不是能直接优化的打分项。软件公司想做这件事，落点只有三样：写的人是谁、文章里有没有一手内容、外部有没有人提你。三样都没有，作者简介写八百字也没用。",[15,176,178],{"id":177},"第一样作者是谁要可核对","第一样：作者是谁，要可核对",[11,180,181],{},"作者页别只放头像和“资深专家”。写清楚：在这个行业几年、做过什么产品、在哪能查到。GitHub、知乎、掘金、行业会议都算。",[11,183,184],{},"我们 2025 年 9 月给一个客户加了 3 个作者页，每位作者写清负责过的模块和写过的文章列表。三个月后品牌词搜索量涨了 26%，询盘里提到“看了你们写的那篇”的多了起来。",[15,186,188],{"id":187},"第二样文章里的一手内容","第二样：文章里的一手内容",[11,190,191],{},"一手内容指的是别人没有的：你们自己的实测数据、内部截图、版本号、上线时间、踩坑记录。",[11,193,194],{},"判断方法很直接：这段话换个公司名字还成立吗。成立，说明不是一手内容。",[15,196,198],{"id":197},"第三样外部有人提你","第三样：外部有人提你",[11,200,201],{},"第三方提到你的地方：开源仓库、技术社区讨论、行业媒体、评测站、播客。这类提及比自家内容更能说明“这个公司确实在做这件事”。",[11,203,204],{},"不用追求被大媒体报道，先在 GitHub 和知乎上有稳定存在，比一次性的曝光有用。",[15,206,207],{"id":207},"我们每篇文末固定三段",[11,209,210],{},"作者和写作背景；更新说明，写清楚改了什么；参考来源，列内部文档和公开资料。",[11,212,213],{},"三段加起来不到 150 字，但读者和引擎都能看出这篇有人负责。",[15,215,216],{"id":216},"一个反例",[11,218,219],{},"有个客户买了几个“行业专家”的署名，作者页写了三行履历，查不到任何对应信息。文章内容还是 AI 拼的。半年过去，那批文章的收录和排名都没有起色。",[11,221,222],{},"头衔可以买，经历买不了。",[15,224,225],{"id":225},"一个常见误解",[11,227,228],{},"E-E-A-T 不是给搜索引擎看的标签。它是结果：你确实有经验，于是写出来的东西带着细节，别人愿意引用，搜索引擎才据此判断。",[15,230,231],{"id":231},"作者页之外的两个小位置",[11,233,234],{},"文章列表页显示作者名，点击能到作者页。这个链路很多站是断的：列表只有标题和日期，作者名藏在详情页最下面。",[11,236,237],{},"更新时间也要露出来。我们 2025 年改过一个客户的模板，在标题下加一行“2025 年 11 月更新”，同样的内容，两个月里点击率涨了 0.6 个百分点。",[15,239,240],{"id":240},"别把这件事做成一次性的",[11,242,243],{},"作者页会过期。人离职、职责变了、产品线没了，作者页还挂着三年前的介绍，反而扣分。",[11,245,246],{},"我们建议每季度核对一遍：作者还在不在、写的方向还对不对、引用链接有没有失效。",[11,248,249],{},"所以顺序是：先做事，再写；不是先写标签，再补内容。",{"title":66,"searchDepth":67,"depth":67,"links":251},[252,253,254,255,256,257,258,259],{"id":177,"depth":67,"text":178},{"id":187,"depth":67,"text":188},{"id":197,"depth":67,"text":198},{"id":207,"depth":67,"text":207},{"id":216,"depth":67,"text":216},{"id":225,"depth":67,"text":225},{"id":231,"depth":67,"text":231},{"id":240,"depth":67,"text":240},"SEO","2026-01-11","作者简介写得再漂亮，正文没有可核对的东西，E-E-A-T 就是空的。我们把落地拆成三件事：作者是谁、文章里有一手内容、外部有人提你。",{},"\u002Fblog\u002Feeat-software-proof",{"title":169,"description":262},"blog\u002Feeat-software-proof",[268,269,270],"E-E-A-T","内容质量","作者页","oMw4dv22_aKKxBR08KS-LMfuLZExFbNVK6zz0wXAfws",1794088109341]