声明
首先本文数据均来源于对观测云的观测，欢迎和我一起折腾。
如果你也对这部分内容感兴趣，欢迎私信。
写在前面的话
本文不设预期，写到哪里，聊到哪里
名词解释
目录
- 气泡图:
- 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' } BYview_path_group - y：R::
view:(AVG(loading_time)) {loading_time<= '3000000000' } BYview_path_group - size:R::
view:(COUNT(userid)) BYview_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)的平均值入手，可能也是一个数据洞察的点。
如果一个前端开发都能花半个小时写出这些内容来，相信热爱折腾的程序员能鼓捣出更多有意思的东西
