iCMS

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

iCMS http://www.hlike.cn 2019-08-07 10:00 出处:网络 编辑:@iCMS
书接上文 上一篇文章《【原创】用事实说话,Firefox的性能是Chrome的2倍,Edge的4倍,IE11的6倍!》,我们对比了不同浏览器下FineUIPro一个页面的性能,发现Firefox的加载速度最快,而众望所归的Chrome却表现的差强人

书接上文

上一篇文章《【原创】用事实说话,Firefox 的性能是 Chrome 的 2 倍,Edge 的 4 倍,IE11 的 6 倍!》,我们对比了不同浏览器下FineUIPro一个页面的性能,发现Firefox的加载速度最快,而众望所归的Chrome却表现的差强人意,加载速度仅仅是Firefox的一半!

最近我们重新对测试和代码进行了优化和整理,有如下三个发现:

1. 测试代码将开始时间放在<head>标签的做法有失偏颇,如下所示:

<!DOCTYPE html>

<html>

<head>

<title></title>

<script>

var __STARTTIME = new Date();

</script>

</head>

这会导致所计算的时间包含HTML页面,CSS文件和JavaScript文件的网络传输时间,实际上这部分是我们测试案例所不关心的,我们仅关心页面的渲染速度!

因此,优化后的代码将开始时间放到页面底部,如下所示:

</form>

<script>

// 等所有JS资源下载完毕后开始

var __STARTTIME = new Date();

// 表格渲染完毕后结束

function onGridRender() {

F.ui.Grid1.setTitle('表格(23列,500行,行高不同) - 渲染:' + ((new Date() - __STARTTIME) / 1000).toFixed(2));

}

</script>

</body>

</html>

2. 前面一篇文章《【原创】这一次,Chrome表现和IE11一样令人失望,围观群众有:Edge,Firefox》,我们发现Chrome解析如下结构时遇到问题:

2.1 页面结构如下:

<td class="f-grid-cell">

<div class="f-grid-cell-inner">杨婷婷</div>

</td>

2.2 页面样式包含:

.f-grid-cell {

overflow: hidden;

}

.f-grid-cell-inner {

position: relative;

}

这样的 CSS 设置会导致滚动时页面出现白屏,并且CPU占用率飙升。

不仅如此,在去除 td 的 overflow:hidden 样式后,我们发现 Chrome 下的页面渲染速度也有明显的提升,这一点对接下来的Chrome性能提升也很重要!

3. FineUIPro 代码中有强制 Chrome 重绘的浏览器特定代码,这也是对 Chrome 之前版本存在滚动条不显示的应急策略:

function forceChromeRepaint(targetNode) {

//:: Chrome的BUG(Firefox,IE都没有此问题)

//:: http://stackoverflow.com/questions/4394350/chrome-scrollbars-not-disappearing-when-content-is-smaller-than-container?rq=1

if(F._fjs_isChrome) {

var overflow = targetNode.css('overflow');

if(overflow === 'auto' && targetNode._fjs_scrollLeft() == 0 && targetNode._fjs_scrollTop() == 0) {

targetNode.css('overflow','hidden');

//:: 强制浏览器重新绘制

targetNode[0].scrollWidth;

targetNode.css('overflow','auto');

}

}

}

在最新版的Chrome下测试,相应的浏览器滚动条不显示问题已经得到了修正,所以可以把相关的强制重绘代码去掉了(之前出问题的好像是Chrome v58前后的一些版本,现在Chrome都升级到75了)。这也进一步提升了页面的渲染速度。

经过上面三方面的改进,我们再来看下不同浏览器下的页面渲染性能的对比数据。

优化后的对比数据

和第一篇文章的测试类似,我们将表格行增加到 500 多行,列增加到 20 多列,并且行高不固定,来测试下各个浏览器的性能。

测试使用的电脑是 MacBook Pro 笔记本(英特尔 i7-8750H,32GB内存,512GB SSD),单独拆分出一个新的 256GB 分区用来安装 Windows 10 Pro(64位)系统,并更新至最新补丁。

参与测试的浏览器都是最新版,分别为:

Chrome 75

Firefox 68

Edge 44

