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

声明

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

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

写在前面的话

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

名词解释

气泡图

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

view_resource_count

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

loading time

页面服务器托管网加载时间，需要考虑页面加载的方式：

initial_load 模式下计算公式:

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

route_change 模式下计算公式：

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

思考与探究

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

x:R::view:(AVG(view_resource_count)) { view_resource_count view_path_group
y：R::view:(AVG(loading_time)) { loading_time 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 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

右侧仍旧有比较大的空白，我们将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