测试关注指标记录点

比眉伴天荒 2023-08-17 17:30 136阅读 0赞

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

*  网络
    
     *  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[内容分发网络][Link 1]（Content Delivery Network）将源站内容发布到最接近用户的“边缘”节点，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器能力带来的访问延迟高问题。
     *  问题：哪些内容才会用到cdn的分发？

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

转载于:https://www.cnblogs.com/syw20170419/p/11514710.html

[Smush.it]: http://Smush.it
[Link 1]: https://cloud.tencent.com/product/cdn?from=10680