[{"data":1,"prerenderedAt":367},["ShallowReactive",2],{"blog-lcp-optimization-retrospective":3,"blog-prev-lcp-optimization-retrospective":129,"blog-next-lcp-optimization-retrospective":212},{"id":4,"title":5,"author":6,"body":7,"canonical":113,"category":114,"cover":113,"date":115,"description":116,"draft":117,"extension":118,"keywords":113,"meta":119,"navigation":120,"noindex":117,"ogImage":113,"path":121,"seo":122,"seoDescription":113,"seoTitle":113,"stem":123,"tags":124,"updated":113,"__hash__":128},"blog\u002Fblog\u002Flcp-optimization-retrospective.md","官网首屏提速复盘：从四点六秒到一点九秒我们改了什么","元析智能",{"type":8,"value":9,"toc":101},"minimark",[10,14,17,22,25,28,32,35,39,51,55,58,62,69,73,80,83,86,89,92,95,98],[11,12,13],"p",{},"今年 8 月我们接手一个 SaaS 官网的性能整改，移动端 LCP 4.6 秒，六周后稳定在 1.9 秒。中间没有换服务器，也没有重写前端。六件事按性价比排下来，顺序比技术选择更重要。",[11,15,16],{},"这个站的情况挺典型：Next.js 做的营销站，首屏传输 2.8MB，42 个请求，第三方脚本 9 个。老板的原话是\"我们的页面怎么这么慢\"，但没人知道慢在哪。我们先跑了一轮真实的移动端测试，不是本地开 DevTools 看，而是用 4G 模拟加 CPU 4 倍降速。",[18,19,21],"h2",{"id":20},"第一件首屏传输从-28mb-压到-740kb","第一件：首屏传输从 2.8MB 压到 740KB",[11,23,24],{},"图片占 1.6MB。hero 图、六张客户 logo、一张 dashboard 截图，全是 PNG。换成 WebP，按容器尺寸出 2 倍图，logo 改 SVG。这一步单独把 LCP 从 4.6 秒带到 3.2 秒。",[11,26,27],{},"顺带一个细节：他们 logo 墙用了六张 400×400 的 PNG，实际渲染 32×32。这种浪费在软件站特别多，客户 logo 是市场部从 PPT 里导出来直接上传的。",[18,29,31],{"id":30},"第二件砍掉三个阻塞渲染的请求","第二件：砍掉三个阻塞渲染的请求",[11,33,34],{},"头部有一个字体 CSS、一个图标库 CSS、一个没用上的组件库样式，合计 210KB，全是同步加载。字体改自托管加 preload，图标库换成内联 SVG 只留用到的 14 个，组件库样式按需引入。LCP 到 2.7 秒。",[18,36,38],{"id":37},"第三件中文字体换子集","第三件：中文字体换子集",[11,40,41,42,46,47,50],{},"他们的中文主字体是 3.4MB 的思源黑体全量包，",[43,44,45],"code",{},"font-display"," 没设。改成常用 3500 字的子集，280KB，",[43,48,49],{},"font-display: swap","。中文软件站这一步几乎必做，代价小，收益稳定。",[18,52,54],{"id":53},"第四件第三方脚本全部延后","第四件：第三方脚本全部延后",[11,56,57],{},"9 个第三方里，客服组件、两个统计、一个 AB 测试、一个热力图，首屏一个都不需要。改成用户首次交互后再加载，首屏请求从 42 降到 19。LCP 到 2.1 秒。",[18,59,61],{"id":60},"第五件给首屏图提优先级","第五件：给首屏图提优先级",[11,63,64,65,68],{},"hero 图加 ",[43,66,67],{},"fetchpriority=\"high\"","，同时在 head 里 preload。这一步单独看收益最小，但在 2.1 秒的基数上，它挤出了最后的 0.2 秒。",[18,70,72],{"id":71},"第六件html-走边缘缓存","第六件：HTML 走边缘缓存",[11,74,75,76,79],{},"营销页内容一周改一次，没必要每次回源。在 CDN 上给首页和定价页设了 10 分钟缓存加 ",[43,77,78],{},"stale-while-revalidate","，TTFB 从 620 毫秒降到 140 毫秒。",[18,81,82],{"id":82},"顺序比技术重要",[11,84,85],{},"六件事如果倒过来做，先上 CDN 再优化图片，效果要差一半。我们判断顺序的标准很土：这一步能不能减少字节或者减少阻塞，能就优先。优先级调整和缓存策略属于锦上添花，放在最后。",[11,87,88],{},"还有个反常识的点：这个站做完 PSI 分数从 31 到 88，但自然流量第三周才开始动，第六周涨了 23%。速度是必要条件，不是充分条件，别指望改完性能排名第二天就往上走。",[18,90,91],{"id":91},"过程中踩的三个坑",[11,93,94],{},"第一个坑是 preload 加重复了。前端在 head 里加了 preload，组件里又自己加载一次，同一张图下载两遍，移动端多花了 400 毫秒。排查方法是在网络面板里按文件大小排序，看到同一 URL 出现两次就明白了。",[11,96,97],{},"第二个坑是缓存把改动盖住了。图片换完，CDN 上还是旧版本，测了两天都是 4.1 秒，差点以为方向错了。现在我们的规矩是每次改静态资源都带版本号或者刷新缓存。",[11,99,100],{},"第三个坑是只测了首页。首页做到 1.9 秒，客户很满意，结果产品页、文档页还在 5 秒以上。营销站真正的入口是产品页和文档，首页只占访问量的三成。这批页面后来单独做了一轮，又多花了两周。",{"title":102,"searchDepth":103,"depth":103,"links":104},"",2,[105,106,107,108,109,110,111,112],{"id":20,"depth":103,"text":21},{"id":30,"depth":103,"text":31},{"id":37,"depth":103,"text":38},{"id":53,"depth":103,"text":54},{"id":60,"depth":103,"text":61},{"id":71,"depth":103,"text":72},{"id":82,"depth":103,"text":82},{"id":91,"depth":103,"text":91},null,"技术SEO","2025-09-14","一个 Next.js 营销站移动端 LCP 4.6 秒，六周做到 1.9 秒，没换服务器没重写前端。六件事按性价比排序：图片、阻塞请求、字体子集、第三方脚本、首图优先级、边缘缓存。",false,"md",{},true,"\u002Fblog\u002Flcp-optimization-retrospective",{"title":5,"description":116},"blog\u002Flcp-optimization-retrospective",[125,126,127],"LCP","性能复盘","移动端速度","gYDspv4w527tyyC7CnRBp8IUP7YrQDImAmaZXjafsgY",{"id":130,"title":131,"author":6,"body":132,"canonical":113,"category":114,"cover":113,"date":201,"description":202,"draft":117,"extension":118,"keywords":113,"meta":203,"navigation":120,"noindex":117,"ogImage":113,"path":204,"seo":205,"seoDescription":113,"seoTitle":113,"stem":206,"tags":207,"updated":113,"__hash__":211},"blog\u002Fblog\u002Fcrawler-discovery-to-index.md","爬虫从发现到入库走四步，卡在哪一步决定怎么修",{"type":8,"value":133,"toc":196},[134,137,140,147,153,159,165,168,171,178,181,184,187,190,193],[11,135,136],{},"结论放在前面：一个页面没被收录，原因只可能落在四步里——发现 URL、抓取成功、渲染出内容、通过索引判定。我们排查从来不从\"内容质量\"开始，而是倒着走：先看索引报告给了什么理由，再看抓取和渲染，最后才怀疑内容。",[18,138,139],{"id":139},"四步各自会断在哪",[11,141,142,146],{},[143,144,145],"strong",{},"第一步，发现。"," 蜘蛛得先知道 URL 存在，靠内链、sitemap、外链三条路。孤岛页、只出现在筛选结果里的产品页、藏在第 5 页之后的分页，常常连\"被发现\"都没做到。",[11,148,149,152],{},[143,150,151],{},"第二步，抓取。"," 知道地址不等于能抓到。robots.txt 规则、服务器 5xx、CDN 拦截、抓取频次过低，都会让请求进不来。判断方法很朴素：看日志里这个路径有没有被请求过。",[11,154,155,158],{},[143,156,157],{},"第三步，渲染。"," 请求成功了，返回的 HTML 里却没有正文——React、Vue 做的产品页和文档站最常见。初始 HTML 只有一个空挂载点，正文全靠 JS 填。",[11,160,161,164],{},[143,162,163],{},"第四步，索引。"," 抓到了、渲染了，还可能因为 canonical 指向别处、页面被标 noindex、内容和别的页重复、整体质量不足而不入库。",[18,166,167],{"id":167},"我们的一次排查",[11,169,170],{},"2025 年 6 月，一个做 API 网关的公司找过来，文档站 1200 个页面，GSC 显示只收录了 298 个。他们自己提交过三次 sitemap，也请人改过两轮内容，四个月没起色。",[11,172,173,174,177],{},"我们先看索引报告，大量文档页的状态是\"已发现，尚未编入索引\"，说明发现没问题、抓取跟不上。再拉日志：Googlebot 每天只请求 60 次左右，其中 40 多次花在一个带参数的搜索页上。查 robots.txt，发现一行 ",[43,175,176],{},"Disallow: \u002Fdocs\u002Fv2\u002F"," 是 2024 年做旧版迁移时留下的，一直没删，而 v2 恰好是现在的主力文档。",[11,179,180],{},"顺手又发现 sitemap 里有 3200 条是带 utm 参数的 302 跳转链接，等于往搜索引擎嘴里塞了一堆无效地址。",[11,182,183],{},"只改了两处：删掉那行 Disallow，sitemap 只保留返回 200 的规范 URL。第 11 天收录数从 298 涨到 913，一个月后 1200 页里收录了 1100 出头。",[18,185,186],{"id":186},"排查顺序为什么不能反",[11,188,189],{},"内容质量是四步里成本和周期都最高的一环，重写一轮至少两个月才能看出效果；robots.txt 和 sitemap 的问题，半小时就能验证。先把便宜的可能性排掉，是我们给自己定的规矩。有个团队反过来做，先重写了 40 篇文档，最后发现是 CDN 把 Googlebot 的 IP 段拦了，白干三个月。",[11,191,192],{},"顺序照抄就行：GSC 索引报告看理由，日志看有没有请求，curl 看返回的 HTML，最后才看页面本身写得怎么样。",[11,194,195],{},"另外一句实话：日志里连一次请求都没有的页面，先别想收录，先想它凭什么被找到。",{"title":102,"searchDepth":103,"depth":103,"links":197},[198,199,200],{"id":139,"depth":103,"text":139},{"id":167,"depth":103,"text":167},{"id":186,"depth":103,"text":186},"2025-09-13","页面不收录，九成能在发现、抓取、渲染、索引这四步里定位到原因。我们按倒序排查，附每一环的查法，以及 2025 年 6 月一个 1200 页文档站只收录 300 页的复盘。",{},"\u002Fblog\u002Fcrawler-discovery-to-index",{"title":131,"description":202},"blog\u002Fcrawler-discovery-to-index",[208,209,210],"抓取","索引","爬虫","ivhAhgnZHzoOzREp6Y8dTvg1LSFD5W2dXWwJsx_KeBA",{"id":213,"title":214,"author":6,"body":215,"canonical":113,"category":354,"cover":113,"date":355,"description":356,"draft":117,"extension":118,"keywords":113,"meta":357,"navigation":120,"noindex":117,"ogImage":113,"path":358,"seo":359,"seoDescription":113,"seoTitle":113,"stem":360,"tags":361,"updated":113,"__hash__":366},"blog\u002Fblog\u002Fsearch-intent-four-types-pages.md","搜索意图分四类，我们见过软件站三类配错页面",{"type":8,"value":216,"toc":347},[217,220,223,226,229,232,235,238,241,244,326,329,332,335,338,341,344],[11,218,219],{},"搜一个词的人想干什么，决定这个页面该长什么样。我们把搜索意图分成四类，每类只配一种页面。软件站最常见的问题是配错，不是写得不生动。配错了，文案改十遍也没用。",[18,221,222],{"id":222},"四类意图怎么分",[11,224,225],{},"分法很简单，看搜索结果前十。学习类，前十是百科、知乎、媒体长文；方案类，前十是同行的场景文章和案例；对比类，前十是对比页和选型清单；操作类，前十是文档和论坛问答。",[11,227,228],{},"判断只需要五分钟：搜一遍这个词，看前十名的页面类型，多数是什么，意图就是什么。",[18,230,231],{"id":231},"软件站最常配错的三种",[11,233,234],{},"第一种，把“XX 怎么选”写成了科普博客。2025 年 6 月我们接手一个项目管理 SaaS 站的诊断，那篇“XX 怎么选”排在第 8 位，半年带来两次试用。页面上没有对比表，没有价格区间，也没说谁适合谁不适合。搜这个词的人在决策，你给他概念解释。",[11,236,237],{},"第二种，把报错词塞进产品页的 FAQ 里。报错词意图极强，用户已经在用了，但你把他扔到营销页，他下一站就是竞品的文档。",[11,239,240],{},"第三种，拿品牌词当内容词。品牌词的意图是导航，写一篇“XX 是什么”去抢，等于用文章跟自己的首页抢位置。",[18,242,243],{"id":243},"一张对照表",[245,246,247,266],"table",{},[248,249,250],"thead",{},[251,252,253,257,260,263],"tr",{},[254,255,256],"th",{},"意图",[254,258,259],{},"用户状态",[254,261,262],{},"该给的页面",[254,264,265],{},"不该给的",[267,268,269,284,298,312],"tbody",{},[251,270,271,275,278,281],{},[272,273,274],"td",{},"学习",[272,276,277],{},"刚接触，还不知道买不买",[272,279,280],{},"概念、边界、常见误解",[272,282,283],{},"价格表和注册按钮",[251,285,286,289,292,295],{},[272,287,288],{},"方案",[272,290,291],{},"有痛点，在找解法",[272,293,294],{},"场景文、案例、方案拆解",[272,296,297],{},"功能清单",[251,299,300,303,306,309],{},[272,301,302],{},"对比",[272,304,305],{},"在两三家之间犹豫",[272,307,308],{},"对比表、选型清单、替代页",[272,310,311],{},"品牌宣传",[251,313,314,317,320,323],{},[272,315,316],{},"操作",[272,318,319],{},"已经在用，卡住了",[272,321,322],{},"文档、报错排查、配置教程",[272,324,325],{},"首页导流",[18,327,328],{"id":328},"意图会漂移",[11,330,331],{},"同一个词，两年前是学习意图，现在可能变成对比意图。品类越成熟，学习词越少，对比词越多。2024 年我们做的“数据可视化工具”还是个科普词，到 2025 年，这个词前十全是带对比表的页面。",[11,333,334],{},"所以意图判断要定期重做，别一次定终身。",[18,336,337],{"id":337},"我们的落法",[11,339,340],{},"词表里每个词都标上意图和对应的页面类型，没标的词不进排期。新页面立项时先看词表，页面类型定不下来，说明这个词还没研究清楚。",[11,342,343],{},"一个页面只承接一种意图，这是硬规矩。想把对比词和操作词写在同一个页面上，结果通常是两拨人都不满意。2025 年 8 月我们拆过一个“XX 报错解决”页面，把操作部分挪进文档，原来的页面留给对比，四个月后文档页带来的登录量翻了 3 倍。",[11,345,346],{},"意图配错的页面，改标题能救回来一点，救不了根本。真要改，就重写页面。",{"title":102,"searchDepth":103,"depth":103,"links":348},[349,350,351,352,353],{"id":222,"depth":103,"text":222},{"id":231,"depth":103,"text":231},{"id":243,"depth":103,"text":243},{"id":328,"depth":103,"text":328},{"id":337,"depth":103,"text":337},"SEO","2025-09-15","同一个词背后的人想干的是四种不同的事：找答案、找方案、比方案、找产品。四类意图对应四类页面，软件站最常见的错误是配错页面，损失比内容写得不生动大得多。",{},"\u002Fblog\u002Fsearch-intent-four-types-pages",{"title":214,"description":356},"blog\u002Fsearch-intent-four-types-pages",[362,363,364,365],"搜索意图","页面匹配","内容策略","软件公司","AaM-rwnqfKUnJHI68SEVfAkzB0ehRokN7kVqhM0J-ms",1794088112402]