记录一次前端系统调优过程，针对于页面卡顿

一: 前端页面卡顿

个人总结前端页面存在卡顿的原因大概如下:

1. 电脑性能差

        2. 网速问题

3. 打开的页面存在很多请求，有的请求未响应，或响应不及时(与网速有一定的关系)。

4. 线程阻塞， 也就是前端存在大量运算或者渲染页面的过程。

针对于前两种的话，那你就换电脑 + 加网络带宽可以搞定 

现在主要来解决我遇到的3和4的情况，及如何去处理该问题。

二: 问题还原

使用场景:  地图在不同比例尺(地图默认比例尺为1-20级)下动态加载路网图层，加载图层之后按照交通态势渲染出红黄绿三色。

            问题描述:  当地图在比例尺为1-14的时候默认只显示高速和一级道路，比例尺为15的时候多显示个二级，比例尺为16的时候多显示个三级道路，比例尺大于16时显示全部路网图层。 当比例尺在1-16级，动态加载路网耗费和用户等待时间大概在2-4s，但是当用户加载到16级以上的时候，会卡顿10s以上才会加载出来。

三: 现状分析

造成这种不友好的情况，分析后发现的原因如下:

1.动态加载图层，在1-16级时，每次请求路网数据会耗费1-2s时间，返回100-200KB(900-1500条路段信息)的数据，当请求16级以上的路网数据时，就会耗费6-10s的时间，返回1.1MB(13000-14000条路段信息)的数据。

2.当路网数据请求完成后，会在路网上叠加路段的拥堵信息，这里使用的是外循环嵌套内循环方式进行渲染，外循环遍历本地路段拥堵信息，当该路段是拥堵路段时，内循环遍历动态获取的路网图层中(当16级以上时，在1.3w-1.4w数据量)路段信息，在这块的耗时比较明显。

四：解决方案

既然问题原因我们已经分析出来了，那接下来就该对症下药。

1.针对于图层加载问题， 采用方案为，不同级别下返回的数据使用本地存储保存起来。使用方式如下:

localStorage.setItem(type ,ctest);  //设置存储key(type)的值为ctest
localStorage.getItem(type);  //获取存储key(type)的值

如果到这里，问题1可以圆满解决那就很好了，但是出现了一个新的问题。 在获取16级以上的数据时，使用本地保存，会提示大小超出了限制。 好吧，本地存储也是有局限性了。 那针对于这个怎么办呢。 进过多角度思考(比如写文件、读文件，保存JSON、读取JSON)之后，决定还是在现有本地存储上进行优化，既然大小超过限制了，那我们压缩下是不是可以解决呢。

OK，经过几番查找，发现确实存在压缩字符串的方法，使用之后压缩率还挺高，之后就没有爆出相关的大小限制问题了。

现附上JS实现的压缩方式 :  

• First, import it in the page where you want to use it:
  <script language="javascript" src=" lz-string.js"></script>
• Next , call compress and decompress on the LZString object:
  var string = "This is my compression test.";alert("Size of sample is: " + string.length);var compressed = LZString.compress(string);alert("Size of compressed sample is: " + compressed.length);string = LZString.decompress(compressed);alert("Sample is: " + string);

        参考地址: http://pieroxy.net/blog/pages/lz-string/index.html   下载地址

        2.对于第二个问题的优化方案是，去除嵌套循环，编程两次循环，第一次循环路段表，将拥堵路段的id包含在临时变量nowRoads中，第二次遍历路网路段信息，如果nowRoads中存在当前的路段id则为拥堵路段，改变其属性即可。

五：实现效果

再次请求之后，只有第一次加载回去请求数据然后保存在本地浏览器中，之后用户在不清除本地历史记录的情况下，每次打开都会从本地来加载相关路网数据。

完成之后，在请求1-16级时，响应速度都控制在1s以内， 当级别大于16级时， 响应速度在1-3s内可以完成。 大大提升了用户体验感。 不过针对于问题2的话，应该还有更好的优化方案，留到后面来挑战。