如何做好H5性能优化？

Posted 2021-02-15 guernicas

一、背景介绍

智能手机的普及、移动互联网的发展、微信异军突起，都为 H5 的发展提供了良好的环境。当前，H5 已被广泛应用于营销、广告、传播之中。而针对 H5 效率慢、体验差的硬伤，如何做好性能测试并优化其性能就显得尤为重要。

红豆 Live 是微博子公司有信旗下的一款语音直播产品，有各种 H5 页面。我们在做 H5 性能测试时进行了总结，本文将为大家详细介绍 H5 性能测试的关注点、测试工具及常见问题。

 

二、H5 页面的劣势

 

html5 作为一门重要的开发语言，有着显著的优势，其开发速度快、运行效率高、安全性好、可扩展性强、开源自由等，但与手机端原生 APP 相比，H5 页面还具有以下劣势：

1. 不稳定性比较强，页面跳转时更加复杂，运行速度容易受网络影响，很容易造成不流畅，甚至出现卡顿或卡死现象。

2. 由于浏览器的导航本身占用一部分屏幕空间，H5 页面空间比 APP 小，在本身就小的移动设备屏幕中，容易造成信息记忆负担。虽然可以利用滚屏扩大页面，但人脑的短期记忆是不稳定的，用户在滚动屏幕的过程中需要临时记忆的信息越多，他们的表现就会越差。

3. 导航不明显，原有底部导航消失，有效的导航遇到挑战等。

4. 交互动态效果受到限制，影响一些页面场景、逻辑的理解。

5. 功能实现相比 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 开发者工具进行性能测试，该工具有以下优点：

1. 支持移动端 H5 在 PC 端远程调试，能够对具体的移动端设备进行测试；

2. 集成了 Page Speed；

3. 提供 Network 面板，展示瀑布流视图，各类资源清晰罗列，还提供图的缩略图，方便查看图片大小尺寸和冗余或缺失；

4. 提供 TimeLine 面板，展示 CPU、内存、FPS 等性能数据。

下面看下参考 Google 官方网站，重点介绍 Chrome 开发者工具中的 Network 和 Timeline 面板。

 

1.Network 面板

 

Network 面板可以记录页面上的网络请求的详情信息，从发起网页页面请求 Request 后分析 HTTP 请求后得到的各个请求资源信息（包括状态、资源类型、大小、所用时间、Request 和 Response 等），可以根据这个进行网络性能优化。该面板主要包括 5 大块窗格 (Pane)：

1. Controls 控制 Network 的外观和功能。

2. Filters 控制 Requests Table 具体显示哪些内容。

3. Overview 显示获取到资源的时间轴信息。

4. Requests Table 按资源获取的前后顺序显示所有获取到的资源信息，点击资源名可以查看该资源的详细信息。

5. 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)：

1. Controls 录制开关和控制录制过程中需要记录哪些信息。

2. Overview 网页性能的概要信息。

3. Flame Chart CPU 堆栈轨迹的可视化图表 (火焰图)。在图表里面有 1 到 3 条虚竖线。

4. Details 当选择一个指定的事件后，会显示这个事件的更多信息；当没有选择事件时，会显示指定的时间帧信息。Flame Chart 里面的虚竖线含义：蓝色标记 DOMContentLoaded 事件；绿色标记第一次的绘制时间点；红色代表 load 事件。

 

其中第 2 块 Overview 显示了网页性能相关的概要信息，可以通过鼠标或者区域边界上的灰色滑块来拖出一个指定区域范围，Flame Chart 会跟着局部放大显示指定区域内的详情信息。

可以通过键盘上的 W,S 来放大和缩小指定区域，通过 A,D 来向左或向右移动指定区域。这个窗格包含了三个图表：

1. FPS 每秒帧数 (Frames Per Second)。绿色柱状条越高，则每秒帧数越高。在 FPS 图表上方的红色块是标记一个长帧。

2. CPU 标记 CPU 资源的使用情况，这里的面积图标记着消耗 CPU 资源的各类事件。

3. NET 各种颜色的柱状条分别显示一种资源。柱状条越长，代表获取这个资源的时间越长。

 

CPU 面积图中各颜色的含义：蓝色代表 HTML 文件；黄色代表脚本文件；紫色代表样式文件；绿色代表媒体文件；灰色代表其它杂项文件。NET 图表柱状条两种颜色的含义：较亮的部分表示等待时间（当资源被请求时，直到第一个字节被下载的时间）；较暗的部分表示传输时间 (在第一个和最后一个字节被下载之间的时间)。

 

四、常见问题及优化方案

 

1. 在请求的资源中有未使用的图片，造成不必要的资源消耗，应过滤掉，如下图所示。

 

1. 接口请求次数太多。

 

优化方案：合并页面的多个图片资源，减少请求次数。通过 CSS Sprite 将直播间页面的多个资源合并（如截图中标注的图片），再通过 background-image 和 backgorund-position 定位出图中的小区域，那么只需要一个 HTTP 请求就可以获得全部图片。

 

1. 事件处理时间长，每项事件最好控制在 500ms 以内。

 

优化方案：

•   减少重绘和回流

•   缓存 Dom 选择与计算

•   缓存列表.length

•   尽量使用事件代理，避免批量绑定事件

•   尽量使用 ID 选择器

•   使用 touchstart、touchend 代替 click，因快影响速度快。

1. 帧率低。应用的帧率最好一直保持在 30-60fps，如果太低了，应用就会因为丢帧看上去混乱或者抖动。

 

优化方案：要想检查一段时间内的绘制（paint）是另一个挑战。如果想知道为什么某个特定的元素绘制的比较慢，可以把 DOM 树中的部分元素设置成 display:none，将它们从布局 / 内容树中移除，并且设置 visibility:hidden 不让它们绘制。然后你可以用 Timeline 进行录制以便测量，看一下绘制时间，在强制重绘模式中可以观察（实验性的）绘制率。（感谢 Paul 提供的窍门）

1. 点击界面按钮后，二级页面弹出慢。

 

优化方案：可以调整请求的顺序，由拿到数据再弹层，变成弹层的同时取数据，加快弹层展示时间.

 

五、总结

 

目前 H5 的应用非常广泛，如何把控好 H5 的性能是一门重要的课程。从代码设计可以优化 CSS、JS、图片、缓存等。还可以通过 Chrome 开发者工具，监控 H5 的网络请求和加载时间，找到性能消耗较大的根源，优化网络请求数、网络加载时间以及渲染优化。