由于 IE11 有明显的卡顿,进行本测试意义不大,所以这次不再对 IE11 进行测试。

下面是测试结果(第一张是 FineUIPro v5.5.0 的截图,第二张是代码优化后的截图):

Firefox:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

Chrome:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

Edge:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

下面对上述结果进行一个综述:

浏览器

原始的渲染时间(秒)

优化后的渲染时间(秒)

Firefox

0.75

0.70

Chrome

1.85

1.08

Edge

5.53

2.47

注:

1. 每次页面刷新结果都有一定的差异,这个取的是多次运行的中间值。

2. 优化后的结果需要等FineUIPro v5.6.0 发布后自行到官网示例测试,目前没有在线测试链接。

可以看到,经过代码优化后,Chrome的性能有明显的提升,但即使如此,Firefox还是比Chrome有性能优势,只不过不再那么辣眼睛了。

发现新问题

看似一个问题的结束,却是另一个问题的开始,还记得上一篇文章中我们提到 Chrome 下选中卡顿的问题吗?

即使在上述数据优化之后,Chrome的渲染性能有明显提升的情况下(从1.85s提升到1.08s之后),Chrome下的行选中依然有明显的卡顿现象,对比下几个浏览器下的动图:

Chrome:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

Firefox:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

Edge:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

Chrome你这是要闹哪样?即使页面渲染慢得多的Edge都没有卡顿,选中行时非常丝滑,而Chrome就像被卡着脖子一样,每次点击都有差不多0.5秒的延迟!

真不省心,真不省心.....

解决问题

这个问题的解决可以说是费尽周折,因为已经明确知道是Chrome浏览器的BUG,而Firefox和Edge都正常,所以根本不能按照常规思路去解释。

后来,一个偶尔的机会,发现去掉第一列(包含复选框的那一列),问题神奇般的消失了,所以我一度怀疑是复选框的样式问题,来看一下。


复选框的HTML结构很简单:

<i class="f-icon f-iconfont f-grid-checkbox f-checkbox"></i>

CSS代码:

.f-checkbox {

position: relative;

top: 0;

left: 0;

display: inline-block;

width: 14px;

height: 14px;

min-width: 14px;

margin: 3px 1px;

border-width: 1px;

border-style: solid;

border-radius: 2px;

}

.f-checkbox:after {

display: table;

position: absolute;

left: 4px;

top: 1px;

width: 5px;

height: 8px;

border-width: 2px;

border-style: solid;

border-color: #fff;

border-top: 0;

border-left: 0;

content: " ";

-webkit-transform: rotate(45deg) scale(0);

transform: rotate(45deg) scale(0);

opacity: 0;

filter: alpha(opacity=0);

}

.f-checkbox.f-checked {

background-color: #007465;

border-color: #007465;

}

.f-checkbox.f-checked:after {

width: 5px;

height: 8px;

left: 4px;

top: 1px;

-webkit-transform: rotate(45deg) scale(1);

transform: rotate(45deg) scale(1);

opacity: 1;

filter: alpha(opacity=100);

}

这段CSS代码我看了很久很久,实在找不到可以优化的地方,因为这个做法也是业内所公认的,通过将 f-checkbox:after 的 L 型边框旋转 45 度来实现对勾的效果。

接下来,神奇的事情发生了,一个偶然的机会,我会外层的 .f-grid-cell-inner 的 position: relative 去掉,所有的卡顿不见了,一切都像Firefox一样丝滑:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

现在来看下去掉这个 CSS 属性之后,行选中的效果,丝滑的就像Firefox一样:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

问题解决了,是不是很高兴?

可惜一点都高兴不起来,首先不知道这个 td -> div 的 position:relative 挨着谁的事了,这么不受 Chrome 的待见。

其次这个属性虽然FineUIPro没有大用处,还是有一点用处的,比如这里:

【原创】原来你竟然是这样的Chrome?!Firefox笑而不语

所以遇到这种情况,就先加个例外好了。

不管怎么说,也算是暂时画上一个句号,看Chrome哪个版本能修正类似的问题?

不忘初心,砥砺前行!

0

精彩评论

暂无评论...
验证码 换一张
取 消