[{"data":1,"prerenderedAt":341},["ShallowReactive",2],{"blog-weak-network-testing":3,"blog-prev-weak-network-testing":127,"blog-next-weak-network-testing":239},{"id":4,"title":5,"author":6,"body":7,"canonical":111,"category":112,"cover":111,"date":113,"description":114,"draft":115,"extension":116,"keywords":111,"meta":117,"navigation":118,"noindex":115,"ogImage":111,"path":119,"seo":120,"seoDescription":111,"seoTitle":111,"stem":121,"tags":122,"updated":111,"__hash__":126},"blog\u002Fblog\u002Fweak-network-testing.md","弱网测试只开 3G 降速，会漏掉一半问题","元析智能",{"type":8,"value":9,"toc":100},"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,91,94,97],[11,12,13],"p",{},"2026 年 10 月我们做了一组弱网测试，同一个页面，三种配置，首屏时间从 1.8 秒到 4.1 秒。差异不是页面本身的问题，是测试条件不同。只用 DevTools 的 3G 降速，会漏掉一半真实问题。",[15,16,18],"h2",{"id":17},"devtools-降速只模拟了两件事","DevTools 降速只模拟了两件事",[11,20,21],{},"它限制了带宽和往返延迟，就这两件。",[11,23,24],{},"它不会模拟丢包。真实弱网环境下丢包率能到 1% 到 3%，一次丢包触发重传，时间就多出好几百毫秒。",[11,26,27],{},"它也不会模拟手机的 CPU 压力。真机上页面在加载，还有其他应用在后台，CPU 不是满血状态。",[15,29,30],{"id":30},"真实弱网的三个特征",[11,32,33],{},"第一，高延迟。4G 在信号弱的地方，往返延迟能到 200 到 400 毫秒。",[11,35,36],{},"第二，丢包。基站的负载、电梯、地铁、地下车库，都会造成间歇性丢包。",[11,38,39],{},"第三，带宽波动。同一个位置，人一多，速度掉一半。",[15,41,42],{"id":42},"我们用的三种配置",[11,44,45],{},"第一种，3G 快速，带宽 1.6 兆，延迟 150 毫秒。用来测基本可用性。",[11,47,48],{},"第二种，4G 弱信号，带宽 1 兆，延迟 400 毫秒，丢包 1%。这个最接近地铁和商场。",[11,50,51],{},"第三种，自定义慢速，带宽 400KB，延迟 600 毫秒。用来测极端情况，看页面会不会直接崩。",[11,53,54],{},"我们的验收标准是第二种通过即可，第三种只做参考。",[15,56,57],{"id":57},"用真机做真实弱网",[11,59,60],{},"DevTools 的模拟再准，也比不上真实环境。",[11,62,63],{},"最简单的办法：手机开热点，笔记本连上去，用系统工具给热点限速。测出来的数据比 DevTools 更接近实际。",[11,65,66],{},"更真实的做法是走到地铁、电梯、商场这些地方打开页面，录屏。看哪一步卡住。这种方法不能量化，但能发现一些数据里看不出的问题。",[15,68,69],{"id":69},"弱网下先看什么",[11,71,72],{},"先看请求数量。弱网下每个请求都要一个来回，请求少的页面天然占优。",[11,74,75],{},"再看首屏资源体积。超过 1 兆的首屏资源，弱网下基本要等三秒以上。",[11,77,78],{},"最后看有没有串行依赖。CSS 里有 @import、JS 里动态加载 CSS，这类串行在弱网下会被放大好几倍。",[15,80,81],{"id":81},"一个成本很低的改进",[11,83,84],{},"请求数是弱网下最敏感的因素。我们给一个站把首屏的七个图标字体合成一个 SVG 精灵图，请求从七个变成一个，弱网首屏快了 400 毫秒。",[11,86,87],{},"这个改动一天能做完，不用改设计。弱网优化里，减少请求的收益通常比压缩体积大，因为每个请求都要一次来回。",[15,89,90],{"id":90},"一个态度",[11,92,93],{},"弱网测试的意义不是追求极端环境下的完美，是知道自己的页面在什么条件下会崩。",[11,95,96],{},"大部分软件公司的客户里，有一部分人就是在弱网环境下访问的，可能是出差、可能在客户现场。",[11,98,99],{},"对这些用户来说，首屏晚两秒可能就关掉页面了。这个损失在报表里看不到，但真实存在。",{"title":101,"searchDepth":102,"depth":102,"links":103},"",2,[104,105,106,107,108,109,110],{"id":17,"depth":102,"text":18},{"id":30,"depth":102,"text":30},{"id":42,"depth":102,"text":42},{"id":57,"depth":102,"text":57},{"id":69,"depth":102,"text":69},{"id":81,"depth":102,"text":81},{"id":90,"depth":102,"text":90},null,"技术SEO","2026-10-08","我们把同一页放在三种弱网配置下测，首屏差了 2.3 秒。DevTools 的降速只模拟网络，不模拟丢包和真实手机的处境，这篇写我们的替代测法。",false,"md",{},true,"\u002Fblog\u002Fweak-network-testing",{"title":5,"description":114},"blog\u002Fweak-network-testing",[123,124,125],"弱网测试","页面体验","移动端","6A-BcrO1X4nN_D1bYIQBUJfQlMjiZET3Jj5ZyeM2nYE",{"id":128,"title":129,"author":6,"body":130,"canonical":111,"category":112,"cover":111,"date":229,"description":230,"draft":115,"extension":116,"keywords":111,"meta":231,"navigation":118,"noindex":115,"ogImage":111,"path":232,"seo":233,"seoDescription":111,"seoTitle":111,"stem":234,"tags":235,"updated":111,"__hash__":238},"blog\u002Fblog\u002Fmobile-technical-seo.md","移动端技术 SEO：桌面和移动内容不一致的 4 个后果",{"type":8,"value":131,"toc":220},[132,135,138,141,144,148,151,154,157,161,164,167,170,174,177,180,183,187,190,193,196,199,202,205,208,211,214,217],[11,133,134],{},"移动优先索引意味着搜索引擎主要看移动版。桌面有内容、移动端没有，排名会按移动版算。2026 年 3 月到 6 月我们检查过 20 个软件站，4 个常见问题几乎每家都有。",[15,136,137],{"id":137},"移动优先索引意味着什么",[11,139,140],{},"Google 现在主要用移动版页面来索引和排名，百度也以移动端为主。也就是说，用户用手机搜到的结果，排序依据是移动版页面的质量。",[11,142,143],{},"桌面版做得再完整，移动版缺内容，排名按缺的算。",[15,145,147],{"id":146},"后果一移动端少内容桌面排名受影响","后果一：移动端少内容，桌面排名受影响",[11,149,150],{},"最常见的做法是移动端隐藏一部分内容：为了\"简洁\"砍掉表格、折叠长文、隐藏参数对比。",[11,152,153],{},"我们检查的 20 个站里，8 个的移动版正文比桌面版少 30% 以上。这些站的核心词排名，普遍比移动内容完整的站低 3 到 5 名。",[11,155,156],{},"修法：移动端可以折叠，但内容要在 HTML 里，别用 display:none 删掉。",[15,158,160],{"id":159},"后果二移动端加载慢抓取变少","后果二：移动端加载慢，抓取变少",[11,162,163],{},"移动端的网络环境和设备性能比桌面差，同一个页面，移动端 LCP 可能慢 2 到 3 倍。",[11,165,166],{},"抓取预算按移动版算，加载慢的页面被抓得少。我们一个客户移动端 LCP 4.8 秒，核心页平均 9 天抓一次；优化到 2.2 秒后，缩到 3 天。",[11,168,169],{},"修法：图片压缩和懒加载、字体精简、第三方脚本延后。",[15,171,173],{"id":172},"后果三弹窗和下载引导被判干扰","后果三：弹窗和下载引导被判干扰",[11,175,176],{},"移动端常见的问题：首屏弹窗要求下载 App、顶部横幅遮挡内容、自动播放视频。",[11,178,179],{},"这些做法会影响页面体验评分，严重的会被判定为干扰性插页。",[11,181,182],{},"修法：首屏不放大弹窗，下载引导放到内容之后，用页面内按钮代替强制跳转。",[15,184,186],{"id":185},"后果四移动端-url-和桌面不一致","后果四：移动端 URL 和桌面不一致",[11,188,189],{},"独立移动站（m.example.com）的站，容易出现两个问题：移动站和桌面站内容不同步，以及两边的 URL 关系没配好。",[11,191,192],{},"现在的趋势是响应式，一套代码适配所有设备。如果你还用独立移动站，至少保证内容一致、互相有链接、canonical 正确。",[15,194,195],{"id":195},"我们的检查清单",[11,197,198],{},"第一，用手机 UA 抓一次页面，对比桌面版的内容量。",[11,200,201],{},"第二，测移动端 LCP 和 INP，重点看首屏。",[11,203,204],{},"第三，检查有没有遮挡内容的弹窗和横幅。",[11,206,207],{},"第四，确认移动端页面的标题、描述、canonical 和桌面一致。",[11,209,210],{},"第五，看移动端的抓取占比，Googlebot 和百度蜘蛛的移动 UA 请求是否正常。",[15,212,213],{"id":213},"判断",[11,215,216],{},"移动端不是\"另一个版本\"，是主版本。按这个前提做技术检查，很多问题会自然消失。",[11,218,219],{},"一个建议：每次改版，先用手机看一遍，再用手机 UA 抓一遍，两个不一样的地方就是风险点。",{"title":101,"searchDepth":102,"depth":102,"links":221},[222,223,224,225,226,227,228],{"id":137,"depth":102,"text":137},{"id":146,"depth":102,"text":147},{"id":159,"depth":102,"text":160},{"id":172,"depth":102,"text":173},{"id":185,"depth":102,"text":186},{"id":195,"depth":102,"text":195},{"id":213,"depth":102,"text":213},"2026-10-07","移动优先索引意味着搜索引擎主要看移动版。桌面有内容、移动端没有，排名会按移动版算。2026 年 3 月到 6 月我们检查过 20 个软件站，4 个常见问题几乎每家都有。检查清单和修法都在这篇，照着查一遍一小时能看完。",{},"\u002Fblog\u002Fmobile-technical-seo",{"title":129,"description":230},"blog\u002Fmobile-technical-seo",[236,237,124],"移动优先索引","移动SEO","sYcEFILKRXbaLeJ-jAnjo9uUcZxQJii446vyd3Mgsog",{"id":240,"title":241,"author":6,"body":242,"canonical":111,"category":329,"cover":111,"date":330,"description":331,"draft":115,"extension":116,"keywords":111,"meta":332,"navigation":118,"noindex":115,"ogImage":111,"path":333,"seo":334,"seoDescription":111,"seoTitle":111,"stem":335,"tags":336,"updated":111,"__hash__":340},"blog\u002Fblog\u002Fblog-audit-300-posts.md","一个 300 篇的博客站，审完只留了 78 篇",{"type":8,"value":243,"toc":319},[244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301,304,307,310,313,316],[11,245,246],{},"2026 年 6 月我们审了一个五年的老博客站，300 篇文章。最后建议：留 78 篇，并 96 篇，删 84 篇，改 42 篇。客户第一反应是“删这么多流量不会掉吗”，两个月后流量比审之前还高 6%。",[15,248,249],{"id":249},"这个站的问题在哪",[11,251,252],{},"三个。主题散，12 个不相关的方向都写过；重复多，同一个主题写过三到五篇；没有承接，大部分文章跟产品线对不上。",[11,254,255],{},"五年前写行业观察，三年前写产品更新，去年开始跟风写关键词。每年的方向都不一样，导致整个站没有主题。",[15,257,258],{"id":258},"留的标准",[11,260,261],{},"只有一条：有排名或有外链，且能对上现在的产品线。",[11,263,264],{},"78 篇里，56 篇有排名，22 篇有外链但没排名。这两类都值得留。",[15,266,267],{"id":267},"并的操作",[11,269,270],{},"96 篇合并成 31 篇。合并的原则是同一核心词、同一读者、同一结论。",[11,272,273],{},"先选主文，补齐内容，再 301。这个过程我们花了三周半，比预期慢，因为要给每篇主文补材料。",[15,275,276],{"id":276},"删的顾虑怎么处理",[11,278,279],{},"客户怕删了掉流量。我们给了两组数据：这 84 篇过去 12 个月总曝光占全站 1.7%，总点击占 0.9%。",[11,281,282],{},"删完第一周流量掉了 4%，第三周回升，两个月后比原来高 6%。删掉的是抓取预算里的噪音，不是流量。",[15,284,285],{"id":285},"结果",[11,287,288],{},"三个月后，收录页面数从 210 到 160，但有效收录比例从 52% 到 78%。抓取频次涨了，日志里每天被抓的页面从 300 多降到 180，每页被抓次数上升。",[11,290,291],{},"客户最直观的感受是：写新文章之后，收录速度快了。",[15,293,294],{"id":294},"教训",[11,296,297],{},"内容不是资产，只有被搜到的才是资产。一个站写五年，能留下四分之一就算不错。",[15,299,300],{"id":300},"审计之后怎么写新内容",[11,302,303],{},"老站审计完之后，新内容的选题全部从“留下”的那 78 篇里长出来：给它们补簇页、补对比页、补文档。",[11,305,306],{},"这样写出来的内容自带内链和已有权重，起来得比从零开新题快。",[15,308,309],{"id":309},"一个成本参考",[11,311,312],{},"300 篇的审计，我们两个人做了 11 个工作日。客户自己内部又花了 5 天做决策和沟通。",[11,314,315],{},"如果你们站不到 100 篇，三天能做完。别拖，越拖越贵。",[11,317,318],{},"我们现在给客户做年度复盘，都会顺带看一眼“无效页面占比”。超过 60% 的，先审计再扩写。",{"title":101,"searchDepth":102,"depth":102,"links":320},[321,322,323,324,325,326,327,328],{"id":249,"depth":102,"text":249},{"id":258,"depth":102,"text":258},{"id":267,"depth":102,"text":267},{"id":276,"depth":102,"text":276},{"id":285,"depth":102,"text":285},{"id":294,"depth":102,"text":294},{"id":300,"depth":102,"text":300},{"id":309,"depth":102,"text":309},"内容运营","2026-10-09","2026 年 6 月我们审了一个五年的老博客站：留 78 篇、并 96 篇、删 84 篇、改 42 篇。客户最担心删了掉流量，实际两个月后流量比审之前还高 6%。",{},"\u002Fblog\u002Fblog-audit-300-posts",{"title":241,"description":331},"blog\u002Fblog-audit-300-posts",[337,338,339],"内容审计","复盘","博客运营","BeXglAleqx5QaAGL5FMO3tEWCjC1SBagwwp3Y_vHgqE",1794088101000]