Open huandie2012 opened 7 months ago
去年9月在做会员升级灰度验证阶段发现:会员中心页面加载速度缓慢,大概在3s~5s,用户体验很不好。
在浏览器控制台初步分析发现: 1、有2个接口响应时间过长,大概在4s左右; 2、接口返回的图片过大; 3、有2个接口串行调用,可以调整为并行调用的方式;
接口的问题,前端侧无法进行优化,我们只能从前端的角度去对页面进行性能方面的优化,可以通过一些性能指标和数据展示以及异常分析对页面进行全方位的性能分析,然后基于根源问题进行性能优化,事半功倍。
由于我们的H5页面是嵌入在APP中访问的,所以可以通过APP相关的WebView性能监控指标中查看H5页面的相关性能数据;
首包时间展示了客户端收到服务端第一个数据包的时间,它可以体现服务器的整体性能,比如有的使用的CDN服务,可以反映CDN服务节点的性能; HTML下载用时是指浏览器下载完整的HTML文档内容所需要的时间; DOM建立用时是指浏览器建立DOM的用时,即浏览器在加载网页时将HTML文档转换为DOM所需时间; 资源加载时间监测各种资源(如图像、脚本、样式表)的加载时间,以确保它们不会拖慢页面加载,资源加载时间过长,页面渲染越延迟; 其中HTML下载用时和资源加载时间均在0.5s以下,时间在可接受范围,但在个别峰点,DOM建立用时最高达3.5s,这个性能指标是有优化空间的。 那接下来我们基于DOM建立用时这个性能指标着重分析下,那影响这个指标的因素大概有资源缺乏异步加载和延迟加载,页面包含大型的脚本文件、阻塞资源这个三个方面: 其中我们通过抓包查看得知,该页面的脚本文件均在200kb以下,不包含大型的脚本文件; 其次我们确定下页面中是否存在阻塞资源问题,这里接着抓包中的相关性能分析工具进行检查和分析,切换到NetWork中刷新页面查看资源的加载状态,没有处于pending中的资源,那说明页面中不存在阻塞资源的问题; 那只剩下最后一个因素,在会员前端项目的构建配置中有添加按需加载,需要给head标签中加载的JS文件添加async或defer属性来异步加载相关JS文件,同时和PO沟通按需加载部分资源。
首包时间
HTML下载用时
DOM建立用时
资源加载时间
资源缺乏异步加载和延迟加载,页面包含大型的脚本文件、阻塞资源
平均页面错误次数=特性时间范围内页面错误总数/页面访问总数;(其中特性时间范围内页面错误总数:所关注的时间段内发生的所有页面错误,包括JS错误、HTTP错误、资源加载错误等的总数;页面访问总数:在相同时间范围内用户访问页面的总次数) 平均吞吐率=特性时间段内成功完成的工作单位量/总时间;(其中特性时间段内成功完成的工作单位量:包含完成的HTTP请求、传输的数据量、处理的事务等,总时间:测量的时间段,通常以秒为单位) 会员中心的页面平均页面错误次数均为0,说明当前页面是相对稳定和可靠的,表现出了较好的用户满意度和用户留存率。 平均吞吐率更多的是衡量Web服务器的一个指标,例如:一个Web服务器在一分钟内成功处理了600个HTTP请求,那么平均吞吐率是:600/60 = 10RPS(每秒处理10个请求)。
平均页面错误次数
特性时间范围内页面错误总数
页面访问总数
平均吞吐率
特性时间段内成功完成的工作单位量
JS错误率=(JS错误量/JS请求或执行的总次数)*100%; 它的数据表明了在JS执行过程中出现问题的频率,可以根据收集过来的数据统计,看某一段时间内出现的错误率是多少。
这两项数据展示了产品所覆盖的地区中的用户某一段时间内共访问了多少次,访问时间比较集中在多伤时间,从而判断一下优良等级。
慢请求:默认网络请求响应时间超过1s就是慢请求; 慢速比=慢页面次数/总页面访问次数;(接口中:慢速比=慢请求次数/总请求次数);也就是说,在一分钟内,页面被访问了1000次,其中有100次页面响应时间超过1s,那么慢速比就是:(100/1000)*100%=10%; 例如:5天内,某页面的慢速比有3个峰值,峰值最高的慢速比为2.78%,其他两个均为1.5%,其他时间点慢速比均为0,整体来说慢速比处于可接受范围,页面次数和慢请求次数均为0,从数据上来看,页面的性能处于良好状态。
最后要看一下监控统计的整体数据,例如:5天内页面在APP中被访问的整体数据显示得出,整体性能均值为0.03,由于页面有2个接口响应时间比较久,所以页面的白屏时间均值为1.12s,将接口问题反馈给后端去做相应优化。
基于以上对于性能数据的分析,可以参考以下优化方案: 首次进入页面后将复用且不常更新的接口数据存入本地缓存中; 第二次进入页面首先读取本地缓存数据等接口返回后更新本地缓存,同时页面数据也更新; 由于接口返回之前页面数据会有延迟性,所以增加半透明的loading的icon,让用户先浏览,页面可以滚动,但不能交互; 首页增加动画效果,未避免完全消失,淡入淡出有重叠时长,总时长由0.5s改为0.3s; 给head标签总加载的JS文件添加async或defer属性来异步加载相关JS文件; 非逻辑关联的接口采用并行调用的方式;
最后再补充下其他的一些重要的性能指标: 页面加载时间 用户从点击链接到页面完全加载所需时间; 首次内容渲染时间(首屏时间FCP) 浏览器首次绘制页面内容的时间,用户在这时会看到页面的第一部分; 可交互时间(TTI) 标志着页面已经加载并且可以响应用户的输入,较低的TTI意味着更快的用户体验; 页面加载时间过长 通常与网络延迟、资源过多或资源未经优化有关; 可交互时间延迟 由于大量JS代码、未优化的代码或性能渲染M操作有关; 不必要的重定向 会增加加载时间,降低性能; 不充分的缓存策略 缺乏适当的资源缓存策略可能导致重复下载相同的资源,增加加载时间; 不适当的图片格式和大小 使用不适当的图片格式或未经优化的高分辨率图片可能会导致资源加载延迟; 浏览器兼容问题 不同浏览器对某些功能的支持不同,可能会导致性能问题或功能失效; 百分位分位值 假设有100个数,按从小到大排列,排在第10个的即为10分位值,排在第50个即为50分位值,也叫中位值,排在90位的叫90分位值,我们将性能数据进行收集并排序统计,然后查询排位后的性能指标; 页面健康度 主要分为4个:优秀、良好、可容忍、不可容忍,慢页面占比主要看当前页面的可容忍与不可容忍的占比,页面相对较慢的比例; 慢页面占比 该页面中性能评估为可容忍与不可容忍PV总和/该页面总PV数。
页面加载时间
首次内容渲染时间(首屏时间FCP)
可交互时间(TTI)
页面加载时间过长
可交互时间延迟
不必要的重定向
不充分的缓存策略
不适当的图片格式和大小
浏览器兼容问题
百分位分位值
页面健康度
慢页面占比
背景
去年9月在做会员升级灰度验证阶段发现:会员中心页面加载速度缓慢,大概在3s~5s,用户体验很不好。
问题分析
在浏览器控制台初步分析发现: 1、有2个接口响应时间过长,大概在4s左右; 2、接口返回的图片过大; 3、有2个接口串行调用,可以调整为并行调用的方式;
解决方案
接口的问题,前端侧无法进行优化,我们只能从前端的角度去对页面进行性能方面的优化,可以通过一些性能指标和数据展示以及异常分析对页面进行全方位的性能分析,然后基于根源问题进行性能优化,事半功倍。
1、页面分析
由于我们的H5页面是嵌入在APP中访问的,所以可以通过APP相关的WebView性能监控指标中查看H5页面的相关性能数据;
a、整体性能分析
首包时间
展示了客户端收到服务端第一个数据包的时间,它可以体现服务器的整体性能,比如有的使用的CDN服务,可以反映CDN服务节点的性能;HTML下载用时
是指浏览器下载完整的HTML文档内容所需要的时间;DOM建立用时
是指浏览器建立DOM的用时,即浏览器在加载网页时将HTML文档转换为DOM所需时间;资源加载时间
监测各种资源(如图像、脚本、样式表)的加载时间,以确保它们不会拖慢页面加载,资源加载时间过长,页面渲染越延迟; 其中HTML下载用时和资源加载时间均在0.5s以下,时间在可接受范围,但在个别峰点,DOM建立用时最高达3.5s,这个性能指标是有优化空间的。 那接下来我们基于DOM建立用时
这个性能指标着重分析下,那影响这个指标的因素大概有资源缺乏异步加载和延迟加载,页面包含大型的脚本文件、阻塞资源
这个三个方面: 其中我们通过抓包查看得知,该页面的脚本文件均在200kb以下,不包含大型的脚本文件; 其次我们确定下页面中是否存在阻塞资源问题,这里接着抓包中的相关性能分析工具进行检查和分析,切换到NetWork中刷新页面查看资源的加载状态,没有处于pending中的资源,那说明页面中不存在阻塞资源的问题; 那只剩下最后一个因素,在会员前端项目的构建配置中有添加按需加载,需要给head标签中加载的JS文件添加async或defer属性来异步加载相关JS文件,同时和PO沟通按需加载部分资源。b、平均页面错误次数和平均吞吐率
平均页面错误次数
=特性时间范围内页面错误总数/页面访问总数;(其中特性时间范围内页面错误总数
:所关注的时间段内发生的所有页面错误,包括JS错误、HTTP错误、资源加载错误等的总数;页面访问总数
:在相同时间范围内用户访问页面的总次数)平均吞吐率
=特性时间段内成功完成的工作单位量/总时间;(其中特性时间段内成功完成的工作单位量
:包含完成的HTTP请求、传输的数据量、处理的事务等,总时间:测量的时间段,通常以秒为单位) 会员中心的页面平均页面错误次数均为0,说明当前页面是相对稳定和可靠的,表现出了较好的用户满意度和用户留存率。 平均吞吐率更多的是衡量Web服务器的一个指标,例如:一个Web服务器在一分钟内成功处理了600个HTTP请求,那么平均吞吐率是:600/60 = 10RPS(每秒处理10个请求)。c、JS错误率
JS错误率=(JS错误量/JS请求或执行的总次数)*100%; 它的数据表明了在JS执行过程中出现问题的频率,可以根据收集过来的数据统计,看某一段时间内出现的错误率是多少。
d、访问体验分布&地区分布
这两项数据展示了产品所覆盖的地区中的用户某一段时间内共访问了多少次,访问时间比较集中在多伤时间,从而判断一下优良等级。
e、健康域名分布及慢速比
慢请求:默认网络请求响应时间超过1s就是慢请求; 慢速比=慢页面次数/总页面访问次数;(接口中:慢速比=慢请求次数/总请求次数);也就是说,在一分钟内,页面被访问了1000次,其中有100次页面响应时间超过1s,那么慢速比就是:(100/1000)*100%=10%; 例如:5天内,某页面的慢速比有3个峰值,峰值最高的慢速比为2.78%,其他两个均为1.5%,其他时间点慢速比均为0,整体来说慢速比处于可接受范围,页面次数和慢请求次数均为0,从数据上来看,页面的性能处于良好状态。
f、整体数据
最后要看一下监控统计的整体数据,例如:5天内页面在APP中被访问的整体数据显示得出,整体性能均值为0.03,由于页面有2个接口响应时间比较久,所以页面的白屏时间均值为1.12s,将接口问题反馈给后端去做相应优化。
2、优化方案
基于以上对于性能数据的分析,可以参考以下优化方案: 首次进入页面后将复用且不常更新的接口数据存入本地缓存中; 第二次进入页面首先读取本地缓存数据等接口返回后更新本地缓存,同时页面数据也更新; 由于接口返回之前页面数据会有延迟性,所以增加半透明的loading的icon,让用户先浏览,页面可以滚动,但不能交互; 首页增加动画效果,未避免完全消失,淡入淡出有重叠时长,总时长由0.5s改为0.3s; 给head标签总加载的JS文件添加async或defer属性来异步加载相关JS文件; 非逻辑关联的接口采用并行调用的方式;
总结
最后再补充下其他的一些重要的性能指标:
页面加载时间
用户从点击链接到页面完全加载所需时间;首次内容渲染时间(首屏时间FCP)
浏览器首次绘制页面内容的时间,用户在这时会看到页面的第一部分;可交互时间(TTI)
标志着页面已经加载并且可以响应用户的输入,较低的TTI意味着更快的用户体验;页面加载时间过长
通常与网络延迟、资源过多或资源未经优化有关;可交互时间延迟
由于大量JS代码、未优化的代码或性能渲染M操作有关;不必要的重定向
会增加加载时间,降低性能;不充分的缓存策略
缺乏适当的资源缓存策略可能导致重复下载相同的资源,增加加载时间;不适当的图片格式和大小
使用不适当的图片格式或未经优化的高分辨率图片可能会导致资源加载延迟;浏览器兼容问题
不同浏览器对某些功能的支持不同,可能会导致性能问题或功能失效;百分位分位值
假设有100个数,按从小到大排列,排在第10个的即为10分位值,排在第50个即为50分位值,也叫中位值,排在90位的叫90分位值,我们将性能数据进行收集并排序统计,然后查询排位后的性能指标;页面健康度
主要分为4个:优秀、良好、可容忍、不可容忍,慢页面占比主要看当前页面的可容忍与不可容忍的占比,页面相对较慢的比例;慢页面占比
该页面中性能评估为可容忍与不可容忍PV总和/该页面总PV数。