
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
在优化web页面打开速度时,我们一般会被问到2个问题 1. 慢在哪里? 2. 为什么慢?
某天监控系统突然给我们告警页面加载时间超长,或者某个客户,同事反馈我们的页面打开很慢,由于数据指标不够精细或问题描述笼统,其实很难迅速定位到具体哪里出了问题,是dns解析? 网络不好? 还是服务器出了问题?接口抖动?又或是运营又上传了一张超大的图片?还是我们之前发版导致的?
看上去我们需要更多的数据帮助来分析问题,在这里请注意,我们很容易会掉进 “数据陷进”, 花了很多的时间成本来收集数据,对面海量和多元的数据却又无从下手,所以需要事先想清楚我们究竟需要哪些数据,从哪些维度来进行分析
web页面性能统计有很多种标准,我们主要采用端到端耗时,主要原因是覆盖的范围更广,从网络,后端,前端都能涵盖,也更接近用户的真实体验。
我总结了2种维度来阐述端到端页面展示
一. 时间轴
window.performance.timing:
navigationStart -> responseStart -> domInteractive -> domComplete -> loadEventEnd
window.chrome.loadTimes:
startLoadTime -> firstPaintTime -> finishDocumentLoadTime -> finishLoadTime
从时间轴上可以比较直观的看出页面加载的时序,进而可以提炼出几个关键指标: 秒开率, 首屏时间,可交互时间,完全加载时间,利用这些指标可以更好的分析优化的侧重点和方向。
二. 耗时分类
初始化耗时 -- 宿主环境,容器
app webview init 耗时
网络耗时 -- dns,网络环境,机房分布
主文档 DNS Lookup + Initial connection + SSL
后端耗时 -- 接口,路由,应用,读取数据
主文档 TTFB
下载耗时 -- 网络,缓存,页面资源大小
主文档 Content Download + 所有资源下载时间
渲染耗时 -- 代码,加载时序
代码执行 + 渲染
每一项对应不同的原因,对”慢“ 的原因从数据层做了细分,让我们更容易找到问题的根源,对症下药
结合这2种指标,可以配合来快速精确的定位和解决问题,例如我对首屏时间监控,发现指标超标后对应查找分类耗时,如下载耗时过长,就应该去优化缓存,页面大小,网络等
以上的数据可以解决第一个问题,慢在哪里?要解决第二个问题,为什么慢?为此我们收集了更多的数据
仔细分析之前的指标,可以看出每个指标都会有一些因素影响,大致分为两类
宿主环境 -- app容器,app版本,机型,操作系统
网络环境 -- 网速, 运营商,地域,机房分布
用户信息 -- 缓存, 操作路径
这些因素和之前的数据维度组合,能够交叉形成非常多的数据组合,虽然我们有了更多的数据,但要“小心”分析和使用这些数据,一是分析这些数据会非常耗时,二是经过这些数据得出的结论不一定科学严谨,三是有些问题有实锤证明,也不一定能够得到解决。
举个例子:我们经过数据分析,得出某个页面95线慢的正关联信息有1. 页面请求量越多,95线越慢 2. 在经济较弱省市,请求耗时大大高于经济强的省市 3. 每个时段都会有一些特别慢的请求,又没有统一的特征
经过更多的数据比对我们发现,某些结论并不一定是事实,有的请求多的页面并没有比请求少的页面耗时更长,或者有些问题我们无法解决,比如我们无法改变地域的基础网络状况,又或者对一些数据需要投入更多的时间成本来进行分析
但这些分析并不是没有好处的,它有可能会帮你发现一些共性问题并可以得到改善,只是需要更谨慎一些
数据分析
获取到部分耗时分类数据进行一下分析,以某网站首页为例,
可以分解成几个阶段:
网络耗时 = dns查询时间 + tcp连接时间 = 212ms
后端耗时 = 首字节时间 - 网络耗时 = 310ms
主文档耗时 = 开始解析HTML时间 - 后端耗时分位 = 63ms
资源下载耗时 = 资源下载时间 - 主文档耗时分位 = 1175ms
渲染&布局耗时 = onload耗时 - 资源下载耗时分位 = 232ms
可以分解成几个阶段:
网络耗时 = dns查询时间 + tcp连接时间 = 295ms
后端耗时 = 首字节时间 - 网络耗时 = 665ms
主文档耗时 = 开始解析HTML时间 - 后端耗时分位 = 60ms
资源下载耗时 = 资源下载时间 - 主文档耗时分位 = 946ms
渲染&布局耗时 = onload耗时 - 资源下载耗时分位 = 477ms
相同技术栈的页面数据分析和对比,可以得出结论
耗时主要在资源下载,后端耗时和渲染布局上(可以在这3方面做优化测试)