摘要：避免这种情况的出现，可以参考对比优化的效果中存在两种状态，优化和非优化可以看到优化的状态，和的时间都大大减少了所以明显提高性能优化的知识储备使用模型测量性能基础储备渲染性能概述的剖析
一，初探，根据现象发现问题chrome的performance知道很久了，但总是没有特别权威且跟上时代的学习资料，这次痛定思痛，直接看英文文档，一点点把这块啃掉，本笔记基于Chrome 59
目的是避免缓存以及不必要的问题
谷歌性能测试地址googlechrome.github.io/devtools-sa…
可以看到如下的页面：
由于有些用户的设备cpu性能很高，无法很好的分析移动端，或者发现低级设备的性能问题，所以我们要降速
找到控制台中的performance项，找到CPU选项，选择降低4倍性能或6倍性能
前面限制了cpu的性能，接下来就要找到性能瓶颈了
连续点击Add 10按钮，向页面中添加小块，直到自己都感觉页面上小块运动出现明显卡顿
点击一下Optimize优化，观察一下效果
再点击一次Un-Optimize（不优化）按钮，可以看到又卡的要死
如何分析现象，肯定要依赖数据，这里就要用到chrome的performance功能了
先将页面切到非优化的状态，点击“录制”按钮
录制4s-5s即可：
然后就可以看到录制的效果了：
fps：是指页面每秒帧数
fps = 60 性能极佳
fps < 24 会让用户感觉到卡顿，因为人眼的识别主要是24帧
此时切换优化状态，到已优化的状态，再次进行性能录制：
可以看到此时：
1，没有了红色条
2，绿色半透明条的高度，明显要比未优化的场景高度要高不少
总结：
红色：意味着帧数已经下降到影响用户体验的程度，chrome已经帮你标注了，这块有问题
绿色：其实就是Fps指数，所有绿色柱体高度越高，性能越好
上图中Fps下面的位置，即是Cpu信息
我们再采集一个真实业务的cpu数据，如下图：
对比可以发现，cpu数据的一些特性：
1，cpu包括两种状态：
（1）充满颜色
（2）不充满颜色
2，cpu是否充满颜色和fps存在联系
Net部分可以将屏幕逐帧录制下来，可以帮助观察页面的状态，主要用处，可以帮助分析首屏渲染速度
Frames部分，主要用于查看特定帧的fps，可以查看特定的帧情况。
可以看到：
这一帧的时间间隔是129.1ms
当前的fps是1000ms/129.1ms = 7.75fps，约等于8fps
这里主要体现的是页面两次刷新之间间隔了129.1ms
点击Frames可以显示当前关键帧的详细信息：
1，duration是当前帧从796.31ms开始等待，796.31ms+127.73ms后进行了一次渲染
2，fps还是老算法，1000ms/127.73ms约等于7fps
3，最下面是关键帧的视图画像
这个东西，暂时先关闭，不利于系统性的学习
三，找到瓶颈
前面已经知道我们的测试页面有性能问题，那么接下来就要想为什么了？
对性能进行录制完成的时候，会默认在底部展示一个Summary摘要，显示全局的信息
上面展示了0～5.52s录制时间的具体耗时：
1，script执行耗时1952.8ms
2，render渲染耗时2986.8ms
3，Painting重绘耗时472.1ms
主要就是这3个耗时，知道了这三部分耗时，只是知道了，哪有问题，但具体问题在哪呢？
上图，红色边框圈出来的，就是Main部分，其中每一块是每一帧中所做的事情
目前这样看不出来什么，脑壳疼，为了方便我们观看，我们可以在fps、cpu、net模块，点击一下，缩小时间区间
火焰图，可以简单理解，x轴表示时间，y轴表示调用的函数，函数中还包含依次调用的函数，y轴只占用x轴的一个时间维度
上图中，可以看到Animation Frame Fired右上角有个红色三角号，这就是chrome自动帮助识别出有问题的部分
就像FPS中的红条一样，用来识别问题
上图可以看到提示了Warning : 重复处理程序耗时287.77毫秒
如上图，可以看到函数调用在代码中的位置，可以点击进行查看
继续查看Main，可以看到app.update下面有很多紫色的条，紫色条本身表示渲染
但请注意！！！ 紫色条上还有更小的
运用前面学过放大功能，调整时间区间
可以看到，每个小紫条上，都有一个红色三角
前面提到：红色三角就是chrome帮助自动识别有问题的地方
查看提示信息：强制回流可能是性能瓶颈
点击查看摘要：
可以看到问题定位在了，app.js的71行，点击查看，能够看到是对每一个元素进行样式修改
此代码的问题在于，在每个动画帧中，它会更改每个方块的样式，然后查询页面上每个方块的位置。由于样式发生了变化，浏览器不知道每个方块的位置是否发生了变化，因此必须重新布局方块以计算其位置。
避免这种情况的出现，可以参考developers.google.com/web/fundame…
demo中存在两种状态，优化和非优化
可以看到优化的状态，script和render的时间都大大减少了
所以fps明显提高
step 7：性能优化的知识储备
使用rail模型测量性能developers.google.com/web/fundame…
基础储备：
渲染性能概述developers.google.com/web/fundame…
A Frame 的剖析aerotwist.com/blog/the-an…
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/6811.html
摘要：分析每一秒的帧是用来分析动画的一个主要性能指标。轴代表了调用栈。在事件长条的右上角出，如果出现了红色小三角，说明这个事件是存在问题的，需要特别注意。双击这个带有红色小三角的的事件。 运行时性能表现（runtime performance）指的是当你的页面在浏览器运行时的性能表现，而不是在下载页面的时候的表现。这篇指南将会告诉你怎么用Chrome DevTools Performance...
摘要：原文地址开始在本教程中，你将学会如何使用性能分析工具分析页面上的性能瓶颈。其中包含了捕获性能指标相关的设置。参考分析优化版的性能使用刚刚学习的工作流和工具，单击演示中的优化以启用优化的代码，进行另一次性能记录，然后分析结果。 原文地址：https://developers.google.com... 开始 在本教程中，你将学会如何使用性能分析工具分析页面上的性能瓶颈。 在隐身模式下打...
摘要：启动性能瓶颈分析与解决方案翻译自的，从属于笔者的前端入门与工程实践。我们必须要清醒地认识到全面评测以挖掘出真正性能瓶颈的重要性。这可能是最佳的方式了，类似于这样的模式鼓励基于路由的分组，目前被与广泛使用。 JavaScript 启动性能瓶颈分析与解决方案 翻译自 Addy Osmani 的 JavaScript Start-up Performance，从属于笔者的Web 前端入门与工...
摘要：如果网页动画能够做到每秒帧，就会跟显示器同步刷新，达到最佳的视觉效果。下面的一条是，低于这条线，可以达到每秒帧上面的一条是，低于这条线，可以达到每秒次渲染。图中帧柱的高度表示了该帧的总耗时，帧柱中的颜色分别对应该帧中包含的不停类型的事件。 原文地址：http://horve.github.io/2015/10/26/timeli... 随着webpage可以承载的表现形式更加多样化，通...
摘要：因此，如果可能，最好利用好毫秒响应预先计算开销大的工作，这样网站就更有可能实现的性能。空闲主线程工作分成不大于毫秒的块。点击按钮见图示，会在页面运行时捕获性能指标。 前言 经常能在博客或者论坛上看到很多有关前端性能优化的文章，但是却很少看到如何分析一个网页的性能的文章。到底什么样的指标（或者说是标准）代表这个网页性能好或者不好，通过什么方式来得到这些指标呢？因此，本文来讲述下如何分析一...
阅读 692·2021-10-11 10:59
阅读 2643·2019-08-30 15:43
阅读 2023·2019-08-30 11:08
阅读 1553·2019-08-29 15:20
阅读 815·2019-08-29 13:53
阅读 383·2019-08-26 13:24
阅读 1490·2019-08-26 13:24
阅读 2705·2019-08-26 12:08
