声明

首先本文数据均来源于对观测云的观测。

写在前面的话

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

名词解释

目录

• 气泡图:

• 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)的平均值入手，可能也是一个数据洞察的点。

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