[{"data":1,"prerenderedAt":334},["ShallowReactive",2],{"blog-china-mobile-network-field-test":3,"blog-prev-china-mobile-network-field-test":122,"blog-next-china-mobile-network-field-test":217},{"id":4,"title":5,"author":6,"body":7,"canonical":106,"category":107,"cover":106,"date":108,"description":109,"draft":110,"extension":111,"keywords":106,"meta":112,"navigation":113,"noindex":110,"ogImage":106,"path":114,"seo":115,"seoDescription":106,"seoTitle":106,"stem":116,"tags":117,"updated":106,"__hash__":121},"blog\u002Fblog\u002Fchina-mobile-network-field-test.md","国内三大运营商 4G 实测：同一页能差几秒","元析智能",{"type":8,"value":9,"toc":96},"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],[11,12,13],"p",{},"2026 年 10 月我们做了一组国内移动网络实测，三个城市、三家运营商、同一台中端安卓机，测五个页面的首屏。同一页面最好和最差差了 1.7 秒。这个差异在报表里看不到，但用户在承受。",[15,16,17],"h2",{"id":17},"怎么测的",[11,19,20],{},"设备用同一台中端机，清空缓存，每次测之前重启浏览器。",[11,22,23],{},"每个城市选三个时段：早高峰、午间、晚上八点。每个组合测三次，取中位数。",[11,25,26],{},"页面选五个：首页、产品页、定价页、文档页、博客文章。覆盖不同类型。",[11,28,29],{},"测试方式是手机上开热点给笔记本，用浏览器开发者工具记录。这样比纯手机录屏更容易拿到细粒度数据。",[15,31,32],{"id":32},"测出来的差异",[11,34,35],{},"首字节时间，不同城市之间差 200 到 400 毫秒，同一城市不同运营商能差 300 毫秒。",[11,37,38],{},"完整加载时间差异更大。资源多的页面，在信号弱的地方能差到 1.7 秒。",[11,40,41],{},"晚上八点是普遍最差的时段，比午间慢三成左右。这个规律在三个城市都成立。",[15,43,44],{"id":44},"差异从哪来",[11,46,47],{},"第一，基站负载。晚高峰人多，每个用户的带宽被摊薄。",[11,49,50],{},"第二，跨网访问。某些运营商的用户访问其他运营商机房的资源，要多绕一跳。",[11,52,53],{},"第三，DNS 解析。不同运营商的 DNS 解析速度和结果不一样，有时会解析到较远的节点。",[11,55,56],{},"第四，CDN 节点覆盖。如果 CDN 在某家运营商没有节点，用户就要跨网取资源。",[15,58,59],{"id":59},"对官网的启示",[11,61,62],{},"第一，别只用 Wi-Fi 测。大部分验收测试都在办公室 Wi-Fi 下做，数据好看，不代表用户体感。",[11,64,65],{},"第二，移动端单独设验收线。我们的标准是 4G 环境下首屏 3 秒内，文档页 2.5 秒内。",[11,67,68],{},"第三，CDN 要看运营商覆盖。三家都有节点的服务商，跨网差异会小很多。",[11,70,71],{},"第四，晚高峰要单独测。日常测出来的数据，晚八点可能差三成。",[15,73,74],{"id":74},"怎么自己复现",[11,76,77],{},"不需要专门的设备。一台中端安卓机、一张不同运营商的卡、一个固定的测试页面就够了。",[11,79,80],{},"测的时候关闭其他应用，用浏览器的无痕模式，每次清缓存。",[11,82,83],{},"测完记录城市、运营商、时段、首屏时间四项，凑够二十组数据就能看出规律。",[15,85,86],{"id":86},"一个态度",[11,88,89],{},"性能优化的目标不是实验室里的满分，是真实用户在真实网络下的体验。",[11,91,92],{},"国内移动网络的复杂性远超大部分人的想象，运营商、地域、时段、机型四个变量交叉，差异可以很大。",[11,94,95],{},"官网的流量里移动端占一半以上，这条线不测，等于放弃了大部分用户的体感。",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105],{"id":17,"depth":98,"text":17},{"id":32,"depth":98,"text":32},{"id":44,"depth":98,"text":44},{"id":59,"depth":98,"text":59},{"id":74,"depth":98,"text":74},{"id":86,"depth":98,"text":86},null,"工具评测","2026-11-04","三个城市、三家运营商、同一台中端机，测同一批页面的首屏。差异最大的一组差了 1.7 秒。这篇写测试方法、差异来源，以及官网该按哪条线验收。",false,"md",{},true,"\u002Fblog\u002Fchina-mobile-network-field-test",{"title":5,"description":109},"blog\u002Fchina-mobile-network-field-test",[118,119,120],"移动端","国内访问","实测","t6gL_SdgovqjuXqQkQUJ5U79LqlAk6akKvd8_rjHzD0",{"id":123,"title":124,"author":6,"body":125,"canonical":106,"category":206,"cover":106,"date":207,"description":208,"draft":110,"extension":111,"keywords":106,"meta":209,"navigation":113,"noindex":110,"ogImage":106,"path":210,"seo":211,"seoDescription":106,"seoTitle":106,"stem":212,"tags":213,"updated":106,"__hash__":216},"blog\u002Fblog\u002Fhttps-migration-checklist.md","从 HTTP 迁到 HTTPS：技术 SEO 的 12 个检查项和两个坑",{"type":8,"value":126,"toc":199},[127,130,134,137,140,143,146,149,153,156,159,162,165,169,172,175,178,181,184,187,190,193,196],[11,128,129],{},"HTTPS 迁移看着简单，做错的代价不小：证书链、混合内容、301 配置、HSTS，每一项都可能让收录掉一截。我们迁移过 15 个站，把检查项整理成 12 条。",[15,131,133],{"id":132},"迁移前的-4-项","迁移前的 4 项",[11,135,136],{},"2025 年 9 月到 2026 年 5 月我们迁移了 15 个站，最大的一个是 3 万页的文档站。清单是踩完坑之后整理的。",[11,138,139],{},"第一，证书类型选对。单域名、多域名、通配符，按站点的域名结构选。有子域名的站，单域名证书不够用。",[11,141,142],{},"第二，确认证书链完整。很多\"证书没问题\"的判断是错的，浏览器能打开不代表链完整。用 SSL Labs 测一遍，拿到 A 级以上再上线。",[11,144,145],{},"第三，备份现有 URL 清单。迁移前爬一遍全站，存一份 URL 列表，后面做映射和验证都要用。",[11,147,148],{},"第四，确定 301 规则。所有 HTTP URL 301 到对应的 HTTPS URL，不要全部跳到首页。",[15,150,152],{"id":151},"迁移中的-4-项","迁移中的 4 项",[11,154,155],{},"第五，301 配置正确。http 到 https、www 到非 www（或反过来），规则要一条一条配，别用通配符一刀切。",[11,157,158],{},"第六，混合内容清理。页面里的图片、JS、CSS、iframe 还有 http 地址的，全部改成 https 或者相对协议。混合内容会让浏览器报警，也影响安全评分。",[11,160,161],{},"第七，HSTS 先别急着开。HSTS 开了之后浏览器会强制 https，配置错了回滚很难。我们一般等迁移稳定两周后再开，而且先设短时间。",[11,163,164],{},"第八，sitemap 和 canonical 全部更新成 https。这一步最容易漏，尤其是历史文章里的 canonical。",[15,166,168],{"id":167},"迁移后的-4-项","迁移后的 4 项",[11,170,171],{},"第九，两边站长后台都提交新站点。GSC 里添加 https 版本并验证，百度搜索资源平台同样操作。",[11,173,174],{},"第十，看索引变化。迁移后 2 到 4 周是观察期，看 https 页面的收录量、http 页面的退出速度。",[11,176,177],{},"第十一，看流量和排名。迁移后有短期波动是正常的，掉 10% 以内不用慌；掉 30% 以上要查 301 和 canonical。",[11,179,180],{},"第十二，检查外链。外部站点链到 http 地址的，靠 301 接住，不用挨个联系改。少数重要的（客户官网、行业媒体）可以发邮件请对方更新。",[15,182,183],{"id":183},"两个容易忽略的",[11,185,186],{},"第一个，站内绝对 URL。很多 CMS 的文章正文里写死了 http 的绝对地址，迁移后这些链接会多一跳 301，浪费抓取预算。用脚本批量替换。",[11,188,189],{},"第二个，第三方服务的回调地址。支付、登录、统计的回调如果配的是 http，迁移后会失败。这个不是 SEO 问题，但会直接影响业务。",[15,191,192],{"id":192},"判断",[11,194,195],{},"HTTPS 迁移本身不复杂，复杂的是\"迁移之外\"的连带影响：混合内容、绝对 URL、第三方回调。",[11,197,198],{},"清单过一遍，比事后救火省事。我们现在的规矩是：迁移必须两人复核，一个人配、一个人查。迁移后的第一个月，每周对一次索引和流量，别等出问题才看。",{"title":97,"searchDepth":98,"depth":98,"links":200},[201,202,203,204,205],{"id":132,"depth":98,"text":133},{"id":151,"depth":98,"text":152},{"id":167,"depth":98,"text":168},{"id":183,"depth":98,"text":183},{"id":192,"depth":98,"text":192},"技术SEO","2026-11-03","HTTPS 迁移看着简单，做错的代价不小：证书链、混合内容、301 配置、HSTS，每一项都可能让收录掉一截。我们迁移过 15 个站，把检查项整理成 12 条，按迁移前、迁移中、迁移后分好，照着过一遍能少踩坑。最后写了两个我们踩过的坑。",{},"\u002Fblog\u002Fhttps-migration-checklist",{"title":124,"description":208},"blog\u002Fhttps-migration-checklist",[214,215,206],"HTTPS","迁移","2sLNyKV9uzSl8368CYK2Xd9ia6aWszDLi_ixz5XmDNM",{"id":218,"title":219,"author":6,"body":220,"canonical":106,"category":322,"cover":106,"date":323,"description":324,"draft":110,"extension":111,"keywords":106,"meta":325,"navigation":113,"noindex":110,"ogImage":106,"path":326,"seo":327,"seoDescription":106,"seoTitle":106,"stem":328,"tags":329,"updated":106,"__hash__":333},"blog\u002Fblog\u002Fcontent-half-life.md","内容的半衰期：哪些文章三年后还在带量",{"type":8,"value":221,"toc":312},[222,225,228,231,234,237,240,243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,291,294,297,300,303,306,309],[11,223,224],{},"内容有半衰期，有的三个月就没流量，有的三年还在涨。我们跟踪了 120 篇内容的流量曲线，分出三类：快消型、稳增型、长尾型。",[15,226,227],{"id":227},"什么是内容半衰期",[11,229,230],{},"一篇文章的月访问量掉到峰值的 50%，所花的时间，就是它的半衰期。",[11,232,233],{},"半衰期短的内容，需要持续补充；半衰期长的内容，是资产。",[15,235,236],{"id":236},"三类半衰期",[11,238,239],{},"快消型：半衰期 1 到 3 个月。新闻、热点分析、活动内容。写完就得推，过了时间就没用。",[11,241,242],{},"稳增型：半衰期 12 到 18 个月。教程、选型、对比。前期爬坡慢，稳定后有持续流量。",[11,244,245],{},"长尾型：半衰期 3 年以上。概念解释、踩坑记录、方法论。流量不大，但一直有。",[15,247,248],{"id":248},"我们跟踪的数据",[11,250,251],{},"2024 年 9 月开始，我们跟踪 120 篇文章 2 年：快消型 34 篇，平均半衰期 1.8 个月；稳增型 61 篇，平均 14 个月；长尾型 25 篇，两年后流量是峰值的 70%。",[11,253,254],{},"有意思的是，长尾型内容单篇流量最低，但两年累计流量最高，因为它在持续带量。",[15,256,257],{"id":257},"什么内容半衰期长",[11,259,260],{},"第一，回答\"不会变的问题\"。什么是 API、为什么需要限流，这些十年后还有人问。",[11,262,263],{},"第二，有独家信息的内容。别人抄不走，所以能长期占位。",[11,265,266],{},"第三，结构完整、可被引用的内容。AI 搜索和同行引用会持续带来流量。",[15,268,269],{"id":269},"怎么用半衰期做排期",[11,271,272],{},"快消型：控制在 20% 以内。做多了，团队会很累，而且不积累。",[11,274,275],{},"稳增型：主力，占 50%。这是搜索流量的基本盘。",[11,277,278],{},"长尾型：占 30%。短期看不到效果，但每年都在积累。",[11,280,281],{},"我们的季度排期一般按 2:5:3 分，和流量贡献的节奏匹配。",[15,283,284],{"id":284},"一个提醒",[11,286,287],{},"半衰期会变长。一篇教程如果每年更新，半衰期可以从 14 个月拉到 3 年。",[11,289,290],{},"所以\"更新\"不只是维护，还是延长资产寿命。",[15,292,293],{"id":293},"两个陷阱",[11,295,296],{},"第一个陷阱，把快消内容当资产。热点文章写完就完了，别指望它持续带量，也别为它做大量内链。",[11,298,299],{},"第二个陷阱，用快消数据判断团队。如果团队这个月写了两篇热点，流量好看，但三个月后归零。考核要看长尾型内容的存量。",[11,301,302],{},"我们的做法是分两个指标：当月流量看新内容，年度流量看资产内容。",[15,304,305],{"id":305},"一句判断",[11,307,308],{},"做内容不能只看当月流量。快消型内容让你这个月好看，长尾型内容让你三年后还有饭吃。",[11,310,311],{},"两者都要有，但比例别搞反。我们的比例是 2:5:3，跑了两年，比 5:3:2 稳。这个比例每年调一次，看当年的数据再定。",{"title":97,"searchDepth":98,"depth":98,"links":313},[314,315,316,317,318,319,320,321],{"id":227,"depth":98,"text":227},{"id":236,"depth":98,"text":236},{"id":248,"depth":98,"text":248},{"id":257,"depth":98,"text":257},{"id":269,"depth":98,"text":269},{"id":284,"depth":98,"text":284},{"id":293,"depth":98,"text":293},{"id":305,"depth":98,"text":305},"内容运营","2026-11-05","内容有半衰期，有的三个月就没流量，有的三年还在涨。我们跟踪了 120 篇内容的流量曲线，分出三类：快消型、稳增型、长尾型。半衰期怎么判断、怎么用它做排期都在这篇，数据来自我们对 120 篇内容的两年跟踪。",{},"\u002Fblog\u002Fcontent-half-life",{"title":219,"description":324},"blog\u002Fcontent-half-life",[330,331,332],"内容评估","内容策略","数据","q-rbxJmVri6Tw5XjEVR2NSeOO82TWzmDEap-WFPvTak",1794088100042]