[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"blog-mobile-desktop-cwv-gap":3,"blog-prev-mobile-desktop-cwv-gap":120,"blog-next-mobile-desktop-cwv-gap":223},{"id":4,"title":5,"author":6,"body":7,"canonical":104,"category":105,"cover":104,"date":106,"description":107,"draft":108,"extension":109,"keywords":104,"meta":110,"navigation":111,"noindex":108,"ogImage":104,"path":112,"seo":113,"seoDescription":104,"seoTitle":104,"stem":114,"tags":115,"updated":104,"__hash__":119},"blog\u002Fblog\u002Fmobile-desktop-cwv-gap.md","移动端比桌面慢三秒，差距不只在网络","元析智能",{"type":8,"value":9,"toc":94},"minimark",[10,14,18,21,24,27,30,33,36,39,42,46,49,52,55,58,61,64,67,70,73,76,79,82,85,88,91],[11,12,13],"p",{},"2026 年 9 月我们测一个客户站，同一页面桌面 1.8 秒、移动端 5.1 秒。客户第一反应是移动网络慢。查下来，网络只占了一半，另一半是 CPU 和渲染。",[15,16,17],"h2",{"id":17},"四个差距来源",[11,19,20],{},"第一，CPU。中端安卓机的性能大约是桌面电脑的四分之一，同样的 JS 在手机上执行时间翻几倍。",[11,22,23],{},"第二，网络。4G 的往返延迟比宽带高，带宽也不稳定，晚高峰更明显。",[11,25,26],{},"第三，渲染。移动端屏幕小，但 DOM 没变，布局计算和绘制的工作量并没有减少。",[11,28,29],{},"第四，资源。移动端视口窄，可能触发不同的图片尺寸和懒加载逻辑，加载的资源反而不一样。",[15,31,32],{"id":32},"网络不是主因",[11,34,35],{},"很多人把移动端慢归咎于网络，实测下来 4G 的带宽对大部分页面够用，真正拖时间的是延迟。",[11,37,38],{},"一个请求来回 100 毫秒，首屏要串行发五个请求，光是等待就是半秒。桌面宽带这个数字是 20 毫秒。",[11,40,41],{},"所以减少请求数量比压缩资源体积更有效，尤其是在移动端。",[15,43,45],{"id":44},"cpu-降速才是大头","CPU 降速才是大头",[11,47,48],{},"桌面电脑跑得欢的 JS，在中端手机上执行时间能翻四倍。",[11,50,51],{},"如果首屏要执行 800 毫秒的 JS，手机上就是三秒多。这还没算解码图片和渲染布局。",[11,53,54],{},"测试时必须打开 CPU 降速。Lighthouse 默认给移动端 4 倍降速，这个值接近真实的中端机，别关掉。",[15,56,57],{"id":57},"移动端专属的四个坑",[11,59,60],{},"第一个，懒加载触发太早。移动端视口窄，图片懒加载的阈值如果按桌面设置，用户滚动一下就要下载好几张。",[11,62,63],{},"第二个，字体太大。移动端带宽和 CPU 都紧张，几兆的中文字体在手机上是灾难。",[11,65,66],{},"第三个，浮层太多。客服、Cookie 提示、下载 App 的横幅，三个浮层叠在小屏上，遮挡内容还影响交互。",[11,68,69],{},"第四个，横向溢出。页面出现横向滚动条，用户在手机上左右晃，体验直接崩掉。",[15,71,72],{"id":72},"怎么测",[11,74,75],{},"先用 DevTools 的移动端模拟，开 4G 降速和 4 倍 CPU 降速，看首屏指标。",[11,77,78],{},"再用真机测。模拟器和真机差很多，尤其是低端安卓机上的表现。",[11,80,81],{},"最后看 CrUX 按设备分组的数据。移动端的真实用户分布才是判断用户感受的依据。",[15,83,84],{"id":84},"一个判断",[11,86,87],{},"移动端优化不能靠桌面数据推算。同一套代码，桌面合格、移动端超标是常态。",[11,89,90],{},"我们的项目验收标准里，移动端的 LCP 单独设一条线，不和桌面共用。",[11,92,93],{},"因为大部分软件公司的流量里，移动端占比已经超过一半，甚至更高。只优化桌面，等于只做了一半。",{"title":95,"searchDepth":96,"depth":96,"links":97},"",2,[98,99,100,101,102,103],{"id":17,"depth":96,"text":17},{"id":32,"depth":96,"text":32},{"id":44,"depth":96,"text":45},{"id":57,"depth":96,"text":57},{"id":72,"depth":96,"text":72},{"id":84,"depth":96,"text":84},null,"技术SEO","2026-08-21","同一页面桌面 1.8 秒、移动 5.1 秒。很多人以为差在网络，其实 CPU 降速和布局复杂度占大头。这篇写四个差距来源和移动端专属的测试方法。",false,"md",{},true,"\u002Fblog\u002Fmobile-desktop-cwv-gap",{"title":5,"description":107},"blog\u002Fmobile-desktop-cwv-gap",[116,117,118],"移动端","CoreWebVitals","测速","015VaLRnQmI9rnAktRBsKlBKBNOLm6Y8AltoddAZV7Y",{"id":121,"title":122,"author":6,"body":123,"canonical":104,"category":105,"cover":104,"date":212,"description":213,"draft":108,"extension":109,"keywords":104,"meta":214,"navigation":111,"noindex":108,"ogImage":104,"path":215,"seo":216,"seoDescription":104,"seoTitle":104,"stem":217,"tags":218,"updated":104,"__hash__":222},"blog\u002Fblog\u002Fcdn-cache-crawl.md","CDN 缓存配错，改版后蜘蛛三天没看到新内容",{"type":8,"value":124,"toc":203},[125,128,131,134,137,140,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191,194,197,200],[11,126,127],{},"一次改版上线三天，搜索引擎抓到的还是旧页面，原因是 CDN 缓存把 HTML 缓存了 7 天。缓存和抓取的关系，很多技术团队没意识到。",[15,129,130],{"id":130},"那次事故",[11,132,133],{},"2026 年 3 月，一个客户的官网改版，产品页 URL 和结构都变了，301 也配好了。上线三天，Google 和百度抓到的还是旧页面，新页面的收录为零。",[11,135,136],{},"查日志发现，蜘蛛请求的返回内容来自 CDN 缓存，缓存 key 没带版本号，HTML 的缓存时间被设成了 7 天。",[11,138,139],{},"我们把 HTML 的缓存策略改成\"短缓存 + 主动刷新\"，重新推送 CDN，第二天蜘蛛就抓到了新页面。但已经浪费了三天，加上恢复，排名掉了两周。",[15,141,142],{"id":142},"缓存和抓取的关系",[11,144,145],{},"搜索引擎抓的是 CDN 返回的内容，不是你源站的内容。CDN 缓存错，它看到的就是旧版本。",[11,147,148],{},"更麻烦的是缓存不一致：不同节点缓存的内容不同，蜘蛛今天抓到一个版本、明天抓到另一个版本，会被判定为页面不稳定。",[15,150,151],{"id":151},"三个配置原则",[11,153,154],{},"第一，HTML 不做长缓存。HTML 用短缓存（比如 5 分钟）或者协商缓存，图片、JS、CSS 这些带哈希的静态资源可以长缓存。",[11,156,157],{},"第二，缓存 key 带上版本。改版时版本号变，缓存自然失效，不用手动刷。",[11,159,160],{},"第三，按 UA 区分缓存要谨慎。有些站按设备做不同页面，缓存 key 里必须带 UA 维度，否则手机用户拿到桌面版。",[15,162,163],{"id":163},"怎么验证",[11,165,166],{},"改版或发布后，做三件事：",[11,168,169],{},"用 curl 请求目标 URL，看返回头里的缓存状态（HIT\u002FMISS）、缓存时间、以及内容是不是新的。",[11,171,172],{},"用搜索引擎的抓取工具（GSC 的 URL 检查、百度的抓取诊断）抓一次，看拿到的 HTML 是不是新版本。",[11,174,175],{},"在不同地区、不同网络下各请求一次，确认缓存一致。我们一般抽 3 个城市。",[15,177,178],{"id":178},"另外两个坑",[11,180,181],{},"第一个，CDN 默认缓存 HTML。很多云厂商的默认规则是\"静态资源缓存、HTML 不缓存\"，但也有些套餐默认缓存所有内容。上线前一定确认。",[11,183,184],{},"第二个，回源 HOST 配错。CDN 回源到错误的域名，拿到的是默认站点或者 404，蜘蛛看到的就是空页面。这个错误很隐蔽，查日志能看到大量 404 但源站正常。",[15,186,187],{"id":187},"一个流程建议",[11,189,190],{},"我们把\"CDN 缓存检查\"加进了上线清单：改版、迁移、大版本发布，发布后 10 分钟内必查。",[11,192,193],{},"检查项就三条：HTML 缓存时间、缓存 key 是否带版本、蜘蛛抓到的内容是否是新版本。",[15,195,196],{"id":196},"判断",[11,198,199],{},"CDN 是技术 SEO 里最容易被忽略的一层，因为它不在代码里，在基础设施里。开发不管、运维不懂 SEO，出了问题两边都查不到。",[11,201,202],{},"改版前把缓存策略定好，比改版后救火便宜得多。",{"title":95,"searchDepth":96,"depth":96,"links":204},[205,206,207,208,209,210,211],{"id":130,"depth":96,"text":130},{"id":142,"depth":96,"text":142},{"id":151,"depth":96,"text":151},{"id":163,"depth":96,"text":163},{"id":178,"depth":96,"text":178},{"id":187,"depth":96,"text":187},{"id":196,"depth":96,"text":196},"2026-08-20","一次改版上线三天，搜索引擎抓到的还是旧页面，原因是 CDN 缓存把 HTML 缓存了 7 天。缓存和抓取的关系、三个配置原则、怎么验证都在这篇，附我们踩过的两次坑。这层不出问题则已，出问题就是全站级别的，别等出事再查。",{},"\u002Fblog\u002Fcdn-cache-crawl",{"title":122,"description":213},"blog\u002Fcdn-cache-crawl",[219,220,221],"CDN","缓存","抓取","ZyS6fM8EZ9kMvRp4SEEoxnE60e0MoaQYCVWPRnfVehQ",{"id":224,"title":225,"author":6,"body":226,"canonical":104,"category":314,"cover":104,"date":315,"description":316,"draft":108,"extension":109,"keywords":104,"meta":317,"navigation":111,"noindex":108,"ogImage":104,"path":318,"seo":319,"seoDescription":104,"seoTitle":104,"stem":320,"tags":321,"updated":104,"__hash__":325},"blog\u002Fblog\u002Fdata-post-structure.md","数据文的结构：先给反常识结论，再交代口径",{"type":8,"value":227,"toc":304},[228,231,234,237,240,243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,289,292,295,298,301],[11,229,230],{},"数据文最容易写成报告：先讲背景，再列数据，最后给一堆结论。读者一般读三段就关掉。我们的结构是反过来的：第一段就给那个最反常识的结论，然后才解释数据从哪来。",[15,232,233],{"id":233},"第一段只做一件事",[11,235,236],{},"给一个反常识的结论，并且带上数字。比如“我们把 1260 个长尾词按搜索量排序，前 30 个选题里只有 4 个带来了试用”。",[11,238,239],{},"这一段决定读者要不要继续。数据文的价值在前 100 字，不在后面的图表。",[15,241,242],{"id":242},"第二段交代来源和口径",[11,244,245],{},"样本多少、时间范围、怎么统计、有哪些已知偏差。这一段会让文章显得可信，也是别人愿意引用的原因。",[11,247,248],{},"口径要写在正文里，不要塞进脚注。AI 摘录时看不到脚注。",[15,250,251],{"id":251},"第三段给两三个细分发现",[11,253,254],{},"不要给十个。挑三个最有用、最能支撑结论的。每个发现配一个具体例子。",[11,256,257],{},"我们的习惯是：一个发现对应一句“所以该怎么做”。只有数据没有行动建议，读者读完会觉得看了一场热闹。",[15,259,260],{"id":260},"第四段写适用边界",[11,262,263],{},"什么情况下这个结论不成立。这一段最容易被省，也最加分。",[11,265,266],{},"写清边界，说明你真的理解数据，不是拿几个数字凑观点。",[15,268,269],{"id":269},"图表放几张",[11,271,272],{},"两三张就够。每张图只讲一件事，标题写结论，不写“图 1 数据分布”这种。",[11,274,275],{},"图里的数字要能被正文引用，别放一张读者看不懂的复杂图。",[15,277,278],{"id":278},"一个具体的对比",[11,280,281],{},"同一批数据，我们写过两版。第一版按“数据概览、分布、趋势、结论”排，阅读完成率 34%。第二版按“结论、口径、发现、边界”排，完成率 61%。",[11,283,284],{},"内容没变，顺序变了。",[15,286,288],{"id":287},"一个时间上的提醒","## 一个时间上的提醒",[11,290,291],{},"数据文有保鲜期。我们 2026 年 3 月发的那篇用了 2025 年全年数据，到 10 月就该更新了。数据文的日期比观点文更敏感，读者会看数据到哪一天。",[15,293,294],{"id":294},"数据文的两个风险",[11,296,297],{},"一是样本太小却下大结论。我们的规矩是样本少于 30 个不出百分比结论。",[11,299,300],{},"二是数据过时。数据文里要写清数据截止时间，超过一年就该更新或者下架。",[11,302,303],{},"写清数据截止时间这一行，也能避免读者把旧结论当新结论用。",{"title":95,"searchDepth":96,"depth":96,"links":305},[306,307,308,309,310,311,312,313],{"id":233,"depth":96,"text":233},{"id":242,"depth":96,"text":242},{"id":251,"depth":96,"text":251},{"id":260,"depth":96,"text":260},{"id":269,"depth":96,"text":269},{"id":278,"depth":96,"text":278},{"id":287,"depth":96,"text":288},{"id":294,"depth":96,"text":294},"内容运营","2026-08-22","数据文不是把数字堆出来。我们固定四段结构：反常识结论、数据来源和口径、两三个细分发现、适用边界。顺序错了，读者读三段就关掉。",{},"\u002Fblog\u002Fdata-post-structure",{"title":225,"description":316},"blog\u002Fdata-post-structure",[322,323,324],"数据文","内容结构","信息增益","nXnHM-VLBbFYaF9iFo6xNcVYQtEcFQDCImOG6MNlBWk",1794088102604]