浏览器地址栏里敲下回车，户端页面加载的户端那三秒钟，大多数人盯着的户端是进度条。我盯着的户端是Network面板——那里面每一行请求都在讲一个故事：谁先到，谁后到，户端谁卡了半秒，户端谁偷偷多传了200KB没用的户端JSON。

Web客户端这东西，户端说到底是户端运行在用户设备上的那层皮。它不碰数据库，户端不写业务逻辑，户端但用户骂的户端永远是它。后端挂了，户端用户看到的户端是"网络异常，请稍后重试"；客户端渲染慢了，户端用户看到的是白屏。你说冤不冤？

一个真实的卡顿案例

去年接手过一个后台管理系统，列表页每次切换tab都要等两秒。查了一圈，后端接口响应稳定在80ms，问题出在前端：每次切换都重新请求全量数据，然后整个表格组件销毁重建。2000行数据，每行12个字段，DOM节点瞬间暴涨，浏览器主线程直接堵死。

改法很简单——缓存已请求过的tab数据，表格用虚拟滚动。改完切换tab降到200ms以内。就这么点事，之前没人愿意翻代码。

我的判断是：大部分Web客户端的性能问题，不是技术难题，是没人愿意弯腰捡起来看。大家更乐意讨论框架选型、微前端架构，却懒得打开Performance面板录一段火焰图。

客户端不只是"展示层"

很多人把Web客户端当成后端的附属品——后端给什么就渲染什么。这种思路在2015年之前或许成立，现在不行了。用户设备上的CPU、内存、网络状况千差万别，客户端必须自己扛起状态管理、缓存策略、错误降级这些事。

举个例子。一个电商详情页，后端返回商品信息、库存、价格、推荐列表。如果客户端老老实实等所有接口都回来再渲染，用户看到的就是长时间白屏。实际做法是：商品主图和信息先渲染，库存和推荐异步填充。用户感知到的加载时间从1.5秒降到300毫秒。这不是后端能解决的问题，必须客户端自己决策。

那些被忽视的细节

Web客户端有个特点：它跑在别人的浏览器里。这意味着你永远不知道用户用的是Chrome 120还是某个套壳的WebView，不知道他的网络是5G还是地铁里的2G。我见过一个页面在开发者机器上跑得飞快，到了用户手里卡成幻灯片——因为用户设备上有个全局的CSS滤镜，把整个页面的合成层拖垮了。

还有内存泄漏。单页应用切了二十个路由，每个路由的组件都绑了window的resize事件，销毁时忘了解绑。跑半小时，内存从80MB涨到600MB，页面开始卡顿。用户只会说"这破网站越用越卡"，不会告诉你具体哪一步出了问题。

我的习惯是：每次上线前，用低端安卓机跑一遍。不是模拟器，是真机。模拟器上的性能数据太理想了，没有参考价值。

写客户端需要一点"不信任"

不信任后端返回的数据格式永远正确，不信任网络永远稳定，不信任用户的设备性能足够。这种"不信任"不是消极，是职业素养。每一个接口调用都要考虑失败的情况，每一个渲染分支都要想好降级方案。

我见过一个团队，接口返回的数组字段偶尔是null，前端直接.map()报错，整个页面白屏。加一行防御性判断就能解决的事，硬是拖了三天才定位到。不是技术难，是心态问题——总觉得"后端应该不会犯这种错"。

Web客户端这活儿，门槛不高，但做好很难。它要求你既懂浏览器渲染原理，又懂用户心理；既能写业务代码，又能调性能瓶颈。说白了，得有点强迫症，看到Network面板里有红色的请求就浑身不舒服。