前端性能优化之利用 Chrome Dev Tools 进行页面性能分析

背景

咱们常用 Chrome Dev Tools 来开发调试,可是不多知道怎么利用它来分析页面性能,这篇文章,我将详细说明怎样利用 Chrome Dev Tools 进行页面性能分析及性能报告数据如何解读。css

分析面板介绍

GitHub
上图是 Chrome Dev Tools 的一个截图,其中,我认为能用于进行页面性能快速分析的主要是图中圈出来的几个模块功能,这里简单介绍一下:html

  • Network : 页面中各类资源请求的状况,这里能看到资源的名称、状态、使用的协议(http1/http2/quic...)、资源类型、资源大小、资源时间线等状况
  • Performance : 页面各项性能指标的火焰图,这里能看到白屏时间、FPS、资源加载时间线、longtask、内存变化曲线等等信息
  • Memory : 能够记录某个时刻的页面内存状况,通常用于分析内存泄露
  • JavaScript Profiler : 能够记录函数的耗时状况,方便找出耗时较多的函数
  • Layers : 展现页面中的分层状况

分析步骤说明

首先,咱们在分析的时候,建议使用隐身模式打开页面,排除一些插件等因素对页面性能状况的影响。而后,咱们把页面缓存勾选去掉,要测 disable cache 的状况,再把网络状况调整一下,咱们用电脑打开页面的时候通常都连着 wifi 等,要更真实一些去测页面的性能,仍是把网络调到 3G 等状况比较好,如图:
GitHub
调整好以后,咱们切到 Performance 面板,这里先说明一下一些按钮的做用:
GitHub
上图,从左到右分别表明的是:前端

  1. 手动开始记录,开始后须要手动结束
  2. 自动重启页面,并记录整个页面加载的过程。这个是最经常使用的,通常大概分析页面性能的时候都是点这个就够了
  3. 清除性能录制的记录
  4. 上传页面性能录制的数据
  5. 下载页面性能录制的数据
  6. 选择要展现的性能记录。你可能进行了屡次分析,这里能够切换去看每次的结果
  7. 是否捕捉页面加载过程的截图,这个通常都要勾选
  8. 是否记录内存变化,这个通常都要勾选
  9. 垃圾回收,点击了即进行一次垃圾回收

这里,我以京东的一个页面为例,勾选 disable cache,网络状况为 Fast 3G,来讲明一下,应该如何理解性能结果,找出优化点。git

从网络面板分析

咱们来看看网络面板,看看都有哪些信息。以下图所示:
GitHub
从图中能够看出,页面中有的一些性能优化手段有:github

  1. 页面直出,输入https://wq.jd.com/wxportal/index_v6 ,页面加载回来的 document 就是一个渲染好的 html 页面
  2. 图片优化,部署在不一样的CDN域名下,用webp/dpg等格式图片,图片切割等
  3. http 协议有部分采用 http2,多路复用,加快资源加载
  4. 小 logo 使用base42来处理
  5. 按需加载,菜单先加载第一屏的图标,滑动到第二屏时再加载第二屏的图标

而从图片,我的认为,还能够考虑用上的一些性能优化手段有:web

  1. html 的大小为138kb,Content Download的时间为七百多毫秒,感受能够拆分一下页面,非一二屏的内容分开加载。
  2. TTFB(Time To First Byte)为五百多毫秒,在下载第一个字节以前等待的时间太久,不过这里主要是用户网络状况影响,能够作的比较少。如DNS解析优化,减小后端服务处理时间等
  3. 合并雪碧图,大轮播图下面的菜单分类那里的图标,能够用一张雪碧图来集合这些图标
  4. 顶部轮播图,在首次加载时,能够先加载第一帧的图片,后面几帧延后一下
  5. 图片较多,能够的话,都用 http2 协议

从性能面板分析

切到 Performance 面板,点击自动重启页面,并记录整个页面加载的过程,而后来分析结果~​后端

