h5页面元素定位_如何定位H5页面存在的性能问题？性能优化工具的使用探索

团队介绍

光大科技有限公司智能云计算部运维服务团队光大e信项目组，致力于为全集团员工提供信息共享、工作协同的一站式移动办公服务平台，助力集团进行战略数字化转型。团队拥有经验丰富的互联网技术研发人员，在自主研发创新项目中不断总结技术经验，不定期进行原创技术文章和实践经验分享，共同去探索如何更好地去进行大型金控集团数字化战略转型IT信息建设。

问题背景

我们通过上一篇文章(如何让你的H5页面首屏秒开？首屏优化方案深度探讨)得知对于一个H5应用，产品功能无疑是很重要的，但性能同样是用户体验中不可或缺的一环。上篇文章中讲述了如何进行页面的性能优化并进行实践，达到了优化的效果。

接下来我们了解一下如何发现自己页面中存在的性能问题。很多时候发现问题比解决问题更加重要，下面就是我们通过分析工具来进行问题排查、问题分析以及解决方案来和大家进行分享。

排查工具

为了更好地排查问题需要先找到最适合的工具，需要找到可以记录和分析页面在运行时所有活动的工具。根据以上两个要求在这里选用谷歌浏览器Chrome DevTools的Performance工具。

先来介绍一下Performance工具的用法，在谷歌浏览器调式模式下，切换到 Performance选项卡，点击刷新图标，过几秒钟出现分析结果如下图1所示内容。

图1

我们可以将这个面板分为三个部分，接下来逐个解释上面各个部分所代表的含义。

1、网页性能总览图

图2

总览图(图2)中四项指标包含FPS(每秒帧数情况)、CPU(CPU占用情况)、NET(网络资源情况)、HEAP(JS占用情况)。

2、各项指标的区块图(图3)，下面介绍几个主要部分

图3

1. Network：表示服务器资源的加载情况。

2. Frames：表示每幅帧的运行情况。

3. Timings：上图中有4条虚线部分，分别表示FP(First Paint)首屏绘制，DCL(DOMContentLoaded)表示HTML文档加载完成事件。FCP(First Contentful Paint)首次内容绘制。L(Onload)页面所有资源加载完成事件。

4. Main：表示主线程，主要负责JavaScript的计算与执行、CSS样式计算、Layout布局计算、将页面元素绘制成位图(Paint)也就是光栅化(Raster)、将位图给合成线程。如下图4。

图4

3、数据统计饼图，主要看一下Summary相关

图5

1. Loading：网络请求和解析HTML的时间。

2. Scripting：JS执行时间。

3. Rendering：重排时间。

4. Painting：重绘时间。

5. System：系统占用时间。

6. Idle：等待时间。

7. Total：合计时间。

通过使用Performance工具分析，我们得知如果想将页面优化到更好需要将以下Timings中几个指标做的更好：

1. FP：首屏绘制。

2. FCP：首次内容绘制。

3. DCL：表示HTML文档加载完成事件。

4. L：页面所有资源加载完成事件。

优化指标

图6

可以通过上图6观察到FP、FCP、DCL、L这几个事件的响应时间。这几个时间决定着我们页面的性能，下面逐一描述各个指标所表示的含义：

1. FP：当用户打开页面链接，发出请求时页面展示的还是之前的内容。当提交数据后，浏览器开始重新渲染页面，这个时候就会触发页面白屏。

2. FCP：当上面部分白屏结束，会触发首次内容绘制。首次内容绘制决定了网页的用户体验。

3. DCL：浏览器完全加载和解析HTML完成，并且将阻塞形成DOM树资源加载解析完毕时，会触发DOMContentLoaded事件。

4. Load：用于检测一个完全加载的页面，页面的HTML、CSS、JS、图片等资源都已经加载完之后才会触发Load事件。

