创业公司技术合伙人路过这轮记录一个性能优化的实战案例公司内部系统的项目工时表单字段多、联动多配完业务逻辑后页面卡到没人想用。最后靠一套懒加载设计救回来请求数砍掉八成首屏时间从五秒降到一秒内。过程记录如下。这个案例想说的不只是结果更是低代码时代的一个新功课配置的自由度越高性能的账越没人管。写代码的工程师会本能掂量请求开销配表单的业务同学不会。这个断层得有人补。我们公司二十来人我一个人补再大点的团队性能评审流程补。一、问题出在哪1.1 一个越配越卡的表单项目工时表单是全公司每天要用的核心表单项目字段联动任务字段任务字段联动工时标准部门字段联动审批人还有成本中心、客户标签一堆次级联动。低代码平台上配置起来都是勾选的事配完功能全对就是慢。用户反馈很直接点开表单泡杯茶回来还在转圈。填一张工时两分钟等表单加载一分钟怨声载道。最扎心的一条反馈来自销售同事填工时的等待时间比见客户路上的红灯还多。工具本该省时间结果先吃掉一截。1.2 抓包看真相动手优化前先抓包看清楚慢在哪。结果吓一跳表单每次打开要发四十七个请求——项目列表、任务列表、部门树、成员列表、历史工时、审批配置加上各种联动的选项集全在页面加载时一拥而上。四十七个请求里绝大多数拉的数据此刻根本用不上用户还没选项目任务列表就先加载了没选部门审批人配置已经到了。典型的全家桶式加载把可能要用的全先拿上代价是每次打开都在搬家。更冤的是这些搬来的东西大多原封不动退回去一张工单只用到一个项目的数据另外四十几个项目的列表白拉了。1.3 冗余请求的三个来源拆解下来冗余请求有三个来源一是联动数据的预加载平台默认把所有关联选项提前拉齐二是重复请求两个联动共用一份数据源却各拉各的三是无差别加载移动端和桌面端拉同样的全量数据移动端根本展示不完。二、懒加载的设计2.0 设计的分寸动手前先定分寸懒加载不能牺牲功能正确性。有些联动是强依赖——不选项目任务字段必须置灰这种前置状态判断用的是本地规则不发请求。把能用规则解决的和必须请求解决的分开懒加载才不会懒出毛病。2.1 核心原则数据等需求懒加载的原则一句话数据等需求需求出现才加载。用户选了项目再去拉这个项目下的任务用户点了成本中心字段再去拉成本中心列表。数据从提前搬运变成按需抵达。这背后还有一层体验设计等待的位置从打开表单挪到了填写中途。打开时的一秒内响应给了用户好头印象字段切换时偶尔两三百毫秒的加载用户在打字间隙里根本察觉不到。等得巧比不等更高级。这个原则的哲学是相信用户的注意力是串行的一张表单里用户同一时刻只填一个字段提前加载其它字段的数据纯属浪费。四十七个请求的方案是给人搬了一座仓库懒加载是用户要什么递什么。2.2 事件驱动的加载器实现上写了一个统一的懒加载器管理所有延迟数据constlazyLoader{cache:newMap(),on(field,event,loader){document.querySelector([data-field${field}]).addEventListener(event,async(){constkeyloader.key();if(this.cache.has(key))returnthis.cache.get(key);constelshowSkeleton(field);constdataawaitloader.fetch();this.cache.set(key,data);el.remove();returnloader.apply(data);});}};lazyLoader.on(project,change,{key:()tasks:${form.projectId},fetch:()api.getTasks(form.projectId),apply:(tasks)fillOptions(task,tasks)});加载器带缓存同键值的数据只拉一次切换字段再切回来不打二次请求。骨架屏占位加载中的状态可感知。核心就这么多没有框架魔法事件驱动加缓存朴素但管用。整个加载器不到百行代码接进低代码页面只花了半天。性能优化不一定都要大动干戈找准病灶小刀也灵。2.3 预加载的例外懒加载不是教条地一刀切。两个例外保留预加载高频路径的数据统计下来八成用户打开表单头一件事就是选项目项目列表保留首屏加载联动链深的数据选项目到任务到工时标准三层联动第二层加载时顺手预取第三层用户无感衔接。原则是死的数据是活的哪里该懒哪里该预看用户行为统计说话不靠感觉。统计方法也简单表单平台埋点记录字段焦点顺序跑两周就有答案。让数据替设计做决定比团队里争论该懒该预省心得多。2.4 移动端单独裁剪移动端方案更激进首屏只加载必填字段的选项其余全部懒加载选项列表超五十条的改搜索式加载输入关键词才拉匹配结果。移动端网络抖、屏幕小更经不起全家桶式加载的折腾。裁剪后移动端首屏只要三个请求车间同事在信号差的角落也能顺畅填报。做性能优化时把最差的设备、最差的网络放进考虑范围优化的下限才够高。三、优化效果3.0 效果的归因数据好看之后先做归因确认提升来自优化本身而非别的原因。对照组是没改造的旧表单同期它的表现纹丝不动改造组的首屏曲线陡降。归因清楚这套打法才能复制到下一个表单而不是碰巧好了一次。3.1 数据对比上线后数据说话首屏请求数从四十七降到九个首屏时间从五秒压到一秒内填完整张表单的总请求数均值二十六个比原来还少近半——缓存命中率四成等于四成请求根本没发生。用户端的反馈最有说服力没人再提表单卡工时填报的及时率从七成回到九成五。工具顺手的程度直接写进了使用数据里。这个案例后来成了我说服团队重视性能的常备弹药性能不是技术洁癖是业务指标。3.2 一个副产物流量账单意外的副产物是服务器流量降了六成。全公司几十人每天开几十次表单每次少搬三十几个请求的数据累积效应可观。性能优化省的不只是体验还有真金白银的带宽费。小公司省钱的路子不多这种顺手的节省更值得珍惜。四、经验沉淀4.00 团队的认知升级技术动作之外这轮优化最大的产出是认知升级业务同学头一回意识到每勾一个联动都有成本主动来问这个联动要不要加。性能意识从技术团队的独角戏变成了全团队的常识。这种转变比任何一次优化本身都值钱。4.1 优化前先测量这轮最深的体会优化前先抓包测量。不测量就动手容易把力气花在无关紧要的地方测量完问题往往自己跳出来——四十七个请求一摆谁都知道该干什么。先测量、再优化、后复测这个顺序不能乱。抓包那十分钟抵得上盲目优化的一礼拜。工程师的直觉在性能问题面前经常失灵数据不会。4.2 联动是性能黑洞低代码平台的联动配置方便但每个联动背后都是数据依赖。字段勾选一时爽联动堆积时性能火葬场。我们的对策联动超过三层的表单强制过一次性能评审把懒加载设计当成标配动作。评审清单也就五条请求数、联动层级、缓存策略、移动端裁剪、首屏时间。五条全过才放行业务同学从嫌麻烦到习惯也就两个月。4.3 缓存策略要想清楚失效缓存带来性能也带来新鲜度问题。任务列表缓存了后台改了任务怎么办我们的做法表单每次保存成功后清掉相关缓存下次加载拿新数据。牺牲一点缓存命中换数据绝对新鲜工时场景这个取舍划算。反例也想过一个如果是库存查询这类要求强新鲜的场景缓存就要缩短或干脆不缓存。同一个技术两个场景两个答案取舍的秤永远架在业务上。缓存失效策略没有万能解按业务对新鲜度的容忍度定。4.4 给团队立个规矩这轮优化后给团队立了条规矩新表单上线前必须过请求数检查首屏超过十五个请求打回重做。规矩比自觉好用性能这东西不设门槛就会悄悄滑坡设了门槛才能长期在线。门槛生效的标志是后来有个新表单被自动打回业务同学自己按清单改到达标才提交过来全程没人吵架。规矩立住了就不再需要人去守。