B端系统的可视化大屏，常常是 "演示时惊艳、上线后崩溃" 的重灾区。作为产品经理，可以不懂前端渲染原理，但必须在需求阶段就把性能问题设计掉。本文从指标收敛、查询粒度、交互降级三个维度，分享几个能直接落地的产品侧解法。

去年做一个交易系统的工作汇报，客户领导要求现场用数据大屏演示过去一年的交易表现，页面转了整整15秒圈才加载完。会议室里没人说话，但气氛已经说明了一切。会后复盘，开发说 “数据量太大，查询慢”，运维说 “服务器配置不够、网络不好”，最后绕了一圈，结论是需求里没写性能要求，谁都没把这当回事。

这在B端项目里太常见了。产品经理画原型时，总觉得 “性能是技术的事”，把大屏堆得满满当当，图表一个接一个。等到上线用户抱怨加载慢，才发现技术能优化的空间其实很有限，数据大屏的性能问题，其实80%在需求定义阶段就埋下了。

一、指标减法，别把大屏当成指标仓库

这是最容易被忽略，但投入产出比最高的一件事。

设计大屏时，很多产品经理生怕漏掉什么，恨不得把所有能想到的指标都堆上去，例如交易额、完成率、趋势图、占比图、排行榜等等，一个首页放十几个指标和图表是常态。当然，这未必全是产品经理的想法，很多客户自己也希望大屏尽量多放指标，把领导可能关注的数据全部铺开，一屏看全。

但真正观察用户的使用行为就会发现，大屏查阅是有一条业务逻辑线的，大多数人日常只盯着核心的几个指标，当这些指标出现异常才会有顺着业务逻辑去追看下游的图表。

其实，做数据大屏和做PPT是一个路子。放在PPT上的，永远是这场汇报最核心、领导最关心的指标，整个演示有先后顺序，不是把内容随手堆上去。而那些领导可能追问、又并非本次重点的明细数据，通常的做法是提前备好附件材料，问到了再拿出来，大屏的下钻页面正是起这个作用。反过来想，如果PPT内容塞满十几个图表，领导根本没耐心听完，大屏堆满指标用户同样没有耐心看完。

所以，我建议在需求设计阶段，就强制做一次“指标分级”：

1. 核心指标：用户打开这个页面的第一诉求，默认加载渲染。
2. 下钻指标：和核心指标相关、但不是每次都要看的，做成点击展开或 Tab 切换，触发后再加载。
3. 砍掉的指标：问自己三个问题——谁在看？多久看一次？看了之后做什么决策？答不上来的，直接砍。

之前那个交易系统，首页原来12个图表加一张地图，砍到6个核心指标+4个可展开的下钻图，首屏默认加载时间从10秒降到1.5秒。客户反而反馈 “页面清爽了，找数据更快了”。

二、管好查询粒度，别忽略了数据量

如果说指标减法是 “少渲染”，那查询粒度就是 “少查数据”。

大屏加载慢，很多时候不是图表渲染慢，而是后端查询慢。而查询慢的元凶，往往在产品经理写PRD的那一刻就埋下了。

相信很少有产品经理会直接要求 “展示全部数据”，大多数人的PRD里写的是”展示近一年数据”、” 展示近一月数据”，看起来都很正常。问题在于，产品经理写需求时脑子里只有功能，没有数据量。近一年数据在测试环境可能就几百条，放到生产环境是几百万条甚至更多。时间范围定得越大，后端要扫的数据越多，查询自然越慢。

产品经理可以不懂SQL，但必须在需求里把三件事想清楚：

1）默认时间范围要和业务场景匹配

日常监控类大屏，默认近7天就够了。月度经营分析，可以默认本月、上月或者近30天。只有年度汇总类页面，才默认全年。用户想看更长时间的数据，让他自己去选，而不是默认就给他一个大范围。

2）数据粒度要和时间范围匹配

看日趋势，就没必要同时加载小时级数据。看月度汇总，也不必去查日明细。粒度越细，数据量越大，查询越慢。

