使用 Chrome Timeline 来优化页面性能

有时候,我们就是会不由自主地写出一些低效的代码,严重影响页面运行的效率。或者我们接手的项目中,前人写出来的代码千奇百怪,比如为了一个 Canvas 特效需要同时绘制 600 个三角形,又比如 Coding.net 的任务中心需要同时 watch 上万个变量的变化等等。那么,如果我们遇到了一个比较低效的页面,应该如何去优化它呢?

优化前的准备:知己知彼

在一切开始之前,我们先打开 F12 面板,熟悉一下我们接下来要用到的工具:Timeline:

嗯没错就是它。下面逐一介绍一下吧。区域 1 是一个缩略图,可以看到除了时间轴以外被上下分成了四块,分别代表 FPS、CPU 时间、网络通信时间、堆栈占用;这个缩略图可以横向缩放,白色区域是下面可以看到的时间段(灰色当然是不可见的啦)。区域 2 可以看一些交互事件,例如你滚动了一下页面,那么这里会出现一个 scroll 的线段,线段覆盖的范围就是滚动经过的时间。区域 3 则是具体的事件列表了。

一开始没有记录的时候,所有的区域都是空的。开始统计和结束统计都很简单,左上角那坨黑色的圆圈就是。它右边那个长得像“禁止通行”的按钮是用来清除现有记录的。当有数据的时候,我们把鼠标滚轮向上滚,可以看到区域被放大了:

短短的时间里,浏览器做了这么多事情。对于一般的屏幕,原则上来说一秒要往屏幕上绘制 60 帧,所以理论上讲我们一帧内的计算时间不能超过 16 毫秒,然而浏览器除了执行我们的代码以外,还要干点别的(例如计算 CSS,播放音频……),所以其实我们能用的只有 10~12 毫秒左右。

差不多熟悉操作了,那么就来一下实战吧!假如有一天,你接手了这样一段代码:

<!-- 一段小动画:点击按钮之后会有一个爆炸的粒子效果 -->
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Test</title>
    <style>
        .main {
            position: relative;
            width: 500px;
            height: 500px;
            background: #000;
            overflow: hidden;
        }
        .circle {
            position: absolute;
            border-radius: 50%;
            border: 1px solid #FFF;
            width: 8px;
            height: 8px;
        }
    </style>
</head>
<body>
    <div class="main"></div>
    <hr>
    <button onclick="showAnimation()">点我</button>
    <script src="jquery.min.js"></script>
    <script src="animation.js"></script>
</body>
</html>
// animation.js

// 粒子总数
var COUNT = 500;
// 重力
var G = -0.1;
// 摩擦力
var F = -0.04;

function init() {
    for (var i = 0; i < COUNT; i++) {
        var d = Math.random() * 2 * Math.PI;
        var v = Math.random() * 5;
        var circle = $(‘<div id="circle-‘ + i + ‘" class="circle" data-x="250" data-y="250" data-d="‘ + d + ‘" data-v="‘ + v + ‘"></div>‘);
        circle.appendTo($(‘.main‘));
    }
}

