We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
首先,本文并不会讲述所有的性能优化的瓶颈如何分析并提供解决方案,只能大致讲述查看性能的思路,绝大多数的分析数据都是来自Aduits Panel、 Performance Panel 以及 Memory Panel。
核心目的就是如何提升 JavaScript 执行速度,当然你可以查看官网学会较好落地的解决方案。
若已经点击完了上述的解决方案,大致核心步骤已经完善了,为了不浪费你的时间,还是不建议你继续阅读下文了。
项目维护到了一定阶段,突然有用户反馈给开发,你的系统使用期间这么卡呢?其实绝大多数,我们并不清楚用户描述的卡顿到底是什么意思?是系统加载速度慢呢?还是用户体验上就是缺少没有让用户感知网站在运行的提示呢?还是由于网络问题,导致系统页面请求刷新一直在loading,而超时居然还设置超高?
如果公司有前端监控系统,还是蛮方便可以查看部分指标(如首屏加载时间)帮助我们定位对应的问题点。绝大多数的公司可能只会有若干前端,所以想要有这么一整套完善的监控体系还是比较困难的,往往很多时候就需要前端自求多福咯。
核心问题是:我们能否通过现有浏览器工具帮助我们查看站点的性能?
首先确保你的环境是干净的,最好和真正使用的用户是「一致」的环境,然后打开一个无痕页面,输入你的站点地址,顺带打开开发者工具。以上步骤的核心逻辑是,减少后续采集数据期间不必要的干扰项。
然后我们就找「人」请求,给点建议咯。毕竟这么大的站点,需要从那个维度切入现在我们并没有半点思路。然后我们找到了Aduits Panel,选中想要审查的性能评估点,进行跑分。不用多久,就会有关于各个指标的数据报告出来,而且各项指标下方,都会有部分优化的建议,根据建议修复对应的问题,可以帮助你提高各项指标。
若站点表现出来问题仅仅是性能问题的话,可以切换到 Performance Panel 点击开启记录功能,然后刷新页面,在关闭记录,等待浏览器解析一会,就可以呈现出记录这段时间的整体性能情况如何。
下述数据来源站点是,官方例子。
如果你不清楚每一个内容区域中的每个面板代表什么,可以查看同事写好的笔记。
我们可以看到很多的红色条状表标记在内容区域的最上方。标记区域就是出现性能瓶颈区域,我们根据标记定位到 Main 分区中每个执行任务,而Main分区主要是可以看到对应时间下主线程的调用栈,也就是火焰图区域。可以选择对应的任务,详情信息区域会展示对应的详情数据。
我们标记火焰图的右上角的红色标记,选中一个进行查看详情数据。
详情信息模块,大致介绍了该任务的执行时间是否是性能瓶颈,同时会标记当前 Call Stack,帮助我们定位具体功能源自脚本位置。
若提示为重排重绘问题,可以调用菜单命令唤起 Rendering Panel 勾选 「Paint flashing」,然后在页面进行查看,若查看大量绿色方块在闪烁,则表明存在重排重绘。此类问题产生多半是CSS样式导致,所以需要查询特别CSS属性是否会触发重排重绘,请查看csstriggers。
当然我们会在详情面板中看到其他三个 tabular 窗口根据不同的维度去分析整个过程的数据。
如果想看选中区间的函数调用情况,可以查看 Call Tree tabular,这里可以看到触发事件的源头造成后续函数调用以及渲染过程的情况。
左侧会有两个时间:Self Time & Total Time。前者表示此项子任务自身消耗多少时长,后者表示此项子任务包含后续子代消耗时长的总计。
该面板看到的数据都是根据调用栈,从上往下的查看对应调用的堆栈,然后查看函数间的调用逻辑,但如果仅仅想看哪项子任务消耗时长最多,建议使用 Bottom-Up tabular,这里首先看到对应的底层任务,可根据时间排序,而且点开同样可以看到该任务的调用形式,和Call Tree调用栈有点相反的感觉。
如果想要查看记录期间任务发生的顺序,可以查看 Event Log tabular,这里可以看到每个任务执行的具体顺序,以及同样任务是否重复执行的情况。
每一个Tabular中都会标明对应函数的位于脚本的位置,可以点击对应链接,工具会帮助你自动跳转到 Source Panel,左侧会出现每行代码执行的时间,你可以查看对应位置是否频繁操作 DOM 定位或是样式导致出现重排重绘问题。
以上都是根据官网提出来的例子,然后结合工具栏的功能进行的如何使用功能讲解的,更多意义上提供了想看什么数据的去哪里找的解决方案。当然可能遇见的问题以及对应的解决方案,官网已经给出,感兴趣可以阅读这里。
当然如果想查看内存泄露等等问题,用到的就是 Memory Panel 可以进行分析网站当下的调用堆栈,以及分析对应时间点下的新内存新增情况,从而进行分析问题。
但官网提供的资料,查阅了两次也不太明白讲述的意思,并且术语那章节看不下去,所以在中途章节出现了术语,理解起来还是比较模糊的,所以就没有继续分析如何使用 Memory Panel 去分析网站情况,感兴趣可以阅读这里。当然你查阅到讲述较为清楚的文章,欢迎你可以留言给我,不胜感激。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
性能优化
首先,本文并不会讲述所有的性能优化的瓶颈如何分析并提供解决方案,只能大致讲述查看性能的思路,绝大多数的分析数据都是来自Aduits Panel、 Performance Panel 以及 Memory Panel。
核心目的就是如何提升 JavaScript 执行速度,当然你可以查看官网学会较好落地的解决方案。
若已经点击完了上述的解决方案,大致核心步骤已经完善了,为了不浪费你的时间,还是不建议你继续阅读下文了。
问题是什么?
项目维护到了一定阶段,突然有用户反馈给开发,你的系统使用期间这么卡呢?其实绝大多数,我们并不清楚用户描述的卡顿到底是什么意思?是系统加载速度慢呢?还是用户体验上就是缺少没有让用户感知网站在运行的提示呢?还是由于网络问题,导致系统页面请求刷新一直在loading,而超时居然还设置超高?
如果公司有前端监控系统,还是蛮方便可以查看部分指标(如首屏加载时间)帮助我们定位对应的问题点。绝大多数的公司可能只会有若干前端,所以想要有这么一整套完善的监控体系还是比较困难的,往往很多时候就需要前端自求多福咯。
核心问题是:我们能否通过现有浏览器工具帮助我们查看站点的性能?
如何解决问题?
前提
首先确保你的环境是干净的,最好和真正使用的用户是「一致」的环境,然后打开一个无痕页面,输入你的站点地址,顺带打开开发者工具。以上步骤的核心逻辑是,减少后续采集数据期间不必要的干扰项。
寻求切入点
然后我们就找「人」请求,给点建议咯。毕竟这么大的站点,需要从那个维度切入现在我们并没有半点思路。然后我们找到了Aduits Panel,选中想要审查的性能评估点,进行跑分。不用多久,就会有关于各个指标的数据报告出来,而且各项指标下方,都会有部分优化的建议,根据建议修复对应的问题,可以帮助你提高各项指标。
性能查看思路
若站点表现出来问题仅仅是性能问题的话,可以切换到 Performance Panel 点击开启记录功能,然后刷新页面,在关闭记录,等待浏览器解析一会,就可以呈现出记录这段时间的整体性能情况如何。
下述数据来源站点是,官方例子。
![image-20190529213132406](https://camo.githubusercontent.com/70600867bcd1e467ed9d1ea63991ce606771669e0b47a261cfc622ff9ca0feed/68747470733a2f2f35316e62696d672e7535312e636f6d2f36393034343930643064653434333236383866333333333366643539316131622e706e67)
如果你不清楚每一个内容区域中的每个面板代表什么,可以查看同事写好的笔记。
我们可以看到很多的红色条状表标记在内容区域的最上方。标记区域就是出现性能瓶颈区域,我们根据标记定位到 Main 分区中每个执行任务,而Main分区主要是可以看到对应时间下主线程的调用栈,也就是火焰图区域。可以选择对应的任务,详情信息区域会展示对应的详情数据。
我们标记火焰图的右上角的红色标记,选中一个进行查看详情数据。
详情信息模块,大致介绍了该任务的执行时间是否是性能瓶颈,同时会标记当前 Call Stack,帮助我们定位具体功能源自脚本位置。
若提示为重排重绘问题,可以调用菜单命令唤起 Rendering Panel 勾选 「Paint flashing」,然后在页面进行查看,若查看大量绿色方块在闪烁,则表明存在重排重绘。此类问题产生多半是CSS样式导致,所以需要查询特别CSS属性是否会触发重排重绘,请查看csstriggers。
当然我们会在详情面板中看到其他三个 tabular 窗口根据不同的维度去分析整个过程的数据。
如果想看选中区间的函数调用情况,可以查看 Call Tree tabular,这里可以看到触发事件的源头造成后续函数调用以及渲染过程的情况。
左侧会有两个时间:Self Time & Total Time。前者表示此项子任务自身消耗多少时长,后者表示此项子任务包含后续子代消耗时长的总计。
该面板看到的数据都是根据调用栈,从上往下的查看对应调用的堆栈,然后查看函数间的调用逻辑,但如果仅仅想看哪项子任务消耗时长最多,建议使用 Bottom-Up tabular,这里首先看到对应的底层任务,可根据时间排序,而且点开同样可以看到该任务的调用形式,和Call Tree调用栈有点相反的感觉。
如果想要查看记录期间任务发生的顺序,可以查看 Event Log tabular,这里可以看到每个任务执行的具体顺序,以及同样任务是否重复执行的情况。
每一个Tabular中都会标明对应函数的位于脚本的位置,可以点击对应链接,工具会帮助你自动跳转到 Source Panel,左侧会出现每行代码执行的时间,你可以查看对应位置是否频繁操作 DOM 定位或是样式导致出现重排重绘问题。
以上都是根据官网提出来的例子,然后结合工具栏的功能进行的如何使用功能讲解的,更多意义上提供了想看什么数据的去哪里找的解决方案。当然可能遇见的问题以及对应的解决方案,官网已经给出,感兴趣可以阅读这里。
当然如果想查看内存泄露等等问题,用到的就是 Memory Panel 可以进行分析网站当下的调用堆栈,以及分析对应时间点下的新内存新增情况,从而进行分析问题。
但官网提供的资料,查阅了两次也不太明白讲述的意思,并且术语那章节看不下去,所以在中途章节出现了术语,理解起来还是比较模糊的,所以就没有继续分析如何使用 Memory Panel 去分析网站情况,感兴趣可以阅读这里。当然你查阅到讲述较为清楚的文章,欢迎你可以留言给我,不胜感激。
The text was updated successfully, but these errors were encountered: