Chrome 运行时性能瓶颈分析

一,初探,根据现象发现问题

step 1: 隐身模式打开chrome

目的是避免缓存以及不必要的问题


step 2: 打开测试地址

谷歌性能测试地址 https://googlechrome.github.io/devtools-samples/jank/
可以看到如下的页面:

页面中有一些蓝色小方块在运动


step 3: 限制 cpu 速度

由于有些用户的设备 cpu 性能很高,无法很好的分析移动端,或者发现低级设备的性能问题,所以我们要降速
找到控制台中的 performance 项,找到 CPU 选项,选择降低 4 倍性能或 6 倍性能


step 4:添加运动小块,找到性能瓶颈

前面限制了 cpu 的性能,接下来就要找到性能瓶颈了
连续点击 Add 10 按钮,向页面中添加小块,直到自己都感觉页面上小块运动出现明显卡顿

类似下面这种情况,就已经明显卡顿了


step 5:先看看优化后的效果会怎样?

点击一下 Optimize 优化,观察一下效果

可以看到页面瞬间变的贼流畅


step 6:体验过优化,再体验一次不优化

再点击一次 Un-Optimize(不优化)按钮,可以看到又卡的要死

ok,到这里,大家已经能够通过现象发现性能的差异了,接下来就是要分析现象了


二,了解 performance 各模块

如何分析现象,肯定要依赖数据,这里就要用到 chrome 的 performance 功能了
先将页面切到非优化的状态,点击“录制”按钮

录制 4s-5s 即可:

然后就可以看到录制的效果了:

上面这些数据看不懂没关系,现在来一步步了解各个部分都有哪些内容


step 1:了解 Fps

fps:是指页面每秒帧数
fps = 60 性能极佳
fps < 24 会让用户感觉到卡顿,因为人眼的识别主要是 24 帧

图中蓝色标注出来的区域,就是FPS记录的信息
放大点看,FPS 由两部分组成:
1,红色的条
2,绿色的半透明条


action :1 切换至“已优化”状态

此时切换优化状态,到已优化的状态,再次进行性能录制:

得到Fps数据如下:

可以看到此时:
1,没有了红色条
2,绿色半透明条的高度,明显要比未优化的场景高度要高不少

总结:

  • 红色:意味着帧数已经下降到影响用户体验的程度,chrome已经帮你标注了,这块有问题

  • 绿色:其实就是Fps指数,所有绿色柱体高度越高,性能越好


step 2:了解 Cpu

上图中 Fps 下面的位置,即是 Cpu 信息
我们再采集一个真实业务的 cpu 数据,如下图:

对比可以发现,cpu数据的一些特性:

  • 1,cpu 包括两种状态:

  • (1)充满颜色

  • (2)不充满颜色

  • 2,cpu 是否充满颜色和 fps 存在联系


step 3:了解 Net

Net 部分可以将屏幕逐帧录制下来,可以帮助观察页面的状态,主要用处,可以帮助分析首屏渲染速度


step 4:了解 Frames

1,查看特定帧的 fps

Frames 部分,主要用于查看特定帧的 fps,可以查看特定的帧情况。

2,悬停其上,可以查看数据

可以看到:

  • 这一帧的时间间隔是 129.1ms
  • 当前的 fps 是 1000ms/129.1ms = 7.75 fps,约等于 8 fps

这里主要体现的是页面两次刷新之间间隔了 129.1ms

3,点击 Frames 块,得到更详细的数据

点击 Frames 可以显示当前关键帧的详细信息:

  • 1,duration 是当前帧从 796.31ms 开始等待,796.31 ms + 127.73 ms 后进行了一次渲染

  • 2,fps 还是老算法,1000 ms/127.73 ms 约 等于 7fps

  • 3,最下面是关键帧的视图画像


step 5:了解 FPS 快捷工具

1,在 chrome 中,还有格 more tools 选项,选中 rendering 选项

2,开启 fps meter 开关

3,直接在页面上,出现了一个fps统计器

这个东西,暂时先关闭,不利于系统性的学习

三,找到瓶颈

前面已经知道我们的测试页面有性能问题,那么接下来就要想为什么了?


step 1:了解 Summary

对性能进行录制完成的时候,会默认在底部展示一个 Summary 摘要,显示全局的信息

上面展示了 0~5.52 s 录制时间的具体耗时:

  • 1,script 执行耗时 1952.8 ms
  • 2,render 渲染耗时 2986.8 ms
  • 3,Painting 重绘耗时 472.1 ms

主要就是这 3 个耗时,知道了这三部分耗时,只是知道了,哪有问题,但具体问题在哪呢?


step 2:了解 Main


上图,红色边框圈出来的,就是 Main 部分,其中每一块是每一帧中所做的事情


目前这样看不出来什么,脑壳疼,为了方便我们观看,我们可以在 fps、cpu、net 模块,点击一下,缩小时间区间

如上图,可以通过缩小时间区间,从而放大 Main 中的内容
现在已经能够看到,Main 中展示的是火焰图,也就是函数调用的堆栈

火焰图,可以简单理解,x 轴表示时间,y 轴表示调用的函数,函数中还包含依次调用的函数,y 轴只占用 x 轴的一个时间维度


step 3:识别问题,红色三角号

上图中,可以看到 Animation Frame Fired 右上角有个红色三角号,这就是chrome 自动帮助识别出有问题的部分
就像 FPS 中的红条一样,用来识别问题

上图可以看到提示了Warning : 重复处理程序耗时287.77毫秒


step 4:追溯问题,定位代码位置

如上图,可以看到函数调用在代码中的位置,可以点击进行查看

虽然定位到了,是方法update造成的问题,但不够明确,所以需要进一步探索


step 5:进一步分析问题位置

继续查看 Main,可以看到 app.update 下面有很多紫色的条,紫色条本身表示渲染
但请注意!!!紫色条上还有更小的
运用前面学过放大功能,调整时间区间

可以看到,每个小紫条上,都有一个红色三角
前面提到:红色三角就是 chrome 帮助自动识别有问题的地方
查看提示信息:强制回流可能是性能瓶颈
点击查看摘要:

可以看到问题定位在了,app.js 的 71 行,点击查看,能够看到是对每一个元素进行样式修改

此代码的问题在于,在每个动画帧中,它会更改每个方块的样式,然后查询页面上每个方块的位置。由于样式发生了变化,浏览器不知道每个方块的位置是否发生了变化,因此必须重新布局方块以计算其位置。

避免这种情况的出现,可以参考 https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing#avoidforcedsynchronous_layouts


step 6:对比优化的效果

demo中存在两种状态,优化和非优化
可以看到优化的状态,script和render的时间都大大减少了
所以fps明显提高

step 7:性能优化的知识储备

使用 rail 模型测量性能 https://developers.google.com/web/fundamentals/performance/rail
基础储备:

  • 渲染性能概述https://developers.google.com/web/fundamentals/performance/rendering/
  • A Frame 的剖析 https://aerotwist.com/blog/the-anatomy-of-a-frame/

Chrome 81 正式发布 !消灭混合内容最后一步~

Chrome 81 于前天正式发布了,这个版本其实最初是计划在 3 月 17 号 发布的,但由于冠状病毒(COVID-19)爆发而导致推迟到了现在。Chrome 81 的延迟也扰乱了 Google 正常的六周发布时间表。因此 Google 此前也宣布,下一个版本将直接跳过 Chrome 82 ,直接发布 Chrome 83。 下面我就来带大家看看 Chrome 81 有哪些重要的更新。

发布于:1月以前  |  104次阅读  |  详细内容 »

当浏览器全面禁用三方 Cookie

苹果公司前不久对 Safari 浏览器进行一次重大更新,这次更新完全禁用了第三方 Cookie,这意味着,默认情况下,各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie,但是由于这些浏览器市场份额较小,并没有给市场带来巨大的冲击。

发布于:1月以前  |  91次阅读  |  详细内容 »

H5 直播的疯狂点赞动画是如何实现的?

直播有一个很重要的互动:点赞。 为了烘托直播间的氛围,直播相对于普通视频或者文本内容,点赞通常有两个特殊需求: 点赞动作无限次,引导用户疯狂点赞 直播间的所有疯狂点赞,都需要在所有用户界面都动画展现出来(广播用户使用websocket消息)

发布于:1月以前  |  88次阅读  |  详细内容 »

探索 Serverless 中的前端开发模式