function updateCircle() {
    for (var i = 0; i < COUNT; i++) {
        var x = parseFloat($(‘#circle-‘ + i).attr(‘data-x‘));
        var y = parseFloat($(‘#circle-‘ + i).attr(‘data-y‘));
        var d = parseFloat($(‘#circle-‘ + i).attr(‘data-d‘));
        var v = parseFloat($(‘#circle-‘ + i).attr(‘data-v‘));
        var vx = v * Math.cos(d);
        var vy = v * Math.sin(d);
        if (Math.abs(vx) < 1e-9) vx = 0;
        // 速度分量改变
        vx += F * Math.cos(d);
        vy += F * Math.sin(d) + G;
        // 计算新速度
        v = Math.sqrt(vx * vx + vy * vy);
        if (vy > 0) d = Math.acos(vx / v);
        else d = -Math.acos(vx / v);
        // 位移分量改变
        x += vx;
        y += vy;
        $(‘#circle-‘ + i).attr(‘data-x‘, x);
        $(‘#circle-‘ + i).attr(‘data-y‘, y);
        $(‘#circle-‘ + i).attr(‘data-d‘, d);
        $(‘#circle-‘ + i).attr(‘data-v‘, v);
        $(‘#circle-‘ + i).css({‘top‘: 400 - y, ‘left‘: x});
    }
}

var interval = null;

function showAnimation() {
    if (interval) clearInterval(interval);
    $(‘.main‘).html(‘‘);
    init();
    interval = setInterval(updateCircle, 1000 / 60);
}

效果如下(右上角的 FPS 计数器是 Chrome 调试工具自带的):

只有 10 FPS……10 FPS……坑爹呢这是!

好吧,打开 Timeline,按下记录按钮,点一下页面中的“点我”,稍微过一会儿停止记录,就会得到一些数据。放大一些,对 jQuery 比较熟悉的同学可以看出来,这些大部分是 jQuery 的函数。我们点一下那个 updateCircle 的区块,然后看下面:

这里告诉我们,这个函数运行了多久、函数代码在哪儿。我们点一下那个链接,于是就跳到了 Source 页:

是不是很震撼,之前这个页面只是用来 Debug 的,没想到现在居然带了精确到行的运行时间统计。当然,这个时间是当前这一行在“刚才我们点击的区块对应的执行时间段”中运行的时间。所以我们就拿最慢的几句话来下手吧!

优化一:减少 DOM 操作

看到这几行代码,第一反应是:mdzz。本来 DOM 操作就慢,还要在字符串和 float 之间转来转去。果断改掉!于是用一个单独的数组来存 xydv 这些属性。

var objects = [];
// 在 init 函数中
objects.push({
    x: 250,
    y: 250,
    d: d,
    v: v
});
// 在 updateCircle 函数中
var x = objects[i].x;
var y = objects[i].y;
var d = objects[i].d;
var v = objects[i].v;
// ….
objects[i].x = x;
objects[i].y = y;
objects[i].d = d;
objects[i].v = v;

效果显著!我们再来看一下精确到行的数据:

优化二:减少不必要的运算

所以最耗时的那句话已经变成了计算 vx 和 vy,毕竟三角函数算法比较复杂嘛,可以理解。至于后面的三角函数为什么那么快,我猜可能是 Chrome 的 V8 引擎将其缓存了(这句话不保证正确性)。然而不知道大家有没有发现,其实计算 d 完全没必要!我们只需要存 vx 和 vy 即可,不需要存 v 和 d

// init
var vx = v * Math.cos(d);
var vy = v * Math.sin(d);
objects.push({
    x: 250,
    y: 250,
    vx: vx,
    vy: vy
});
// updateCircle
var vx = objects[i].vx;
var vy = objects[i].vy;
// 计算新速度
var v = Math.sqrt(vx * vx + vy * vy);
if (Math.abs(vx) < 1e-9) vx = 0;
// 速度分量改变
vx += F * vx / v;
vy += F * vy / v + G;
// ….
objects[i].vx = vx;
objects[i].vy = vy;

只有加减乘除和开平方运算,每次比原来的时间又少了两毫秒。从流畅的角度来说其实已经可以满帧运行了,然而为什么我还是觉得偶尔会有点卡呢?

优化三:替换 setInterval

既然偶尔会掉帧,那么就看看是怎么掉的呗~原则上来说,在每一次浏览器进行绘制之前,Timeline 里面应该有一个叫 Paint 的事件,就像这样:

看到这些绿色的东西了没?就是它们!看上面的时间轴,虽然代码中 setInterval 的长度是 1000/16 毫秒,但是其实根本不能保证!所以我们需要使用 requestAnimationFrame 来代替它。这是浏览器自带的专门为动画服务的函数,浏览器会自动优化这个函数的调用时机。并且如果页面被隐藏,浏览器还会自动暂停调用,有效地减少了 CPU 的开销。

// 在 updateCircle 最后加一句
requestAnimationFrame(updateCircle);
// 去掉全部跟 setInterval 有关的句子,把 showAnimation 最后一句直接改成这个
updateCircle();

我们至少可以保证,我们每算一次,屏幕上就会显示一次,因此不会掉帧(前提是每计算一次的时间小于 12ms)。但是虽然计算时间少了,浏览器重计算样式、绘制图像的时间可是一点都没变。能不能再做优化呢?

优化四:使用硬件加速、避免反复查找元素

如果我们用 transform 来代替 left 和 top 来对元素进行定位,那么浏览器会为这个元素单独创立一个合成层,专门使用 GPU 进行渲染,这样可以把重计算的代价降到最低。有兴趣的同学可以研究一下“CSS 硬件加速”的机制。同时,我们可以缓存一下 jQuery 的元素(或者 DOM 元素),这样不用每次都重新查找,也能稍微提高一点效率。如果把元素缓存在 objects 数组中,那么连 id 都不用写了!

// init
var circle = $(‘<div class="circle"></div>‘);
objects.push({
    x: 250,
    y: 250,
    vx: vx,
    vy: vy,
    // 其实可以只存 DOM,不存 jQuery 对象
    circle: circle[0]
});
// updateCircle 里面 for 循环的最后一句话替换掉
objects[i].circle.style.transform = ‘translate(‘ + x + ‘px, ‘ + (400 - y) + ‘px)‘;

看起来是不是很爽了?

其实,优化是无止境的,例如我在 init 函数中完全可以不用 jQuery,改用 createDocumentFragment 来拼接元素,这样初始化的时间就可以急剧缩短;调换 updateCircle 中的几个语句的顺序,在 V8 引擎下效率可能会有一定的提升;甚至还可以结合 Profile 面板来分析内存占用,查看浏览器绘图的细节……然而个人感觉并用不到这么极限的优化。对于一个项目来说,如果单纯为了优化而写一些奇怪的代码,是很不合算的。

P.S. 全部的代码在这里,欢迎吐槽:

未优化版 | 优化版

时间: 2024-11-07 21:22:52

使用 Chrome Timeline 来优化页面性能的相关文章

页面性能优化办法有哪些?

引子 互联网有一项著名的8秒原则.用户在访问Web网页时,如果时间超过8秒就会感到不耐烦,如果加载需要太长时间,他们就会放弃访问.大部分用户希望网页能在2秒之内就完成加载.事实上,加载时间每多1秒,你就会流失7%的用户.8秒并不是准确的8秒钟,只是向网站开发者表明了加载时间的重要性.那我们如何优化页面性能,提高页面加载速度呢?这是本文主要要探讨的问题,然而性能优化是个综合性问题,没有标准答案,想要面面俱到罗列出来,并非易事.本文只关注一些核心要点,以下是我总结性能优化常见的办法: 一.资源压缩与

使用Chrome DevTools的Timeline分析页面性能

随着webpage可以承载的表现形式更加多样化,通过webpage来实现更多交互功能,构建web应用程序已经成为很多产品的首要选择.这种方式拥有非常明显的优势:跨平台.开发便捷.便于部署和维护等等,但随着功能的不断积累,web应用程序也会变得越来越复杂.但是,我们仍然想要在webpage支持丰富的呈现形式的同时,让页面效果能够达到>=60fps(帧)/s的刷新频率以避免出现卡顿,就需要我们使用一些比较直观的方式来分析衡量页面的性能问题,为性能优化方案提供依据. 为什么是60fps?我们的目标是保

Web页面加载,如何分析页面性能?如何进行优化?

一.浏览器加载过程:1.建立连接过程 (1) 浏览器查找域名的IP地址 (2) 浏览器给web服务器发送一个HTTP请求 (3) 服务器发送永久重定向响应 (4) 浏览器跟踪重定向地址 (5) 服务器"处理"请求 (6) 服务器发回一个HTML响应2.浏览器渲染 解析HTML ↓构建DOM树 ↓渲染树构建 ↓渲染树布局 ↓绘制渲染树二.优化方法1.启用浏览器缓存 浏览器要根据域名找出IP地址,而DNS查找过程的第一步是在浏览器缓存中查找,根据Chrome的PageSpeed给出的建议:

页面性能优化和高频dom操作

一.DOM操作影响页面性能的核心问题 通过js操作DOM的代价很高,影响页面性能的主要问题有如下几点: 访问和修改DOM元素 修改DOM元素的样式,导致重绘或重排 通过对DOM元素的事件处理,完成与用户的交互功能 DOM的修改会导致重绘和重排. 重绘是指一些样式的修改,元素的位置和大小都没有改变: 重排是指元素的位置或尺寸发生了变化,浏览器需要重新计算渲染树,而新的渲染树建立后,浏览器会重新绘制受影响的元素. 页面重绘的速度要比页面重排的速度快,在页面交互中要尽量避免页面的重排操作.浏览器不会在

页面性能优化总结

页面性能优化总结         由于本人前几天一直在解决页面性能.加载慢等问题.解决后,对于该方面知识有一定的认识与理解,现将经验码出来,与大家分享:由于单纯讲解知识点会造成知识点认识混乱,故将知识分模块讲解:由于项目中主要使用chrome浏览器,故仅讲解以webkit为内核的浏览器机制1.浏览器加载时间:当浏览器对页面进行加载并且解析时,会产生如下几个主要时间: 1).queueing 时间 该时间为等候时间,也可以叫排队时间.即文件在加载之前的排队等候时间.该排队等候时间会根据优先级进行判

新时代的页面性能优化

概述 最近这几天对页面性能优化进行了一些思考,记录下来,供以后开发时参考,相信对其他人也有用.在我查资料的过程中,发现以前的一些黄金优化法则,在现代有些已经或多或少的被淘汰了! 首屏时间 首屏时间真的很重要,用户的等待忍受能力是有限的.有以下几个优化方向: 可以通过chrome浏览器的performance面板来查看页面加载时的逐帧闪照.来查看在首屏之前浏览器做了哪些多余的动作,然后一一优化掉. 对于首屏有一个很大的背景图的网站,背景图一般是用background-img实现的,但是backgr

如何使用 Chrome 和 DevTools 查找影响页面性能的内存问题,包括内存泄漏、内存膨胀和频繁的垃圾回收

了解如何使用 Chrome 和 DevTools 查找影响页面性能的内存问题,包括内存泄漏.内存膨胀和频繁的垃圾回收. TL;DR 使用 Chrome 的任务管理器了解您的页面当前正在使用的内存量. 使用 Timeline 记录可视化一段时间内的内存使用. 使用堆快照确定已分离的 DOM 树(内存泄漏的常见原因). 使用分配时间线记录了解新内存在 JS 堆中的分配时间. 概览 在 RAIL 性能模型的精髓中,您的性能工作的焦点应是用户. 内存问题至关重要,因为这些问题经常会被用户察觉. 用户可通

页面性能分析-Chrome Dev Tools

一.分析面板介绍 进行页面性能快速分析的主要是图中圈出来的几个模块功能: Network : 页面中各种资源请求的情况,这里能看到资源的名称.状态.使用的协议(http1/http2/quic...).资源类型.资源大小.资源时间线等情况 Performance : 页面各项性能指标的火焰图,这里能看到白屏时间.FPS.资源加载时间线.longtask.内存变化曲线等等信息 Memory : 可以记录某个时刻的页面内存情况,一般用于分析内存泄露 JavaScript Profiler : 可以记

雅虎团队经验:网站页面性能优化的34条黄金守则

1.尽量减少HTTP请求次数 终端用户响应的时间中,有80%用于下载各项内容.这部分时间包括下载页面中的图像.样式表.脚本.Flash等.通过减少页面中的元素可以减少HTTP请求的次数.这是提高网页速度的关键步骤. 减少页面组件的方法其实就是简化页面设计.那么有没有一种方法既能保持页面内容的丰富性又能达到加快响应时间的目的呢?这里有几条减少HTTP请求次数同时又可能保持页面内容丰富的技术. 合并文件是通过把所有的脚本放到一个文件中来减少HTTP请求的方法,如可以简单地把所有的CSS文件都放入一个