我们经常使用 Chrome Dev Tools 来开发调试,但是很少知道怎么利用它来分析页面性能,这篇文章,我将详细说明怎样利用 Chrome Dev Tools 进行页面性能分析及性能报告数据如何解读。
上图是 Chrome Dev Tools 的一个截图,其中,我认为能用于进行页面性能快速分析的主要是图中圈出来的几个模块功能,这里简单介绍一下:
首先,我们在分析的时候,建议使用隐身模式打开页面,排除一些插件等因素对页面性能情况的影响。然后,我们把页面缓存勾选去掉,要测 disable cache 的情况,再把网络情况调整一下,我们用电脑打开页面的时候一般都连着 wifi 等,要更真实一些去测页面的性能,还是把网络调到 3G 等情况比较好,如图:
调整好之后,我们切到 Performance 面板,这里先说明一下一些按钮的作用:
上图,从左到右分别代表的是:
这里,我以京东的一个页面为例,勾选 disable cache,网络情况为 Fast 3G,来说明一下,应该如何理解性能结果,找出优化点。
我们来看看网络面板,看看都有哪些信息。如下图所示:
从图中可以看出,页面中有的一些性能优化手段有:
而从图片,个人认为,还可以考虑用上的一些性能优化手段有:
切到 Performance 面板,点击自动重启页面,并记录整个页面加载的过程,然后来分析结果~
网络&&白屏
性能面板,有很多很多的参数,我们要看一些比较常见的。首先看白屏时间和网络加载情况,如下图:
上图,我们可以看几点信息:
另外,我们可以看一下资源加载有没有空白期,虽然上图没有,但是如果资源加载之间存在空白期,说明没有充分利用资源加载的空闲时间,可以调整一下。
火焰图
火焰图,主要在 Main 面板中,是我们分析具体函数耗时最常看的面板,我们来看一下,如图:
首先,面板中会有很多的 Task,如果是耗时长的 Task,其右上角会标红(图中没有,说明页面首屏的逻辑处理分配得还不错),这个时候,我们可以选中标红的 Task (这里就随手选中一个),然后放大(选中,滑动鼠标可放大),看其具体的耗时点。
放大后,这里可以看到都在做哪些操作,哪些函数耗时了多少,这里代码有压缩,看到的是压缩后的函数名。然后我们点击一下某个函数,在面板最下面,就会出现代码的信息,是哪个函数,耗时多少,在哪个文件上的第几行等。这样我们就很方便地定位到耗时函数了。
还可以横向切换 tab ,看它的调用栈等情况,更方便地找到对应代码。具体大家可以试试~
时间线&&内存情况
在 Timings 的区域,我们可以看到本次加载的一些关键时间,分别有:
我们可以选区(选择从白屏到有内容的区域,代表本次的页面加载过程),可以对照着看一下上面的时间,截图如下:
另外,我们可以看到页面中的内存使用的情况,比如 JS Heap(堆),如果曲线一直在增长,则说明存在内存泄露,从图中可以看出,相当长的一段时间,内存曲线都是没有下降的,这里是有发生内存泄露的可能的,在 Onload 之后,内存才得到释放。更多内存泄露产生的原因及分析方法,可以参照我的这篇文章《Chrome 浏览器垃圾回收机制与内存泄漏分析》
最下方就是页面的一个整理耗时概况,如果 Scripting 时间过长,则说明 js执行的逻辑太多,可以考虑优化js,如果渲染时间过长,则考虑优化渲染过程,如果空闲时间过多,则可以考虑充分利用起来,比如把一些上报操作放到页面空闲时间再上报等。
以上就是性能面板可以看的一些信息。另外,我们可以借助 Layers面板来查看页面分层情况的3D视图,Rendering面板(点击more tools->Rendering即可打开),勾选Layer Bordersk可以看到复合层、RenderLayer区域,可以帮助分析动画卡顿、是否开启GPU加速等问题,而 Memory 面板 和 JavaScript Profiler 面板主要是分析内存泄露的,这里就不说了,可以看我另一篇文章《Chrome 浏览器垃圾回收机制与内存泄漏分析》
Audits 其实就是 LightHouse,LightHouse 是Google开源的一个自动化测试工具,它通过一系列的规则来对网页进行评估分析,最终给出一份评估报告。它的面板是这样的:
整体情况
Audits主要从5个方面来给网页打分,当然你也可以去掉某些方面的评估。在选择了设备、评估方面、网络情况等选项后,点击 Run Audits ,我们将会得到一份报告。
上图是一个总体报告,可以看出,这个页面的性能不太合格。当然一次的测试也说明不了什么问题,只能做个参考。我们看它的性能指标分别有:
这些时间,都可以点击图中红框切换展示方式,会附上对应的时间解释,然后可以点击 Learn more 来查看详细的指标介绍。在文档中,每一项指标都会明确的分为三个部分:为什么说此审查非常重要;如何通过此审查;如何实现此审查;
性能建议主要分为3类, Opportunities 可优化项、手动诊断项、通过的审查项。本次的例子如下图:
图中的每一项都可以展开来看明细解释,其中:
这项里面的内容指的是LightHouse发现的一些可以直接优化的点,你可以对应这些点来进行优化。
这些项目表示LightHouse并不能替你决定当前是好是坏,但是把详情列出来,由你手动排查每个项目的情况
这里列出的都是做的好的地方,本文例子共有16条,不过即使做的好,依然值得我们进去仔细看一下,因为像所有条目一样,这里的每个条目也有一个showmore,我们可以点进去仔细学习背后的知识和原理!
辅助功能指的是那些可能超出"普通"用户范围之外的用户的体验,他们以不同于你期望的方式访问你的网页或进行交互,本文的例子建议如下图:
辅助功能类别测试屏幕阅读器的能力和其他辅助技术是否能在页面中正常工作。例如:按元素来使用属性,标签使用是否规范,img 标签是否缺少 alt 属性,可辨别的元素命名等等。这一项我们不展开讲,但是还是建议大家按照审计建议修改一下网页。
其他几项,本文的例子最佳实践评分挺高的,而例子不支持PWA,也不需要考虑SEO,这里就不展开说明了,有对应需求的可以自己详细看看即可。
最后总结一下,我们利用Chrome Dev Tools 进行页面性能分析有以下指标可以参考:
而这些分析方法,本文都详细写了。可以认真看看~
到此这篇关于利用 Chrome Dev Tools 进行页面性能分析的步骤说明(前端性能优化)的文章就介绍到这了,更多相关 Chrome Dev Tools 页面性能内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!
问题内容: 我正在使用Node.js进行一些Web抓取。我想使用XPath,因为我可以使用几种GUI半自动生成它。问题是我找不到有效的方法。 非常慢。它会在一分钟左右的时间内解析500KiB文件,并具有完整的CPU负载和大量内存。 流行的HTML解析库(例如)既不支持XPath,也不公开W3C兼容的DOM。 很明显,有效的HTML解析是在WebKit中实现的,因此可以使用或将其作为一种选择,但这些
本文最初发表于博客园,并在GitHub上持续更新前端的系列文章。欢迎在GitHub上关注我,一起入门和进阶前端。 以下是正文。 前言 提升页面性能优化的方法有哪些: 1、资源压缩合并,减少http请求 2、非核心代码异步加载 --> 异步加载的方式 --> 异步加载的区别 如果回答出非核心代码异步加载,就会层层深入。 3、利用浏览器缓存 --> 缓存的分类 --> 缓存的原理 缓存是所有性能优化的
根据 Go 开发团队和基本的算法测试,Go 语言与 C 语言的性能差距大概在 10%~20% 之间( 译者注:由于出版时间限制,该数据应为 2013 年 3 月 28 日之前产生 )。虽然没有官方的性能标准,但是与其它各个语言相比已经拥有非常出色的表现。 如果说 Go 语言的执行效率大约比 C++ 慢 20% 也许更有实际意义。保守估计在相同的环境和执行目标的情况下,Go 程序比 Java 或 S
JIT与GC优化 > untyped(无类型)。 JAVASCRIPT是个无类型的语言,这导致了如x=y+z这种表达式可以有很多含义。 y,z是数字,则+表示加法。 y,z是字符串,则+表示字符串连接。 而JS引擎内部则使用“细粒度”的类型,比如: 32-bit* integer。 64-bit* floating-point。 这就要求js类型-js引擎类型,需要做“boxed/unboxed(
Ruby、Rails 性能分析与优化 性能统计 性能监控的好工具 - NewRelic 简介 你不知道的 New Relic InfluxDB + Grafana 快速搭建自己的 NewRelic,分析应用运行情况 如何持续监控 Unicorn 的性能指标 性能分析 检测 Rails action 的内存开销 rails-perftest - 分析你的 Rails 应用的性能 优化 Perform
我开始写前端应用的时候,并不知道一个 Web 应用需要优化那么多的东西。编写应用的时候,运行在本地的机器上,没有网络问题,也没有多少的性能问题。可当我把自己写的博客部署到服务器上时,我才发现原来我的应用在生产环境上这么脆弱。 我的第一个真正意义上的 Web 应用——开发完应用,并可供全世界访问,是我的博客。它运行在一个共享 256 M 内存的 VPS 服务器上,并且服务器是在国外,受限于网络没有备