最近公司系统有个主要的功能，查询结果数据量太大，但是用户呢还坚持要求就要这么多数据（显然不符合软件学原理，超过两千你就眼花了。。。），迫于压力，公司将此艰巨任务交付给我。
背景：F12查看该查询结果最后也没大小是 12.5M，后端耗时咱们先暂且不管，前端耗时除了网速就和这个页面大小有关了。
目的：最终的目的是要前端查询渲染时间减少，根源还是最后渲染的页面的大小变小。
结果：经过九牛二虎之力，各种优化，各种分析，各种删减，保持功能与之前一致的情况下，页面大小减少到了4.5M，渲染速度也是有显著的提升。
优化过程：
长话短说，总结性说说做了大体哪些方面的工作，细节就不多说了。
1、css整理，原先的页面css可以说是满天飞，随处可见css，最后将所有的css抽取成一个css文件，放在页面上方。css加载的时候，不影响dom tree的解析。
2、js 整理放入页面下方，js会影响dom的解析；有些js前期加入，后期不用了，这种直接删掉。
3、最难的一步，分析dom结构。 这个可能是页面渲染慢的最大根源，在开发功能的最初阶段，开发人员目的很简单，按照UI设计完成功能，不会考虑到dom结构和层级（当然没必要过于开始就考虑这些，完成功能仍然是首要目的），因此我看这个结构，分析了有分析，看到好几层的那种div，立马拆拆拆，删删删，能用一层结构的绝不用两层，做到最少的层级结构。这一步可以说优化是无止境的，后期的主要战场就在这，耐心的去优化吧。
4、我们的系统页面是jsf，当然最终也是解析成html，差不多。有个别特殊性语法。 去掉rendered="false"的代码片段。
将循环的代码片段中的公共js挪出来，没必要每次循环，加载一遍js。
5、使用原生标签，加快渲染速度。用原生的span、div等代替。
最后附上一张系统截图，还是很漂亮的：
