IE之页面加载慢.

场景

场景是大屏页面一张深色背景, 里面一些文本元素以及图表展示.

结果在IE下发现加载异常缓慢, 还有部分人员反馈页面卡死.

后台读写优化

默认处理图片逻辑是, ImageIO读取原图, 转成byte[], base64编码后, 放到dom里.

这样图片越大, 后台转的byte[]数组越大也越卡, 那么改进思路自然是压缩, 以及去除ImageIO读取.

使用Thumbnailator, 对超过1MB的图片进行压缩, 一般10MB的深色图片, 

压缩率用75%, 压缩后也就几百KB. 然后把base64编码写在dom里的实现方式改成了css加载src.

改完之后, 后台已经完全不涉及到读写图片卡顿问题了.

图片加载方式

但是前台依然会空白很久, 然后出现加载图标, 最后才开始各个组件加载渲染. 那么这个空白跟图片背景有没有关系呢? 

答案是no, 不过图片会占用服务器带宽, 所以需要压缩下原图或者直接放到cdn上.

关于图片渲染是否影响内容加载可以做个很简单的实验, 将Chrome控制台调整到Network,

选择fast3g网络模式, 可以模拟一个低速网络. 

访问一张带背景图的表单, 可以看到内容是先渲染出来的, 然后是加载图片.

图片是一段一段的加载的, 并不会影响内容主体渲染, 也不是导致初始页面空白的元凶.

如果觉得图片分段加载效果不好的话, 可以把图片改成渐进式加载. 效果如下:

可以明显看到图片从模糊到清晰的一个过程, 企业微信里聊天传输图片用的也是渐进式加载.

如何生成渐进式图片呢? 只需要在photoshop编辑图片的时候, 选择交错保存PNG. 

也可以用代码处理, 设置ProgressiveMode即可.

 1         File file = new File("D:/o.jpg");
 2         BufferedImage image = ImageIO.read(file);
 3         Iterator<ImageWriter> it = ImageIO.getImageWritersByFormatName("jpeg");
 4         ImageWriter writer = null;
 5         while (it.hasNext()) {
 6             writer = it.next();
 7             break;
 8         }
 9         if (writer != null) {
10             ImageWriteParam params = writer.getDefaultWriteParam();
11             params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT); // 设置可否压缩
12             params.setCompressionQuality(0.75f); // 设置压缩质量参数
13             params.setProgressiveMode(ImageWriteParam.MODE_DEFAULT);
14             ImageOutputStream output = ImageIO.createImageOutputStream(new File("D:/progressive.jpg"));
15             writer.setOutput(output);
16             writer.write(null, new IIOImage(image, null, null), params);
17             output.flush();
18             writer.dispose();
19         }
20     }

重复一下, 图片渐进式和分段式, 只是提升交互体验, 加载速度并没有变化.

IE与Gzip

如果不是图片导致的加载慢, 为什么很多小伙伴反馈大屏慢呢? IE以及Edge似乎更卡一点. 

我们用Chrome访问一张大屏模板, 对比下IE访问模板的响应时间. 两者都预先清理缓存.

访问大屏地址 http://106.15.45.188:8088/WebReport/ReportServer?op=fs_main&cmd=entry_report&id=2571

截图一看清楚了, IE里看上去Gzip就没起作用, 实实在在的加载原js. 用了4s才加载完.

看下代码中Gzip的处理, 直接把 IE全家 列到不支持Gzip的列表里了.

1 public boolean supportGzip() {
2    return !(isIE()) && !(isWebkit() && J2EEContainer.isWebLogic());
3 }
4   
5 public boolean isIE() {
6    //ie10之后不能根据msie判断需根据trident,先带上edge看看
7    return "msie".equals(this.browser) || this.userAgent.contains("trident") || this.userAgent.contains("edge");
8 }

实际上高版本IE早就支持Gzip了, 因为IE11里http的响应头已经写了Accept-Encoding: gzip, deflate.

找了早期的IE9看了下, 也是支持Gzip压缩的.

修复验证

因为是线上环境, 我们本地没还原客户那边的卡顿很久空白的情况, 猜测跟网速有关系.

需要用一个软件来模拟低速网络环境,. 首选自然是fiddler, 只需要一步设置即可.

Rules → Performances → Simulate Modem Speeds.

重复上述访问entry操作, 等得的快炸的时候, 页面终于加载出来了.

低速网络下, 两个js累计加载耗时561s!!! 

开启Gzip后, 跟Chrome速度一样了, 两个js累计114s, 越是低速网络, Gzip效果越明显.