小程序要先定包体，再写代码。微信的硬线有三条：主包和每个分包都不能超过 2M，所有分包加起来不超过 30M，服务商代开发的不超过 20M。写第一行代码之前，把这三条写进项目文档。
这跟坐飞机一样：随身登机箱有重量上限，超一点柜台就不收，托运还有总量。箱子多大是出门前定的事，不是到了机场再往外掏东西。
分包是把小程序切成几个箱子。用户第一次只拿主包，进到哪个功能，再取对应那个箱子。切得好，第一次打开就快；切不好，等于白切。
线上减肥最贵。改页面路径、重新分包、重做回归测试，都得再来一遍。定额要定在拦你的线之前。等它拦住上传，能砍的只剩功能了。
四条线记牢，出处都在微信官方文档。单个包不超过 2M，主包和分包同一个标准。M 是文件大小的单位，1M 约等于一千个 KB。所有分包合计不超过 30M，服务商代开发的小程序是 20M（分包加载）。首屏不超过 5 秒，指的是用户点开到你看见第一屏内容（体验评分·性能）。
上传的时候工具会先算一遍包体。超了直接弹红字，连上传都不让点。所以这条线不是你说了算，是平台说了算。
30M 看着很大，其实不经用。一个演示视频、一个富文本编辑器，就能吃掉一半额度。
这两类线性质不同。2M 是硬限，超了连预览和上传都过不去，工具直接报错。5 秒是评分线，超了不掉功能，掉的是用户。
自己再紧一档。主包定 1.5M，留四分之一余量。主包里常驻的是底部导航页、公共组件和基础样式。正常迭代一个月净增几十 KB（工程经验，非官方口径）。留 25%，够一个季度不加干预地迭代。
首屏也可以自己收紧。平台线是 5 秒，自己定 3 秒，留 2 秒给低端机和弱网（工程经验，非官方口径）。这条比包体更该盯，因为用户等的是屏幕，不是文件。3 秒这个数是这样反推的：1.5M 主包在中等网络下的下载时间，加上第一个请求和第一次渲染。
怎么看自己现在多大。第一步，打开微信开发者工具，点右上角「详情」，看「基本信息」里那一栏“代码包大小”（项目页卡）。主包、各分包、合计，三个数都在里面。
第二步，想知道是哪个文件夹占地方，在「详情」里的「本地代码」点「代码依赖分析」（代码静态依赖分析）。它按体积从大到小列出每个文件，还会单独标出没用到的文件。删之前先看这一栏。
看不到数等于没定。分包配了但那一栏是空的，通常是分包没生效：分包目录下没放独立页面。
越线以后按这个顺序砍，前三步都不动页面结构。顺序不是随便排的，越往后改动越大。
第一步砍图片。一张没压过的大图能顶几十个页面。动作是三步。先转成 webp（一种体积更小的图片格式）。再按屏幕实际宽度裁一遍。首屏以外的图，改成滑到才加载。怎么知道生效：依赖分析里排最前面那几张图不见了，主包少了几百 KB。同一张 4M 的实拍图，压完通常能到 300KB 以内（工程经验，非官方口径）。
第二步砍第三方工具包。工具包就是别人写好、你直接拿来用的功能模块，比如地图、直播、富文本编辑器。它们不是每个页面都用得上，挪进分包，用到才下载。怎么知道生效：主包的依赖列表里不再出现它。
第三步合并埋点。埋点是记录用户点了哪儿的代码。首屏打开时不要一条一条往外发，攒一批再发。怎么知道生效：首屏那几个请求里，上报类的请求没有了。
拆包不是免费的。每拆一次，页面之间的跳转、参数怎么传、公共资源放哪儿，都要重新捋一遍。
三步做完还超，最后才拆包。拆包要改页面路径和跳转，最容易出问题。放最后不是因为它最有效，是因为它最贵。
拆包有个坑要提前知道。两个分包不能共用同一个组件，共用了会编译报错。动手之前先把公共部分挪进主包，或者各留一份。
还有一种省事的配法：支付页、活动页这类必须一次到达的页面，配成独立分包。用户从这类页面进来，不下载主包也能用。
首屏那 5 秒要单独看。它其实分四段：下载代码包、准备好运行环境、发出第一个请求、画出第一屏。前两段归包体，后两段归接口和页面结构。
分不清是哪一段，就看下载花了多少。真机打开调试面板，看启动总耗时里下载代码包占的比例。超过一半，是包体的事，回去砍包。不到三成，包体不是瓶颈，去合并首屏接口、把不急的字段挪到后面取。
有一个数常被忽略：页面上元素的个数。一页最好少于 1000 个元素，层级不超过 30 层（体验评分·性能）。一个列表一次渲染两百行，界面就会卡。动作是分页，先渲染看得见的那十几行。
请求也有定额。耗时超过 0.3 秒的接口，同时发起的不超过 10 个。首屏一次甩出十几个接口的页面很常见。动作是把首屏那几个接口合成一个，其余的等首屏画完再发。
上线之后还要定期看。开发者工具里有「体验评分」，跑一遍能看到首屏、渲染、请求各项的得分。首屏和渲染两项连续两次不达标，就该排一次优化，别等用户反馈。
定额要落在三个地方。一是需求评审时写进文档。二是每次发版前看一眼包体变化。三是发版单上填一行主包大小。三个地方都没有，那句话就只是文档里的一段。
包体是少数不会自己变好的指标。功能只会加，图只会多，包只会变大。所以它需要一条固定的线，而不是每次上线前临时商量。
包体能确切量出来，这是它比别的体验指标好办的地方。别等它拦住上传才想起来——那时候能砍的只剩功能。
最后一句是给写方案的人。包体定额写进合同或验收单，才有约束力。写在技术方案里，第一个赶工期的月就会被绕过。
验收单上加一句就够：主包不超过 1.5M，分包合计不超过 30M，超了整改后再上线。这句话比任何优化技巧都管用。
