一、背景介绍
智能手机的普及、移动互联网的发展、微信异军突起，都为 H5 的发展提供了良好的环境。当前，H5 已被广泛应用于营销、广告、传播之中。而针对 H5 效率慢、体验差的硬伤，如何做好性能测试并优化其性能就显得尤为重要。
红豆 Live 是微博子公司有信旗下的一款语音直播产品，有各种 H5 页面。我们在做 H5 性能测试时进行了总结，本文将为大家详细介绍 H5 性能测试的关注点、测试工具及常见问题。
二、H5 页面的劣势
HTML5 作为一门重要的开发语言，有着显著的优势，其开发速度快、运行效率高、安全性好、可扩展性强、开源自由等，但与手机端原生 APP 相比，H5 页面还具有以下劣势：
- 不稳定性比较强，页面跳转时更加复杂，运行速度容易受网络影响，很容易造成不流畅，甚至出现卡顿或卡死现象。
- 由于浏览器的导航本身占用一部分屏幕空间，H5 页面空间比 APP 小，在本身就小的移动设备屏幕中，容易造成信息记忆负担。虽然可以利用滚屏扩大页面，但人脑的短期记忆是不稳定的，用户在滚动屏幕的过程中需要临时记忆的信息越多，他们的表现就会越差。
- 导航不明显，原有底部导航消失，有效的导航遇到挑战等。
- 交互动态效果受到限制，影响一些页面场景、逻辑的理解。
- 功能实现相比 APP 存在差距，用户重复使用难度大，用户粘性差。
二、H5 性能优化技巧1. 代码结构和设计 压缩组件
用户使用 H5 功能过程中，绝大多数时间都花在网络请求上，所以减少使用紧张的网络资源在提高性能上能取得良好的收益。组件压缩就是一种减少网络传输消耗的办法。
从 HTTP 请求返回资源中的 HTML，JS，CSS，XML 等都可以设置压缩。对于已经压缩过的资源（如图片音乐等）不需要再次压缩，收益不高，而且增加 CPU 负担。
JS，CSS 可以常通过去掉空格和回车来压缩，再经过 GZIP 压缩，能达到良好的压缩效果。
压缩方法：在 HTTP 请求中设置所接受到压缩方式，在 Server 端对 Response 资源进行压缩再传给浏览器。一般使用 GZIP 设置 content-Encoding 字段。
设计技巧
CSS 放在顶部、JavaScript 写在底部或异步：DOM 树构建完成后，CSS 要放到 HTML 代码的开头的 head 标签结束前。如果网页是动态生成的，那么在 head 代码完成后可以页面输出，这样浏览器就会更快地解析出来 head 中的内容，开始下载 CSS 文件资源。而 CSS 放在底部则会引起重新绘制，用户会感受到“闪屏”的不好体验。
CSS 使用技巧
- 正确使用 Display 属性，因为 Display 属性会影响页面的渲染
- 避免图片和 iFrame 等空 Src
- 尽量避免重设图片大小
- 避免 CSS 表达式
- 移除空的 CSS 规则
- 不滥用 Web 字体、Float
- 不声明过多的 Font-Size
- 值为 0 时不需要单位
- 标准化各种浏览器的前缀
- 避免让选择符看起来像正则表达式
JS 在下载的时候会引起两个问题：阻止网页内容的展示并组织其他资源下载。下载 JS 时候，并行下载机制失效。并且在 JS 中可能包括 Document.write 等改变页面布局的操作，所以渲染引擎会等待 JS 下载完成再开始渲染。用户侧页面加载时间会因为等待而变得更长。
关于缓存
添加缓存的最终目的是为了减少 HTTP 请求，最终达到提升性能的效果，所有静态资源都要在服务器端设置缓存，并且尽量使用长 Cache 缓存一切可缓存的资源。
2. 网络请求 HTTP 请求个数
有统计证明：一个网页最终到达终端用户有 80% 的时间都是在 JS，CSS，图片，MP3，Flash 等资源的 HTTP 请求。另一方面，HTTP 请求的数量也是有限制的，浏览器对同一个域名有连接数限制，不同浏览器内核、不同版本的请求数不尽相同，大部分的并发请求数是 6 个。通过够控制 HTTP 请求的数量，减少 HTTP 请求时间，达到减少网页加载和呈现的时间，能带来更好的用户体验。
图片格式和大小是否合适
图片格式：H5 中常用的图片格式有 WebP、JPG 和 PNG8。其中 WebP 的图片最小，但在 IOS 或者 Android4.0 以下的系统中可能会有兼容性问题需要解决。JPG 是最常使用的方案，大小适中，解码速度快，兼容性问题也基本不存在，在 H5 的应用中使用起来性价比最高的方案。如果有 PNG24|32 图片，尽量将其转换层 PNG8，能极大减少图片大小。BMP 是未压缩的图片格式，应该避免使用。
图片尺寸：当前移动设备中常用个尺寸规格为 480×800、600×1024、720×1280，800×1280 等，保证提供的原图能够被呈现，避免在代码中调整图片大小。
避免非 200 返回值
每一个 HTTP 请求都有一个相对于的返回状态标志当次请求是否如期完成，如：
1：请求收到，这些状态代码表示临时的响应。
2：操作成功，这类状态代码表明服务器成功地接受了客户端请求。
3：重定向，客户端浏览器必须采取更多操作来实现请求。
4：客户端错误，发生错误，客户端似乎有问题。
5：服务器错误，服务器由于遇到错误而不能完成该请求。
所以，如果有 HTTP 请求返回为非 200 的状态码，我们认为这一次请求时无意义的，占用了稀缺的网络资源，所应该避免非 200 的返回状态码。
三、性能测试工具
推荐采用 Chrome 开发者工具进行性能测试，该工具有以下优点：
- 支持移动端 H5 在 PC 端远程调试，能够对具体的移动端设备进行测试；
- 集成了 Page Speed；
- 提供 Network 面板，展示瀑布流视图，各类资源清晰罗列，还提供图的缩略图，方便查看图片大小尺寸和冗余或缺失；
- 提供 TimeLine 面板，展示 CPU、内存、FPS 等性能数据。
下面看下参考 Google 官方网站，重点介绍 Chrome 开发者工具中的 Network 和 Timeline 面板。
1.Network 面板
Network 面板可以记录页面上的网络请求的详情信息，从发起网页页面请求 Request 后分析 HTTP 请求后得到的各个请求资源信息（包括状态、资源类型、大小、所用时间、Request 和 Response 等），可以根据这个进行网络性能优化。该面板主要包括 5 大块窗格 (Pane)：
- Controls 控制 Network 的外观和功能。
- Filters 控制 Requests Table 具体显示哪些内容。
- Overview 显示获取到资源的时间轴信息。
- Requests Table 按资源获取的前后顺序显示所有获取到的资源信息，点击资源名可以查看该资源的详细信息。
- Summary 显示总的请求数、数据传输量、加载时间信息。
其中 Requests Table 显示如下信息列：
• Name 资源名称，点击名称可以查看资源的详情情况，包括 Headers、Preview、Response、Cookies、Timing。
• Status HTTP 状态码。
• Type 请求的资源 MIME 类型。
• Initiator 标记请求是由哪个对象或进程发起的（请求源）。• Parser： 请求由 Chrome 的 HTML 解析器时发起的。
• Redirect：请求是由 HTTP 页面重定向发起的。
• Script：请求是由 Script 脚本发起的。
• Other：请求是由其他进程发起的，比如用户点击一个链接跳转到另一个页面或者在地址栏输入 URL 地址。
• Size 从服务器下载的文件和请求的资源大小。如果是从缓存中取得的资源则该列会显示 (from cache)
• Time 请求或下载的时间，从发起 Request 到获取到 Response 所用的总时间。
• Timeline 显示所有网络请求的可视化瀑布流 (时间状态轴)，点击时间轴，可以查看该请求的详细信息，点击列头则可以根据指定的字段可以排序。
2.Timeline 面板
在 Chrome 中点击开发者工具，打开 Timeline 面板，这个工具真的很强大，Timeline 工具栏提供了对于在装载你的 Web 应用的过程中，时间花费情况的概览，这些应用包括处理 DOM 事件, 页面布局渲染或者向屏幕绘制元素。Timeline 可以通过事件，框架，和实时内存用量 3 个方面的数据来监测网页，通过这些数据，我们可以方便的找出页面中存在问题的地方。该面板主要包括 4 大块窗格 (Pane)：
- Controls 录制开关和控制录制过程中需要记录哪些信息。
- Overview 网页性能的概要信息。
- Flame Chart CPU 堆栈轨迹的可视化图表 (火焰图)。在图表里面有 1 到 3 条虚竖线。
- Details 当选择一个指定的事件后，会显示这个事件的更多信息；当没有选择事件时，会显示指定的时间帧信息。Flame Chart 里面的虚竖线含义：蓝色标记 DOMContentLoaded 事件；绿色标记第一次的绘制时间点；红色代表 load 事件。
其中第 2 块 Overview 显示了网页性能相关的概要信息，可以通过鼠标或者区域边界上的灰色滑块来拖出一个指定区域范围，Flame Chart 会跟着局部放大显示指定区域内的详情信息。
可以通过键盘上的 W,S 来放大和缩小指定区域，通过 A,D 来向左或向右移动指定区域。这个窗格包含了三个图表：
- FPS 每秒帧数 (Frames Per Second)。绿色柱状条越高，则每秒帧数越高。在 FPS 图表上方的红色块是标记一个长帧。
- CPU 标记 CPU 资源的使用情况，这里的面积图标记着消耗 CPU 资源的各类事件。
- NET 各种颜色的柱状条分别显示一种资源。柱状条越长，代表获取这个资源的时间越长。
CPU 面积图中各颜色的含义：蓝色代表 HTML 文件；黄色代表脚本文件；紫色代表样式文件；绿色代表媒体文件；灰色代表其它杂项文件。NET 图表柱状条两种颜色的含义：较亮的部分表示等待时间（当资源被请求时，直到第一个字节被下载的时间）；较暗的部分表示传输时间 (在第一个和最后一个字节被下载之间的时间)。
四、常见问题及优化方案
- 在请求的资源中有未使用的图片，造成不必要的资源消耗，应过滤掉，如下图所示。
- 接口请求次数太多。
优化方案：合并页面的多个图片资源，减少请求次数。通过 CSS Sprite 将直播间页面的多个资源合并（如截图中标注的图片），再通过 background-image 和 backgorund-position 定位出图中的小区域，那么只需要一个 HTTP 请求就可以获得全部图片。
- 事件处理时间长，每项事件最好控制在 500ms 以内。
优化方案：
• 减少重绘和回流
• 缓存 Dom 选择与计算
• 缓存列表.length
• 尽量使用事件代理，避免批量绑定事件
• 尽量使用 ID 选择器
• 使用 touchstart、touchend 代替 click，因快影响速度快。
- 帧率低。应用的帧率最好一直保持在 30-60fps，如果太低了，应用就会因为丢帧看上去混乱或者抖动。
优化方案：要想检查一段时间内的绘制（paint）是另一个挑战。如果想知道为什么某个特定的元素绘制的比较慢，可以把 DOM 树中的部分元素设置成 display:none，将它们从布局 / 内容树中移除，并且设置 visibility:hidden 不让它们绘制。然后你可以用 Timeline 进行录制以便测量，看一下绘制时间，在强制重绘模式中可以观察（实验性的）绘制率。（感谢 Paul 提供的窍门）
- 点击界面按钮后，二级页面弹出慢。
优化方案：可以调整请求的顺序，由拿到数据再弹层，变成弹层的同时取数据，加快弹层展示时间.
五、总结
目前 H5 的应用非常广泛，如何把控好 H5 的性能是一门重要的课程。从代码设计可以优化 CSS、JS、图片、缓存等。还可以通过 Chrome 开发者工具，监控 H5 的网络请求和加载时间，找到性能消耗较大的根源，优化网络请求数、网络加载时间以及渲染优化。
原文地址：https://www.cnblogs.com/Guernicas/p/10662189.html