可观测性平台-数据洞察（2）-网站性能探究之页面加载时间

声明

首先本文数据均来源于对观测云的观测，欢迎和我一起折腾。

如果你也对这部分内容感兴趣，欢迎私信。

写在前面的话

本文不设预期，写到哪里，聊到哪里

名词解释

目录

• 气泡图:
• view_resource_count:
• loading_time:
• view_path_group
• resource_size

气泡图

气泡图可用于展示三个变量之间的关系，与散点图类似，分为横轴和纵轴，并加入表示大小的变量进行对比。表示因变量随自变量而变化的大致趋势，由此趋势可以选择合适的函数进行经验分布的拟合，进而找到变量之间的函数关系。可用来观察数据的分布和聚合情况。

view_resource_count

每次页面加载时请求的资源个数

loading time

页面加载时间，需要考虑页面加载的方式：

initial_load 模式下计算公式:

① loadEventEnd - navigationStart
② 页面首次无活动时间 - navigationStart

route_change 模式下计算公式：

用户点击时间 - 页面首次无活动时间
页面首次无活动时间：页面超过 100ms 无网络请求或 DOM 突变

思考与探究

按照之前常见思路，是探究页面资源加载数量、页面加载时间的关系。

• x:R::view:(AVG(view_resource_count)) { view_resource_count <= '50' } BY view_path_group
• y：R::view:(AVG(loading_time)) { loading_time <= '3000000000' } BY view_path_group
• size:R::view:(COUNT(userid)) BY view_path_group

使用avg而不是p75/p90解释

单个页面加载的资源的数量基本是固定的

图如下

分析

为什么最左侧的view_resource_count==0？

view_resouce_count==0，意味着使用了缓存，也就是使用了客户端文件。 大家可以看到当使用了缓存时，页面的loading time的下限更靠下，也就是页面加载时间更短。（此处如果用箱线图可能效果更好）,如果我们让view_resouce_count==0,单独来看一下的话：

也就是即便使用本地缓存文件，页面加载时间也存在一定的分布。这里我们暂时不能推测出最大的影响因素。

我们先排除view_resource_count==0的影响，即：x:R::view:(AVG(view_resource_count)) { view_resource_count <= '50' and view_resource_count != '0' } BY view_path_group

这里因为有多款应用，我们只考虑saas版本，即需要把appid限定即可

这样来看x增大y也增大的趋势就比较明显，从图中能明显看出访问人数比较多的页面分别有

• /login/pwd 页面，500ms
• /redirct/login 页面，976ms
• / 页面，1.44s
• /scene/dashboard/list 页面，1.19
• /log/all页面，1.72s

其中log/login/dashboard这几个点之间的面积差别不大，也就是访问者数量差别不大，但页面性能相差确有好几倍。为了更直观的看到x与y的趋势对比，我们将x轴定位到view_resouce_count<30

右侧仍旧有比较大的空白，我们将view_resouce_count调整为80

当然这里我们也能根据已有信息直接查询view_resouce_count的一个平均值 为了更好的观测，我们将view_resouce_count设置为40

从上面的介绍看出，首次加载和页面切换的loading time是不一样的，众所周知的是，loading time对于首次加载更为重要，所以这里只关注首次加载的情况。

由上图看出，明显view_resource_count在0-10之间的数据少了，可以推测是很多页面切换时，加载了少量的资源，常见的页面性能提升大多是把公共资源合并实现1+1《2的加载时间。这里禁不住好奇，如果只是看页面切换的效果，会有哪些情况呢？ 这里将view_loading_type切换为route_change

从这幅图上看，似乎x与y之间，更加呈现线性关系。 同时我们仍旧发现/log /scene/dashboard/list这几个页面依旧存在，也就是说访问人数多的页面是多是切换而来。

resouce_size

resouce_size,资源大小，默认单位：byte

图上展示size大小变化不大，等同于其实页面传输的数据量大小变化不大。

当资源大小变化不大，但是对加载资源的数量相对敏感时，合并资源就成了一个比较合理的优化手段。此时我同时看会话停留时间：

当会话时长变化不大，但是对加载资源的数量相对敏感时，合并资源就成了一个比较合理的优化手段。

问题来了，合并哪些页面呢？一般是从页面停留时间较长但加载时间较长、页面访问频率较高但加载较长来看，刚才已经看过页面停留时间相对不如页面访问人数更加敏感。也就是我们要将访问次数多，但是访问资源也多的页面进行拆分，

也就是说，我们需要将右侧框内的文件，平移到左侧框内 其中包含：

• /log/all
• /dashboard/list
• /tracing/service/table
• /object/admin/host可能将x轴缩小，能看的更加直观一些。

也就是A部分的访问频次较多但加载性能在1.5上下，移动到500-1s之间。即将资源加载数量由10 降低到5。 由于目前没有线性公式，但如果将x轴缩小，查看效果应该更加明显，这里先调整为12，效果如下：

由此看出调整为8可能效果会更好

这里有一个比较有意思的点，view_resouce_count一开始用的是avg，如果使用p99会是什么效果呢

转念一想，loading_time是否也应该取p99

如果只关注平均或者p99，但是对于主要功能页面，访问的人数自然多，我们如果只看加载的总耗时呢？

这几个页面分别是

• /scene
• /log
• /objectadmin/host
• /service/table

但这个无异于其实就是比较sum(loading_time)对吧？同步把view_resouce_count也做sum，看一下效果：

但我们依旧能看出，resouce_count的增多，依旧存在loading time的增多，不过不能给出resouce_count是loading time的直接因果。

推测依旧有其他一个或者多个因素在影响页面加载的性能。我们全部使用p99进行查看

数据洞察改为均值后的3张图：

虽然没有经过相关检验，基本能看出view_resource_count和loading time之间呈现正相关。

如果x轴能够以多个变量的加权值进行计算，比如 sum(resource size)/avg(resource_count)的平均值入手，可能也是一个数据洞察的点。

如果一个前端开发都能花半个小时写出这些内容来，相信热爱折腾的程序员能鼓捣出更多有意思的东西