[{"data":1,"prerenderedAt":333},["ShallowReactive",2],{"blog-js-bundle-load-order":3,"blog-prev-js-bundle-load-order":120,"blog-next-js-bundle-load-order":228},{"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\u002Fjs-bundle-load-order.md","JS 包体拆完还是慢，问题在加载顺序","元析智能",{"type":8,"value":9,"toc":93},"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],[11,12,13],"p",{},"2026 年 7 月一个客户说包体已经拆过了，从 2.1 兆降到 600K，首屏还是 2.8 秒。我打开 DevTools 一看，600K 里有 400K 是首屏根本用不到的东西，只是被放在了主包里。",[15,16,17],"h2",{"id":17},"拆包解决的是什么",[11,19,20],{},"它解决下载量，让首屏不用等全部 JS 下完。但首屏时间不只取决于下载，还取决于解析、执行、以及依赖的先后顺序。",[11,22,23],{},"一个 300K 的包，在 4 倍 CPU 降速下执行要一秒多。拆成三个 100K 的包并行下载，执行时间没变。",[11,25,26],{},"所以拆包只是第一步，关键是让主线程上只跑首屏需要的东西。",[15,28,29],{"id":29},"三种常见的拆错",[11,31,32],{},"第一种，把首屏依赖拆进了懒加载。按钮点击才加载的组件里，包含了首屏渲染要用的工具函数，结果首屏卡住等它。",[11,34,35],{},"第二种，拆得太碎。几十个小 chunk，每个都要一个请求，HTTP\u002F2 下虽然能复用连接，但请求排队和依赖解析反而更慢。",[11,37,38],{},"第三种，vendor 全塞一个包。所有第三方库打成一个 1 兆的文件，首屏只用到其中一个，剩下全是白下。",[15,40,41],{"id":41},"加载顺序怎么排",[11,43,44],{},"首屏关键 chunk 用 modulepreload 提前拿，放在 head 里，让它和 HTML 并行。",[11,46,47],{},"非关键的用 defer，别用 async。async 的执行时机不确定，可能抢在关键脚本前面跑，造成页面空白。",[11,49,50],{},"runtime 和 manifest 内联到 HTML 里，省一个请求，也避免版本错配。",[15,52,53],{"id":53},"真正的大头往往不在业务代码",[11,55,56],{},"我们拆过十几个站，主包里最大的三样东西通常是：全量引入的工具库、图标库、polyfill。",[11,58,59],{},"工具库只用了两个函数，却把整个库打进来；图标库引了一千个图标，页面只用八个；polyfill 给现代浏览器也塞了一份。",[11,61,62],{},"这三样加起来能占主包的一半，砍掉比拆十次都有用。",[15,64,65],{"id":65},"怎么判断哪里该砍",[11,67,68],{},"用 bundle 分析工具看每个模块的体积占比，先砍排名前十的。",[11,70,71],{},"再用代码覆盖率看首屏执行了多少。我们见过首屏执行率 12% 的页面，意思是 88% 的 JS 白跑了。",[11,73,74],{},"最后在 4 倍 CPU 降速下测。桌面跑得欢的代码，在中端安卓机上可能是灾难。",[15,76,77],{"id":77},"一个可以立刻做的检查",[11,79,80],{},"打开 DevTools 的 Coverage 面板，录一次首屏加载，它会告诉你每个 JS 文件执行了多少、浪费了多少。",[11,82,83],{},"超过一半没执行的包，就是该拆或者该砍的。这个检查十分钟能做完，比看任何分析报告都直接。",[15,85,86],{"id":86},"一个判断",[11,88,89],{},"包体优化里，砍掉不用的代码比拆包收益大，排好加载顺序比压缩收益大，压缩只是最后一步。",[11,91,92],{},"很多团队把顺序做反了：先上压缩和 CDN，再研究拆包，最后才想起来问这些代码到底用不用。这个顺序应该倒过来。",{"title":94,"searchDepth":95,"depth":95,"links":96},"",2,[97,98,99,100,101,102,103],{"id":17,"depth":95,"text":17},{"id":29,"depth":95,"text":29},{"id":41,"depth":95,"text":41},{"id":53,"depth":95,"text":53},{"id":65,"depth":95,"text":65},{"id":77,"depth":95,"text":77},{"id":86,"depth":95,"text":86},null,"技术SEO","2026-06-23","一个站 JS 从 2.1 兆拆到 600K，首屏还是 2.8 秒。拆包解决下载，解决不了执行和依赖顺序。这篇写拆错的三种情况、关键 chunk 怎么排、真正的大头在哪。",false,"md",{},true,"\u002Fblog\u002Fjs-bundle-load-order",{"title":5,"description":107},"blog\u002Fjs-bundle-load-order",[116,117,118],"JavaScript","代码分割","首屏","I_h685YtX-z_-Oh3_MV54zfZl_CDDd1Ub-Pr9GoR4QA",{"id":121,"title":122,"author":6,"body":123,"canonical":104,"category":105,"cover":104,"date":217,"description":218,"draft":108,"extension":109,"keywords":104,"meta":219,"navigation":111,"noindex":108,"ogImage":104,"path":220,"seo":221,"seoDescription":104,"seoTitle":104,"stem":222,"tags":223,"updated":104,"__hash__":227},"blog\u002Fblog\u002Ffaceted-navigation-crawl.md","筛选参数把抓取预算吃光了：电商站的 5 个处理规则",{"type":8,"value":124,"toc":207},[125,128,131,134,137,141,144,147,151,162,165,169,172,175,179,182,185,189,192,195,198,201,204],[11,126,127],{},"一个 B2B 电商站的筛选组合生成了 6 万多个 URL，抓取预算的 62% 花在参数页上，核心产品页一周才被抓一次。我们用 5 条规则把参数页从 6 万压到 800。",[15,129,130],{"id":130},"先算清楚参数页有多少",[11,132,133],{},"三个筛选维度各 10 个值，组合起来理论上是 1000 种；如果再叠加排序、页码、视图模式，实际 URL 能到几万个。",[11,135,136],{},"查法：从日志里把带问号的 URL 全提出来，按参数名分组，数每个参数组合的抓取次数和收录数。我们那个客户，日志里 62% 的抓取请求落在参数页，而这些页面的收录率只有 8%。",[15,138,140],{"id":139},"规则一只保留有搜索需求的组合","规则一：只保留有搜索需求的组合",[11,142,143],{},"不是所有筛选组合都值得收录。用关键词工具查\"产品词 + 筛选值\"有没有搜索量，有量的保留，没量的不收录。",[11,145,146],{},"那个客户 6 万多个组合里，真正有搜索需求的只有 800 个左右。",[15,148,150],{"id":149},"规则二参数顺序统一去掉无意义参数","规则二：参数顺序统一，去掉无意义参数",[11,152,153,157,158,161],{},[154,155,156],"code",{},"?color=red&size=1"," 和 ",[154,159,160],{},"?size=1&color=red"," 是两个 URL，内容一样。排序参数、追踪参数、会话参数，全部规范化或者屏蔽。",[11,163,164],{},"做法：服务端对参数排序，追踪参数用 canonical 合并，视图模式参数直接不走 URL。",[15,166,168],{"id":167},"规则三没有搜索量的组合用-robots-屏蔽","规则三：没有搜索量的组合用 robots 屏蔽",[11,170,171],{},"屏蔽的是\"组合页\"，不是\"单个筛选值页\"。比如颜色筛选可以收录，颜色 + 尺码 + 价格区间的三重叠组合就屏蔽。",[11,173,174],{},"robots 屏蔽的页面不会被抓取，也就不会浪费预算。代价是这些页面也拿不到排名，但它们本来也没有排名。",[15,176,178],{"id":177},"规则四筛选页要有独立价值","规则四：筛选页要有独立价值",[11,180,181],{},"保留下来的 800 个筛选页，不能只是列表换个顺序。我们给每个页面加了筛选条件说明、适用场景、相关产品推荐，让它有独立的内容价值。",[11,183,184],{},"这一步决定了收录之后能不能排上去。只靠参数组合的页面，收录了也是零展现。",[15,186,188],{"id":187},"规则五内链只指向有价值的筛选页","规则五：内链只指向有价值的筛选页",[11,190,191],{},"导航和列表页里的筛选链接，只链到保留下来的 800 个页面。无价值的组合不生成可点击链接，减少蜘蛛的发现路径。",[15,193,194],{"id":194},"结果",[11,196,197],{},"调整从 2026 年 1 月开始，做了 6 周。第 8 周看数据：抓取请求里参数页占比从 62% 降到 9%，核心产品页的平均抓取间隔从 7 天缩到 1.5 天，有排名的关键词从 1200 个涨到 3100 个。",[11,199,200],{},"询盘量第 10 周开始涨，两个月后比调整前高 40%。",[15,202,203],{"id":203},"一句判断",[11,205,206],{},"筛选页不是\"要不要收录\"的问题，是\"哪些组合值得收录\"的问题。先算清楚数量和需求，再决定屏蔽还是保留，别一刀切全屏蔽——那会丢掉真正有搜索量的长尾。",{"title":94,"searchDepth":95,"depth":95,"links":208},[209,210,211,212,213,214,215,216],{"id":130,"depth":95,"text":130},{"id":139,"depth":95,"text":140},{"id":149,"depth":95,"text":150},{"id":167,"depth":95,"text":168},{"id":177,"depth":95,"text":178},{"id":187,"depth":95,"text":188},{"id":194,"depth":95,"text":194},{"id":203,"depth":95,"text":203},"2026-06-22","一个 B2B 电商站的筛选组合生成了 6 万多个 URL，抓取预算的 62% 花在参数页上，核心产品页一周才被抓一次。我们用 5 条规则把参数页从 6 万压到 800，收录率和询盘都回来了。照着做能把参数页数量压掉 90%，还能把收录率拉回来。",{},"\u002Fblog\u002Ffaceted-navigation-crawl",{"title":122,"description":218},"blog\u002Ffaceted-navigation-crawl",[224,225,226],"筛选参数","抓取预算","电商SEO","Rci4uxEa3PhEdxr9-z2RKNwbjuuZvV72GCr1U7bkajk",{"id":229,"title":230,"author":6,"body":231,"canonical":104,"category":321,"cover":104,"date":322,"description":323,"draft":108,"extension":109,"keywords":104,"meta":324,"navigation":111,"noindex":108,"ogImage":104,"path":325,"seo":326,"seoDescription":104,"seoTitle":104,"stem":327,"tags":328,"updated":104,"__hash__":332},"blog\u002Fblog\u002Fkeyword-research-without-tools.md","不买关键词工具能不能挖词，能，但慢三倍",{"type":8,"value":232,"toc":311},[233,236,240,243,246,250,253,256,260,263,266,270,273,276,279,282,285,288,291,294,296,299,302,305,308],[11,234,235],{},"不买关键词工具也能挖词，只是慢三倍。2026 年 1 月我们给一个预算为零的客户做过一次，三个人三周，挖出 210 个候选词，进排期的 31 个。没花一分钱，靠的是四个免费来源。",[15,237,239],{"id":238},"第一个来源搜索后台","第一个来源：搜索后台",[11,241,242],{},"GSC 和百度搜索资源平台的查询数据，是唯一免费又真实的搜索量代理。最近 28 天有曝光、排名在 10 到 50 名之间的查询，就是现成的机会词表。",[11,244,245],{},"这个来源比工具准，因为它是你自己的真实数据，不带估算。",[15,247,249],{"id":248},"第二个来源站内搜索","第二个来源：站内搜索",[11,251,252],{},"用户在你站内搜过什么，说明他想找什么但没找到。这类词往往正是该写的内容。",[11,254,255],{},"站内搜索数据一般在统计工具里，或者从产品日志里导。有的话别浪费。",[15,257,259],{"id":258},"第三个来源客服工单","第三个来源：客服工单",[11,261,262],{},"客户描述问题的原话，几乎就是搜索词。报错原文、功能叫法、操作步骤，三类都能直接变成选题。",[11,264,265],{},"工单里的词工具一般挖不出来，量太小，被当噪音过滤了。",[15,267,269],{"id":268},"第四个来源竞品目录和文档搜索","第四个来源：竞品目录和文档搜索",[11,271,272],{},"看竞品写了什么，看他没写什么；看他文档的搜索框提示，看他的 FAQ 结构。",[11,274,275],{},"这一步不是为了抄，是为了确认哪些问题已经有人验证过有需求。",[15,277,278],{"id":278},"没工具最缺什么",[11,280,281],{},"缺搜索量。没有量，就没法排序，只能靠判断。",[11,283,284],{},"我们的替代办法：用搜索后台的曝光当量级，用搜索结果页的竞争程度当机会分，两个加起来排优先级。粗糙，但够用。",[15,286,287],{"id":287},"慢在哪",[11,289,290],{},"慢在没法批量。工具能一次导出两万个词，人工只能一个个过。三周时间里有两周花在整理和核对上。",[11,292,293],{},"如果词库规模超过 500 个词，或者要做多个语言，还是买工具。手工的成本比订阅费高。",[15,295,86],{"id":86},[11,297,298],{},"工具解决的是规模，不解决判断。没有工具的时候，你反而会更认真地看每个词的搜索结果。",[15,300,301],{"id":301},"一个人做的话",[11,303,304],{},"一个人用免费来源挖词，一周能稳定产出 20 到 30 个候选，够一个月写。",[11,306,307],{},"别贪多。词表太大反而没人用，40 个里面挑出 8 个，写完再挖下一批。",[11,309,310],{},"我们那个客户后来买了工具，但选词的标准还是那三条：有没有决策信号、竞品做没做好、我们有没有素材。这三条工具给不了。",{"title":94,"searchDepth":95,"depth":95,"links":312},[313,314,315,316,317,318,319,320],{"id":238,"depth":95,"text":239},{"id":248,"depth":95,"text":249},{"id":258,"depth":95,"text":259},{"id":268,"depth":95,"text":269},{"id":278,"depth":95,"text":278},{"id":287,"depth":95,"text":287},{"id":86,"depth":95,"text":86},{"id":301,"depth":95,"text":301},"SEO","2026-06-24","预算为零也能挖词。四个免费来源：搜索后台、站内搜索、客服工单、竞品目录。我们给一个零预算客户做了三周，挖出 210 个词，进排期的 31 个。",{},"\u002Fblog\u002Fkeyword-research-without-tools",{"title":230,"description":323},"blog\u002Fkeyword-research-without-tools",[329,330,331],"关键词研究","免费工具","小团队","tVGK11VKfwGyUm1HG0kFw6W5_Gx91Fzc-Km3Wtugn4E",1794088104439]