测试关注指标记录点

”加载速度“ 的主要关注点如下：

• 网络
  
  
  
  • WIFI/4G/3G/2G
  
  
  
  


• 启动
  
  
  
  • 白屏时间
  
  
  • 首屏时间
  
  
  • 可交互时间
  
  
  
  


• 缓存
  
  
  
  • 有缓存
  
  
  • 无缓存
  
  
  
  


• 缩短响应时间
  
  
  
  • CDN部署
  
  
  • 合理分域名
  
  
  
  


• HTTP请求数
  
  
  
  • 资源合并
  
  
  
  


• HTTP状态
  
  
  
  • 失败资源处理
  
  
  
  


• 单个请求优化
  
  
  
  • 缓存机制
  
  
  • 压缩内容
  
  
  
  


• 资源合理组合
  
  
  
  • 预加载
  
  
  • 分页加载
  
  
  • CSS放顶部
  
  
  • js放底部
  
  
  
  

测试关注指标：

• HTTP请求个数【是否有多余的请求，示例：后端可做的请求放在了前段去实现（注：公共的加载项除外）】
  
  
  
  • 一个网页最终到达终端用户有80%的时间都是在js，CSS，图片，mp3，flash等资源的http请求。另一方面，http请求的数量也是有限制的，浏览器对同一个域名有连接数限制，不同浏览器内核、不同版本的请求数不尽相同，大部分的并发请求数是6个。
  
  
  • 问题：什么样的请求应该由后端去做？什么样的请求必须由前端来实现？
  
  
  
  


• 组件是否压缩
  
  
  
  • 压缩方法：在http请求中设置所接受到压缩方式，在Server端对Response资源进行压缩再传给浏览器。一般使用GZIP设置content-Encoding字段。Transfer-Encoding: chunked
  
  
  • 压缩对象：从http请求返回资源中的html，js，CSS，xml等都可以设置压缩，值得注意的是我们不需要对图片音乐等资源设置压缩，因为这些资源本身已经压缩过了，再次压缩收益并不高，而且增加CPU负担。
  
  
  • 问题：什么情况下才会做压缩？哪些文件支持压缩？压缩的利弊？
  
  
  
  


• 图片格式和大小是否合适
  
  
  
  • 图片格式：显示效果较好的图片格式中，有webp、jpg和png24/32这几种常见的图片格式，webp的图片最小
  
  
  • 图片尺寸：获取图片尺寸时候应该考虑图片具体的展示场景，如当前移动设备中常用个尺寸规格为480×800、600×1024、720×1280，800×1280等，从原图来保证图片能够被呈现，而不是通过代码对图片放大或缩小。
  
  
  • 图片压缩：对于jpg，png格式图片来说本身就已经经过了压缩，这对于稀缺的带宽资源是不够的，我们还需要更加优化的压缩算法，通过一系列的图片压缩工具如TinyPNG, Smush.it可以得到更好的压缩且图片质量不变。
  
  
  • 问题：jpeg的图片格式跟jpg图片格式的区别？图片的尺寸对加载性能上的影响大不？图片的大小一般建议不超过多少KB？
  
  
  
  


• css放在顶部（CSS和js代码是否有做分离）：
  
  
  
  • 在浏览器渲染过程中谈到，dom树构建完成后。CSS要放到html代码的开头的head标签结束前。如果网页是动态生成的，那么在head代码完成后可以页面输出，这样浏览器就会更快地解析出来head中的内容，开始下载CSS文件资源。而CSS放在底部则会引起重新绘制，用户侧感受到“闪屏”的不好体验。
  
  
  • 问题：CSS和js代码什么情况下适合做分离？什么情况下是不可以做分离的？
  
  
  
  


• js放在底部
  
  
  
  • JS在下载的时候会引起两个问题：阻止网页内容的展示并阻止其他资源下载。在“减少http数量”部分中，我们谈到各种资源的下载是并行的，根据不同域名不同浏览器内核并行数量有所不同，所以下载js时候，并行下载机制失效。并且在js中可能包括document.write等改变页面布局的操作，所以渲染引擎会等待js下载完成再开始渲染。所以用户侧页面加载时间会因为等待而变得更长。
  
  
  
  


• js&css压缩
  
  
  
  • 从js&CSS文件的源头进行压缩，缩小了http传输过程数据大小。
  
  
  
  


• 是否添加缓存
  
  
  
  • 缓存的优点：缓存接口数据，在一些数据新旧敏感性不高的场景下很有用，在非首次加载数据时候优先使用上次请求来的缓存数据，可以让页面更加快速地渲染出来，而不用等待一个新的HTTP请求结束之后再渲染。 
  
  
  • 两种方式设置缓存，测试时注意常用资源是否请求资源时否设置缓存Cache-Control：
    
    
    
    • "no-cache"指示请求或响应消息不能缓存（HTTP/1.0用Pragma的no-cache替换）
    
    
    • "no-store"用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。根据缓存超时Expires 表示存在时间，允许客户端在这个时间之前不去检查（发请求），等同max-age的效果。
    
    
    • 问题：什么样的请求类型才会做缓存？哪些文件适合做缓存？一般的缓存方式有哪些？
    
    
    
    
  
  
  
  


• 避免非200返回值
  
  
  
  • 如果有http请求返回为非200的状态码，我们认为这一次请求时无意义的，占用了稀缺的网络资源，所应该避免非200的返回状态码。
  
  
  
  


• 使用CDN
  
  
  
  • CDN内容分发网络（Content Delivery Network）将源站内容发布到最接近用户的“边缘”节点，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器能力带来的访问延迟高问题。
  
  

  • 问题：哪些内容才会用到cdn的分发？

  
  
  
  

• 页面的加载方式？（是否有懒加载、预加载）


• 时间
  
  
  
  • 白屏时间：用户首次看到网页有内容的时间，即第一次渲染流程完成时间。
  
  
  • 首屏时间：是指用户看到第一屏，即整个网页顶部大小为当前窗口的区域，显示完整的时间。
  
  
  • 首资源下载时间：从开始下载到第一个资源均下载完成的时间，不包括页面绘制时间。
  
  
  • 总资源下载时间：从开始下载到所有资源均下载完成的时间，不包括页面绘制时间。
  
  
  • 用户可操作时间：从页面开始加载到用户操作可响应的时间。