[{"data":1,"prerenderedAt":363},["ShallowReactive",2],{"blog-cwv-monitoring-tools":3,"blog-prev-cwv-monitoring-tools":126,"blog-next-cwv-monitoring-tools":251},{"id":4,"title":5,"author":6,"body":7,"canonical":110,"category":111,"cover":110,"date":112,"description":113,"draft":114,"extension":115,"keywords":110,"meta":116,"navigation":117,"noindex":114,"ogImage":110,"path":118,"seo":119,"seoDescription":110,"seoTitle":110,"stem":120,"tags":121,"updated":110,"__hash__":125},"blog\u002Fblog\u002Fcwv-monitoring-tools.md","测速工具那么多，我们最后只留三个","元析智能",{"type":8,"value":9,"toc":99},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87,90,93,96],[11,12,13],"p",{},"2026 年 9 月我们把自己用过的测速工具清了一遍，五个，最后只留三个。工具不是越多越好，同一件事用三个工具测，数据不一致时反而不知道该信谁。",[15,16,17],"h2",{"id":17},"工具分四类",[11,19,20],{},"第一类，本地实验室。Lighthouse 装在浏览器或者命令行里，跑一次出一份报告，能看到具体哪个资源拖了后腿。",[11,22,23],{},"第二类，在线单页测试。PageSpeed Insights 除了跑实验室数据，还会带上 CrUX 的真实用户数据，一页看两边。",[11,25,26],{},"第三类，多地合成监控。WebPageTest 可以从不同地点、不同设备跑，看地域差异。",[11,28,29],{},"第四类，国内测速平台。国内节点覆盖好，能反映真实的国内访问速度。",[15,31,32],{"id":32},"我们留下的三个",[11,34,35],{},"Lighthouse，本地跑，用来诊断和改完验证。它的价值是详细，每个资源、每段 JS 执行都能看到。",[11,37,38],{},"PageSpeed Insights，看真实用户数据。它给的 CrUX 是 75 分位，比实验室数据更接近用户体验。",[11,40,41],{},"国内的测速平台，用来测国内多地的首字节和完整加载时间。海外工具在国内的数据不可信。",[11,43,44],{},"WebPageTest 我们只在需要看瀑布图对比时用，不算日常工具。",[15,46,47],{"id":47},"每个工具的限制",[11,49,50],{},"Lighthouse 的数据是模拟的，同一个页面跑两次分数可能差十分。别盯着分数，看具体指标和诊断建议。",[11,52,53],{},"PageSpeed Insights 的 CrUX 只有流量足够的站才有数据，小站会显示数据不足。这时候只能看实验室数据。",[11,55,56],{},"国内测速平台的节点和设备配置不透明，适合看趋势和对比，不适合当绝对标准。",[15,58,59],{"id":59},"国内工具的一个细节",[11,61,62],{},"部分国内测速平台的节点是虚拟的，报出来的数据波动很小，看着很稳，但和真实用户差很远。",[11,64,65],{},"判断办法是拿同一页在平台测一次、再用真实手机打开一次，对一下时间。差得多，就只能拿平台数据看趋势，不能当标准。",[15,67,68],{"id":68},"一个用工具的规矩",[11,70,71],{},"同一个页面，改前改后必须用同一个工具、同一套参数测。换工具对比等于没对比。",[11,73,74],{},"移动端测试固定开 4G 降速和 4 倍 CPU 降速，这两个参数别改来改去。",[11,76,77],{},"每次测三次取中位数。单次数据波动太大，尤其是网络相关的指标。",[15,79,80],{"id":80},"监控不能只靠手动",[11,82,83],{},"手动测只能看到某一天的状态。真实的问题是上线之后慢慢变差，没人发现。",[11,85,86],{},"我们的做法是核心页面每天自动跑一次 Lighthouse，把 LCP、INP、CLS 记到表里，连续三天变差就提醒。",[11,88,89],{},"这个监控不需要付费工具，一个定时任务加一个脚本就够。它的价值是发现回归，不是给老板看报表。",[15,91,92],{"id":92},"一个态度",[11,94,95],{},"工具是手段，不是目标。花时间比较工具，不如花时间改一个真实的性能问题。",[11,97,98],{},"我们见过团队为了选监控工具开了三次会，站上的首屏还是四秒。这个顺序明显反了。",{"title":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107,108,109],{"id":17,"depth":101,"text":17},{"id":32,"depth":101,"text":32},{"id":47,"depth":101,"text":47},{"id":59,"depth":101,"text":59},{"id":68,"depth":101,"text":68},{"id":80,"depth":101,"text":80},{"id":92,"depth":101,"text":92},null,"工具评测","2026-08-31","实验室工具、合成监控、真实用户数据，三类各有用处。这篇写 Lighthouse、PageSpeed Insights、WebPageTest 和国内测速平台各管什么，哪些可以放弃。",false,"md",{},true,"\u002Fblog\u002Fcwv-monitoring-tools",{"title":5,"description":113},"blog\u002Fcwv-monitoring-tools",[122,123,124],"测速工具","CoreWebVitals","监控","ZHBgw8O2mZcYtJ5aBE18WOFMtT8C7gIP9VsgALDXVSE",{"id":127,"title":128,"author":6,"body":129,"canonical":110,"category":239,"cover":110,"date":240,"description":241,"draft":114,"extension":115,"keywords":110,"meta":242,"navigation":117,"noindex":114,"ogImage":110,"path":243,"seo":244,"seoDescription":110,"seoTitle":110,"stem":245,"tags":246,"updated":110,"__hash__":250},"blog\u002Fblog\u002Fmultilingual-site-structure.md","多语言站用子目录、子域名还是独立域名：软件公司怎么选",{"type":8,"value":130,"toc":230},[131,134,137,145,152,163,167,170,173,176,179,182,185,188,191,194,197,200,203,206,209,212,215,218,221,224,227],[11,132,133],{},"三种结构没有绝对优劣，看你的市场、团队和 SEO 目标。2025 年 9 月到 2026 年 6 月，我们给 12 个软件公司做过选择：做周边市场选子目录，做重点市场选子域名，品牌独立运营才用独立域名。",[15,135,136],{"id":136},"三种结构的差别",[11,138,139,140,144],{},"子目录：",[141,142,143],"code",{},"example.com\u002Fen\u002F","。主域名权重共享，配置简单，运营成本最低。",[11,146,147,148,151],{},"子域名：",[141,149,150],{},"en.example.com","。技术上独立，权重继承比子目录弱一些，但可以单独部署和运营。",[11,153,154,155,158,159,162],{},"独立域名：",[141,156,157],{},"example.en"," 或 ",[141,160,161],{},"example.co.uk","。品牌和地域信号最强，成本和运营复杂度最高。",[15,164,166],{"id":165},"我们给-12-个软件公司的选择","我们给 12 个软件公司的选择",[11,168,169],{},"6 个选了子目录，4 个选了子域名，2 个用了独立域名。",[11,171,172],{},"选子目录的，都是\"英文站主要给现有客户看、顺便拿点海外搜索流量\"的公司。比如一个做 API 工具的客户，英文文档是产品的一部分，不是独立市场。",[11,174,175],{},"选子域名的，是\"海外是重点市场，有独立团队\"的。一个做数据平台的客户，英文站单独配置 CDN、单独做内容排期，子域名更合适。",[11,177,178],{},"用独立域名的 2 个，一个是收购的海外品牌，一个是在欧洲有本地实体的。",[15,180,181],{"id":181},"什么情况选子目录",[11,183,184],{},"三个条件：英文内容规模不大（500 页以内）、没有独立的海外运营团队、主要目标是让现有客户和少量海外用户看懂。",[11,186,187],{},"子目录最大的好处是权重共享。主站有排名，子目录的页面起步就快。我们一个客户的主站有 3000 个外链，英文子目录上线 3 周就开始出词。",[11,189,190],{},"缺点是不好做地域定向，也不方便单独统计。",[15,192,193],{"id":193},"什么情况选子域名",[11,195,196],{},"三个条件：海外是重点市场、有独立的内容和运营团队、需要单独做技术和 CDN 配置。",[11,198,199],{},"子域名的权重继承弱一些，但可以通过主站的导航和链接传递。我们一般要求主站首页链到子域名，子域名也链回主站。",[11,201,202],{},"一个客户的英文子域名，上线 6 个月，自然流量从 0 到每月 8000，主站的外链帮了不少忙。",[15,204,205],{"id":205},"什么情况用独立域名",[11,207,208],{},"只有两种：品牌在目标市场独立运营，或者有本地实体（法律、支付、客服需要本地化）。",[11,210,211],{},"独立域名的 SEO 成本最高，要从零积累权重。我们建议大部分软件公司别选，除非有明确的品牌策略。",[15,213,214],{"id":214},"迁移的坑",[11,216,217],{},"从子目录换到子域名，或者反过来，都是迁移。三个必须做的：全量 301 映射、hreflang 同步更新、两边站点地图都提交。",[11,219,220],{},"我们见过客户迁移后忘了改 hreflang，结果英文页被 Google 当成中文页的副本，两个版本互相压排名，掉了两个月。",[15,222,223],{"id":223},"判断",[11,225,226],{},"结构选择是战略问题，不是技术问题。选错了再改，成本很高。",[11,228,229],{},"一个小建议：不确定的时候选子目录，它最便宜、最容易回退。等海外市场真的起来了，再迁到子域名也不迟。",{"title":100,"searchDepth":101,"depth":101,"links":231},[232,233,234,235,236,237,238],{"id":136,"depth":101,"text":136},{"id":165,"depth":101,"text":166},{"id":181,"depth":101,"text":181},{"id":193,"depth":101,"text":193},{"id":205,"depth":101,"text":205},{"id":214,"depth":101,"text":214},{"id":223,"depth":101,"text":223},"技术SEO","2026-08-30","三种结构没有绝对优劣，看你的市场、团队和 SEO 目标。2025 年 9 月到 2026 年 6 月，我们给 12 个软件公司做过选择：做周边市场选子目录，做重点市场选子域名，品牌独立运营才用独立域名。判断依据和迁移的坑都在这篇。选错再改的成本很高。",{},"\u002Fblog\u002Fmultilingual-site-structure",{"title":128,"description":241},"blog\u002Fmultilingual-site-structure",[247,248,249],"多语言","站点结构","国际SEO","iudP8kQIu-Xlwx04vNH6kqPvrSSs14Um9Ck-RxC1DqM",{"id":252,"title":253,"author":6,"body":254,"canonical":110,"category":352,"cover":110,"date":353,"description":354,"draft":114,"extension":115,"keywords":110,"meta":355,"navigation":117,"noindex":114,"ogImage":110,"path":356,"seo":357,"seoDescription":110,"seoTitle":110,"stem":358,"tags":359,"updated":110,"__hash__":362},"blog\u002Fblog\u002Fcontent-refresh-calendar.md","内容维护日历：哪些文章每年必更，哪些三年不用动",{"type":8,"value":255,"toc":343},[256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301,304,307,310,313,316,319,322,325,328,331,334,337,340],[11,257,258],{},"内容发完就不管，两年后一半的文章在拖后腿。我们按内容类型排了维护日历：产品文档每季度、教程每年、观点文两年、数据文跟着数据走。",[15,260,261],{"id":261},"为什么要排维护日历",[11,263,264],{},"不维护的内容会慢慢失效：价格变了、功能下线了、竞品换了、数据过时了。",[11,266,267],{},"我们 2026 年 2 月抽查过一个客户的 60 篇老文，其中 23 篇有明显过时信息，比如还在写已经下线的功能、还在用两年前的定价。",[11,269,270],{},"这些文章不删，会拉低整站可信度；全删，又浪费历史权重。维护日历就是解决这个问题的。",[15,272,273],{"id":273},"按内容类型定周期",[11,275,276],{},"产品功能页：每季度对一次。价格、版本号、截图必须是最新的。",[11,278,279],{},"教程和操作文：每年更新一次。补新版本的操作步骤、新案例。",[11,281,282],{},"对比和选型文：每半年一次。竞品和价格变化快，半年不更就可能误导。",[11,284,285],{},"观点和行业分析：每两年一次。观点可以旧，但要标注\"写于某年\"。",[11,287,288],{},"数据报告：跟着数据走。新数据出来就更新，或者每年发新版。",[15,290,291],{"id":291},"三类必须每年更新的内容",[11,293,294],{},"第一类，带价格、版本、参数的内容。用户搜到两年前的价格，会直接离开。",[11,296,297],{},"第二类，带操作步骤的教程。产品界面一年一变，旧步骤照做会出错。",[11,299,300],{},"第三类，被 AI 搜索频繁引用的内容。AI 引用的内容如果过时，会持续传播错误信息。",[15,302,303],{"id":303},"三类可以三年不动的",[11,305,306],{},"第一类，概念解释类。什么是 API、什么是限流，这些不会变。",[11,308,309],{},"第二类，历史复盘类。写过去发生的事，内容本身就是固定的。",[11,311,312],{},"第三类，方法论类。我们讲怎么判断内容质量，这类内容不依赖具体产品版本。",[15,314,315],{"id":315},"我们的日历怎么排",[11,317,318],{},"每年 12 月排下一年的维护计划：把全部文章按类型分组，标出更新月份。",[11,320,321],{},"每月维护 15 到 20 篇，占内容团队 10% 的时间。别一次全更，会挤掉新内容的产能。",[11,323,324],{},"更新时不要只改日期。至少改三处：数据、案例、结论。",[15,326,327],{"id":327},"一个提醒",[11,329,330],{},"不是所有旧文都值得维护。判断标准：还有搜索需求吗、还有外链吗、还有转化路径吗。",[11,332,333],{},"三个都没有的，删掉或者合并，比维护便宜。",[15,335,336],{"id":336},"一句判断",[11,338,339],{},"内容维护是\"看不见的产能\"。用户看不到你改了什么，但搜索引擎能看到页面的新鲜度和准确性。",[11,341,342],{},"一个建议：把维护当成固定成本，写进年度计划，别等排名掉了才想起来。",{"title":100,"searchDepth":101,"depth":101,"links":344},[345,346,347,348,349,350,351],{"id":261,"depth":101,"text":261},{"id":273,"depth":101,"text":273},{"id":291,"depth":101,"text":291},{"id":303,"depth":101,"text":303},{"id":315,"depth":101,"text":315},{"id":327,"depth":101,"text":327},{"id":336,"depth":101,"text":336},"内容运营","2026-09-01","内容发完就不管，两年后一半的文章在拖后腿。我们按内容类型排了维护日历：产品文档每季度、教程每年、观点文两年、数据文跟着数据走。哪些必更、哪些别碰、日历怎么排都在这篇，照着排能省一半维护时间。",{},"\u002Fblog\u002Fcontent-refresh-calendar",{"title":253,"description":354},"blog\u002Fcontent-refresh-calendar",[360,361,352],"内容维护","内容更新","w-BQ4dWjajdLcXmEnjB3bEAMFKxfWaAXlq70T_wXBKI",1794088102290]