各位，手上项目上有个页面： 建筑视图一览 ，现在一直加载得比较慢，每次打开这个页面要1分钟左右，现要想重新重构这个页面，需要一个思路。
目前情况：
1.这个页面，主要展示是的就是建筑的一些实时情况，Web前端页面需要，图形化的展示，前后端。
2.建筑是个树形结构，整个树形数据量几万，每级都有汇总信息，还有其他的关联信息（如：人数啊，设备数啊，建筑里有那些的人信息啊，设备信息啊，管理员信息啊等等），总之就是要关联蛮多表，来获取到这些关联信息。
3.这个页面对系统来打开频率高，对实时性有要求。
4.目前做法，就前端请求，后台接口实时计算:递归循环，然后关联查询，再计算汇总，最后组成JSON数据结构返回给前端。（目前接口查询要 40 秒左右）
不知道现在主流的做法是如何实现， 类似 数据一览 的页面的，求个整体重构思路。
如果每次数据整体统计（后端接口统计）需要很长时间的话，我这边建议有几点：
1、尝试提升接口效率，方法：sql语句优化，索引优化，缓存优化等手段；
2、使用推送功能实现局部刷新，利用 websocket ，每次局部内容发生变更时，将局部内容主动推送到前端，前端合并内容并渲染。
基本上第二种效率理论上最高，但是重构成本也是最大的。
将与你接口40s的效率，应该还是有优化的空间的，优化到 5s 以内肯定没有什么问题，尽量不要使用 join 之类的多联表查询，可以尝试查询主表之后，得到主表与关联表的外键，再单独根据外键 查询子表，手动装配到主表上，也就是将单次 联表查询 分成多次查询，手动组合结构。
如果这样还是不能提升效率，那么就得看表中查询字段是否没有索引。
首页接口要40s的话，肯定要优化接口的，毫无疑问的
然后前端能做的也不多，预加载一些先看的，根据屏幕大小做一些懒加载（不在第一屏显示的），还有就是一些适当的缓存
先看看把sql语句能优化的优化下，之前一家公司一个查询写了100行，都懒得说。
主要还是数据量大的问题，那就从请求数据量入手。
建议：
后台优化：别搞一个接口，按优先展示的顺序分多个接口传输（我不知道他后台表怎么设计的，反正思路大概是这样），前端监听页面滑动或者点击之类的交互，需要展示新数据时候再调别的接口。
前端优化：webpack配置好，gzip技术压缩项目，还有就是图片的懒加载
前端和后端优化
1.前端图片资源预加载，数据渲染可根据动作触发，用时加载。总体感觉前端优化除了静态资源有效果明显，其他的一般。
2.后端方案就比较多了。看你的业务啦。初级数据库缓存（基本不多用），物理缓存（也不多），内存级缓存（框架一般都带的有，开启即可），缓存中间件（redis基本能满足）。在大就是分布式，
我觉得接口上面可以拆分一下（能不能拆成几个接口分担一下），几十秒的接口太不科学了
界面上能不能优化一下，不要一次加载全部数据，比如先加载几条，界面渲染出来，再去请求生下来的数据
还有既然是实时的，可以通过websocket 后端推送。也要分开推，不然跟接口返回全部数据估计也没两样。