最近关于 Serverless 的讨论越来越多。看似与前端关系不大的 Serverless,其实早已和前端有了渊源,并且将对前端开发模式产生变革性的影响。本文主要就根据个人理解和总结,从前端开发模式的演进、基于 Serverless 的前端开发案例以及 Serverless 开发最佳实践等方面,与大家探讨 Serverless 中的前端开发模式。本人也有幸在 QCon2019 分享了这一主题。

发布于:1月以前  |  115次阅读  |  详细内容 »

前端需要了解的9种设计模式

设计模式是对软件设计开发过程中反复出现的某类问题的通用解决方案。设计模式更多的是指导思想和方法论,而不是现成的代码,当然每种设计模式都有每种语言中的具体实现方式。学习设计模式更多的是理解各种模式的内在思想和解决的问题,毕竟这是前人无数经验总结成的最佳实践,而代码实现则是对加深理解的辅助。

发布于:1月以前  |  96次阅读  |  详细内容 »

为什么你的网页需要 CSP?

内容安全策略(CSP)是一个 HTTP Header,CSP 通过告诉浏览器一系列规则,严格规定页面中哪些资源允许有哪些来源, 不在指定范围内的统统拒绝。

发布于:1月以前  |  86次阅读  |  详细内容 »

10 种跨域解决方案(附终极方案)

嗯。又来了,又说到跨域了,这是一个老生常谈的话题,以前我觉得这种基础文章没有什么好写的,会想着你去了解底层啊,不是很简单吗。但是最近在开发一个 「vscode 插件」 发现,当你刚入门一样东西的时候,你不会想这么多,因为你对他不熟悉,当你遇到不会的东西,你就是想先找到解决方案,然后通过这个解决方案再去深入理解。

发布于:1月以前  |  140次阅读  |  详细内容 »

移动 Web 最佳实践(干货长文,建议收藏)

笔者在公司用 web 技术开发移动端应用已经有一年多的时间了,开始主要以 vue 技术栈配合 native 为主,目前演进成 vue + react native 技术架构,vue 主要负责开发 OA 业务,比如报销、出差、crm 等等,react native 主要负责即时通信部分,是在 mattermost-mobile的基础上修改的(mattermost 是一个开源的即时通讯方案)。

发布于:1月以前  |  100次阅读  |  详细内容 »

不可错过的实用前端工具

给大家整理了 25 个前端相关的学习网站和一些靠谱的小工具,包括一些小游戏、教程、社区网站和博客,以及一些资源网站,希望可以帮助到大家!

发布于:1月以前  |  92次阅读  |  详细内容 »

理解 WebView

我们通常使用 Chrome, Firefox, Safari, Internet Explorer 和 Edge 等浏览器来浏览网页。你也许正在使用其中一种浏览器阅读本文!虽然浏览器对于访问互联网内容的任务来说非常流行,它们还有一些我们从未过多关注过的竞争对手。这些竞争对手以 WebView 的形式被我们所熟知。这片文章将讲解 WebView 的神秘之处以及为什么它这么棒。

发布于:1月以前  |  94次阅读  |  详细内容 »

Facebook 前端技术栈重构分享

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对Facebook(我们已知的)所有期望的功能,我们现有的技术栈无法支持我们所需要的类似于桌面应用的感觉和性能。

发布于:1月以前  |  95次阅读  |  详细内容 »

最多阅读

为Electron程序添加运行时日志 1年以前  |  4813次阅读
初探 React 组件 1年以前  |  2169次阅读
wordpress标签页的制作 1年以前  |  2056次阅读
Node.js下通过配置host访问URL 1年以前  |  1995次阅读
js动态创建类和实例化 1年以前  |  1975次阅读
500行PHP代码搞定富文本安全过滤 1年以前  |  1954次阅读
22个HTML5的初级技巧 1年以前  |  1902次阅读
使用 SRI 增强 localStorage 代码安全 1年以前  |  1901次阅读
浅谈浏览器的原生拖拽事件 1年以前  |  1869次阅读
第三版主题上线 1年以前  |  1859次阅读
CSS清除浮动 1年以前  |  1855次阅读
2014年度总结 1年以前  |  1805次阅读
【译】V8 团队眼中的 ES6、ES7及未来 1年以前  |  1799次阅读
利用服务器返回header来传输数据 1年以前  |  1788次阅读
获取元素的计算的样式 1年以前  |  1784次阅读