网络&&白屏

性能面板,有不少不少的参数,咱们要看一些比较常见的。首先看白屏时间和网络加载状况,以下图:
GitHub
上图,咱们能够看几点信息:浏览器

  1. 本次页面加载的白屏时间约为 1000 ms
  2. FPS 曲线没有标红,若是有不少标红的则说明页面存在渲染卡顿多的地方
  3. 从网络资源加载状况来看,图片没有启用 http2,所以每次能够同时加载的图片数有限,未被加载的图片有等待过程
  4. 资源的加载时间也能够看到,好比轮播的背景图加载了近 700 毫秒,时间有点长

另外,咱们能够看一下资源加载有没有空白期,虽然上图没有,可是若是资源加载之间存在空白期,说明没有充分利用资源加载的空闲时间,能够调整一下。缓存

火焰图

火焰图,主要在 Main 面板中,是咱们分析具体函数耗时最常看的面板,咱们来看一下,如图:
GitHub性能优化

首先,面板中会有不少的 Task,若是是耗时长的 Task,其右上角会标红(图中没有,说明页面首屏的逻辑处理分配得还不错),这个时候,咱们能够选中标红的 Task (这里就随手选中一个),而后放大(选中,滑动鼠标可放大),看其具体的耗时点。

放大后,这里能够看到都在作哪些操做,哪些函数耗时了多少,这里代码有压缩,看到的是压缩后的函数名。而后咱们点击一下某个函数,在面板最下面,就会出现代码的信息,是哪一个函数,耗时多少,在哪一个文件上的第几行等。这样咱们就很方便地定位到耗时函数了。

还能够横向切换 tab ,看它的调用栈等状况,更方便地找到对应代码。具体你们能够试试~

时间线&&内存状况

在 Timings 的区域,咱们能够看到本次加载的一些关键时间,分别有:

  • FCP: First Contentful Paint
  • LCP: Largest Contentful Paint
  • FMP: First Meaningful Paint
  • DCL: DOMContentLoaded Event
  • L: Onload Event

咱们能够选区(选择从白屏到有内容的区域,表明本次的页面加载过程),能够对照着看一下上面的时间,截图以下:
GitHub
另外,咱们能够看到页面中的内存使用的状况,好比 JS Heap(堆),若是曲线一直在增加,则说明存在内存泄露,从图中能够看出,至关长的一段时间,内存曲线都是没有降低的,这里是有发生内存泄露的可能的,在 Onload 以后,内存才获得释放。更多内存泄露产生的缘由及分析方法,能够参照个人这篇文章《Chrome 浏览器垃圾回收机制与内存泄漏分析

最下方就是页面的一个整理耗时概况,若是 Scripting 时间过长,则说明 js执行的逻辑太多,能够考虑优化js,若是渲染时间过长,则考虑优化渲染过程,若是空闲时间过多,则能够考虑充分利用起来,好比把一些上报操做放到页面空闲时间再上报等。

其余面板

以上就是性能面板能够看的一些信息。另外,咱们能够借助 Layers面板来查看页面分层状况的3D视图,Rendering面板(点击more tools->Rendering便可打开),勾选Layer Bordersk能够看到复合层、RenderLayer区域,能够帮助分析动画卡顿、是否开启GPU加速等问题,而 Memory 面板 和 JavaScript Profiler 面板主要是分析内存泄露的,这里就不说了,能够看我另外一篇文章《Chrome 浏览器垃圾回收机制与内存泄漏分析

用Audits工具分析

Audits 其实就是 LightHouse,LightHouse 是Google开源的一个自动化测试工具,它经过一系列的规则来对网页进行评估分析,最终给出一份评估报告。它的面板是这样的:
GitHub

总体状况

Audits主要从5个方面来给网页打分,固然你也能够去掉某些方面的评估。在选择了设备、评估方面、网络状况等选项后,点击 Run Audits ,咱们将会获得一份报告。
GitHub