所以接下来要把这几个指标在我们的网页中拿到，进行分析之后再决定优化方向。这里为了拿到正确的数据，需要将谷歌浏览器模式模拟手机4G环境再进行分析。所以需要将以下如图7位置的Network(可在Network标签下建立不同网络环境进行模拟)和CPU设置为手机相同情况，经过测速发现网络稳定环境4G网速大概为2000kb/s，网络非稳定环境4G网速大概为1000kb/s。所以接下来我们的收集的数据都会是在模拟这两种网络情况下收集。

图7

首先看一下某个项目在优化前使用Network在网络1000k/s和2000k/s的情况下对多个页面几个关键数据抓包如下表：

表1

可以看到在优化之前每个页面平均数据为：

1. CSS/JS体积平均为1M左右、数量平均在30个左右。

2. 图片请求体积平均在2M以上、数量在平均35个以上。

3. 1000kb/s网速下DOMContentLoaded和Load时间平均为10s左右。

4. 2000kb/s网速下DOMContentLoaded和Load时间平均为5s左右。

分析瓶颈

通过上面图6的指标和表1进行分析，接下来定位我们页面存在的瓶颈：

1. HTML中DOM节点过多导致HTML解析时间过长。

2. CSS、JS脚本数量过多解析执行时造成阻塞。

3. JS的执行内容过大会形成Long Task造成阻塞。

4. JS引入位置在HEAD标签中也会造成白屏时间加长。

5. 图片的数量过多，体积过大会造成整个页面的LOAD时间加长。

6. CSS/JS数量多体积大下载起来会慢，造成DOMContentLoaded时间加长。

以上6点会造成HTML文档加载阻塞导致白屏时间延长、首次内容绘制更晚出现、资源加载用时过长，造成页面性能较差、打开缓慢、交互性差的问题。

解决方法

1. 在HTML的优化中我们尽量减少DOM结构，减少层级。同时优化阻塞资源的加载顺序，尽早形成DOM树，以缩短首次渲染时间。

2. 将CSS放到头部尽早下载到客户端，尽早形成CSSOM树，然后DOM树加上CSSOM树会形成Render树渲染到页面，完成首屏渲染。

3. 将JS资源使用Async、Defer的方式请求，或者放在最后进行加载，防止JS阻塞页面渲染。

4. 梳理项目中的静态资源，将静态资源整合在一起，减少请求次数，将无用的静态资源删除，或者体积过大的第三方库寻找其他替代方案，减小体积。

5. 通过开启Gzip方式混淆压缩将包体积可以缩小一半左右。

6. 使用Lazy-Load懒加载，首屏时只加载视口内的图片，其它图片实现异步加载。

7. 由于上述问题中提出图片体积过大，需要对图片的体积进行优化，在和后端工程师配合下在不降低太多质量的基础上尽量减小体积，并且在不同的场景下使用不同格式的图片(JPEG/JPG、PNG、SVG、Base64、雪碧图等)。

优化后指标

优化后每个页面平均数据为：

与优化前数据进行对比：

1. CSS/JS体积平均为220k左右、数量平均在16个左右；体积减小了60%左右，请求数量减低50%左右。

2. 图片请求体积平均在30k以下，图片体积减小50%。

3. 1000kb/s网速下DOMContentLoaded和Load时间平均为3s左右，时间减小了60%。

4. 2000kb/s网速下DOMContentLoaded和Load时间平均为2s以内，时间减小了60%。

总结

在这个项目优化过程中，我们通过谷歌浏览器的工具Performance和Network来发现页面中存在的性能问题，然后逐一分析这性能问题存在的原因，在通过上述的方法去一一解决对应的问题，希望大家也可以打开自己的网站看看性能，看看是不是也可以通过Webpack构建系统、静态资源优化、图片的优化、服务器的Gzip配置、浏览器的加载顺序、图片延迟加载这些方向让自己的网站性能得到进一步的提升。

往期回顾

网络中的身份证明--数字签名

制品库初识

初识对象存储

不防火的防火墙究竟在干些什么

扫码关注EBCloud！

作者｜陈晨