3）大屏查汇总表，不查明细表

这一点要提前和开发约定好。大屏应该查的是预聚合的汇总表，而不是原始业务明细表。如果系统里还没有汇总表，那就不是开发能顺手解决的问题，而是一个需要排期的需求，别等上线了才发现开发一直在查明细表。

三、交互降级，别让用户干等

前面两招是 “让页面变快”，这一招是 “让用户觉得快”。

再怎么优化，大屏总需要加载时间。用户怕的不是等，而是不知道要等多久、页面是不是卡死了。所以产品经理在设计交互时，要把加载状态当成一个正经的功能来设计，而不是指标需求、设计图甩给开发就完事。

用骨架屏，别用大转圈

一个全屏转圈转5秒，用户觉得等了很久，但同样时间如果用骨架屏逐步填充，用户感知会好很多。骨架屏能让用户提前看到页面结构，心理上会觉得 “内容马上就出来了”。

超时先给缓存数据

如果接口确实需要较长时间加载和返回数据，别让用户对着空白页等。可以先展示上一次的缓存数据，加一个小字提示 “数据更新中，当前显示的是XX时间的数据”。用户至少能看到东西，而不是怀疑系统崩了。

筛选条件做局部刷新

很多数据大屏，用户改一个时间筛选，整个页面所有图表全部重新加载。这完全没必要，改了时间范围，只刷新和时间相关的图表就行，改了业务线筛选才需要全量刷新。产品经理在原型上需要标注清楚哪些筛选影响哪些图表，开发做局部刷新就有了依据。

大数据量导出走异步

如果大屏要带上导出数据功能，正确的做法是异步导出。用户点导出后提示 “导出任务已提交，完成后可在下载中心获取”，后台异步生成文件。如果还是沿用同步导出，用户点击后页面转圈几十秒才下载完，期间不能切换其他页面，体验极差。这不是技术方案，这是产品交互设计。

四、把性能写进验收标准，别等上线了才补

大部分B端项目的验收标准里，测试验证的都是 “功能正常使用”、” 数据准确无误 “，很少有人关注性能问题。结果就是，开发和测试用测试环境的几百条数据验收，一切正常，等上线后真实数据量翻了很多倍，页面卡得没法用。这时候再考虑优化性能，成本是需求阶段的十倍以上。

所以，针对大屏等可视化统计页面，产品经理要在PRD的验收标准里加两条硬指标：

1. 规定首屏加载时间，例如≤3秒
2. 规定图表切换、筛选联动响应时间，例如≤1 秒

注意，一定要注明是 “基于生产环境真实数据量”。如果验收时还没上线，就要求开发或测试在测试环境导入模拟数据，数据量至少和上线初期持平。用几十条测试数据验出来的 “性能达标”，没有任何意义。

另外，上线后也别撒手。让运维或开发加一个简单的监控，统计大屏的平均加载耗时，一旦超过阈值就报警。很多性能问题是数据量慢慢涨上来的，等用户投诉时已经很严重了，有监控就能提前发现。

五、总结

最后想说的，其实就三句话。

第一，可视化大屏的性能问题，从来不是单纯的技术问题，它也是产品设计问题。技术团队能帮你把一个设计合理的页面优化到极致，但没法把一个堆满指标、默认查全部细粒度数据的页面救回来。性能的起点，在产品经理画原型的那一刻就定下了。

第二，设计的时候，先问清楚指标是不是真的需要。谁在看、多久看一次、看了之后做什么决策，答不上来就砍。指标减下来，页面自然就快了。

第三，PRD 里不能只写指标需求和设计图。数据粒度怎么展示、是否要建预聚合的汇总表、加载中的交互怎么做、验收时性能要求定多少，这些看起来 “不像是产品该管的事”，恰恰是决定大屏最终体验的关键。漏了哪一项，上线后都要用十倍的成本补回来。

说到底，用户打开数据大屏，要的不是信息更多，而是更快地找到他要的那一个数据。而能不能快，从你写需求那天就决定了。