上图是一个整体报告,能够看出,这个页面的性能不太合格。固然一次的测试也说明不了什么问题,只能作个参考。咱们看它的性能指标分别有:

  • First Contentful Paint:内容首次开始绘制。
  • First Meaningful Paint:能够简单理解为用户看到网页主要内容的时间,分数越低,页面显示其主要内容的速度就越快。图中例子,网页首次有效绘制时间为2.5s。
  • Speed Index:速度指标是一个页面加载性能指标,向你展现明显填充页面内容的速度,此指标的分数越低越好。
  • First CPU Idle:首次 CPU 空闲时间
  • Time to Interactive:可互动时间,页面中的大多数网络资源完成加载而且CPU在很长一段时间都很空闲的所需的时间。此时能够预期cpu很是空闲,能够及时的处理用户的交互操做。
  • Max Potential First Input Delay:最大的输入延迟时间,输入响应能力对用户如何看待你应用的性能起着关键做用。应用有 100 毫秒的时间响应用户输入。若是超过此时间,用户就会认为应用反应迟缓。

这些时间,均可以点击图中红框切换展现方式,会附上对应的时间解释,而后能够点击 Learn more 来查看详细的指标介绍。在文档中,每一项指标都会明确的分为三个部分:为何说此审查很是重要;如何经过此审查;如何实现此审查;

性能指标优化建议解读

性能建议主要分为3类, Opportunities 可优化项、手动诊断项、经过的审查项。本次的例子以下图:
GitHub

图中的每一项均可以展开来看明细解释,其中:

可优化项有2个建议:

  1. 延迟会阻塞渲染的资源加载,这里是一个 navfoot.6bf68af7.css
  2. 延迟视口外的图片加载,这里列举了没必要要加载的图片(和我上文提的优化建议一致,哈哈)

这项里面的内容指的是LightHouse发现的一些能够直接优化的点,你能够对应这些点来进行优化。

手动诊断项有6个建议:

  1. 最小化主线程工做
  2. 减小JavaScript执行时间
  3. 避免DOM太大
  4. 经过有效的缓存策略缓存一些静态资源
  5. 避免连接关键请求
  6. 保持低请求数量和小传输大小

这些项目表示LightHouse并不能替你决定当前是好是坏,可是把详情列出来,由你手动排查每一个项目的状况

经过的审查项

这里列出的都是作的好的地方,本文例子共有16条,不过即便作的好,依然值得咱们进去仔细看一下,由于像全部条目同样,这里的每一个条目也有一个showmore,咱们能够点进去仔细学习背后的知识和原理!

Accessibility辅助功能

辅助功能指的是那些可能超出"普通"用户范围以外的用户的体验,他们以不一样于你指望的方式访问你的网页或进行交互,本文的例子建议以下图:
GitHub

辅助功能类别测试屏幕阅读器的能力和其余辅助技术是否能在页面中正常工做。例如:按元素来使用属性,标签使用是否规范,img 标签是否缺乏 alt 属性,可辨别的元素命名等等。这一项咱们不展开讲,可是仍是建议你们按照审计建议修改一下网页。

其余几项,本文的例子最佳实践评分挺高的,而例子不支持PWA,也不须要考虑SEO,这里就不展开说明了,有对应需求的能够本身详细看看便可。

总结

最后总结一下,咱们利用Chrome Dev Tools 进行页面性能分析有如下指标能够参考:

  • 从网络面板分析
  • 从性能面板分析
  • 从Memory面板等分析内存泄露
  • 用Audits工具分析

而这些分析方法,本文都详细写了。能够认真看看~

姊妹篇推荐

最后

  • 欢迎加我微信(winty230),拉你进技术群,长期交流学习...
  • 欢迎关注「前端Q」,认真学前端,作个有专业的技术人...

GitHub

相关文章
相关标签/搜索