最近正好在做web前端的性能测试，这次就来聊聊关于这个的测试思路~ 。

首先从用户的思维去思考，关于web前端性能，用户最看重的是什么...... 。

其实就是下面三个点:

　　1. 加载性能（即页面加载时间+资源加载时间） 。

　　2. 渲染性能（即浏览器绘制出包含实际内容（如文本、图片等）的时间） 。

　　3. 交互性能（即用户可以进行点击、输入等操作的时间和延迟时间） 。

这三点组成了用户的等待时间，也就是我们俗称的258秒~ 。

那基于这三点，我开始设计测试方案，最后还是选择了jmeter+lighthouse的性能测试模式，原因也很简单，我太熟悉jmeter了（不是），其实原因大致是下列2点:

　　1. Jmeter有加载性能和交互性能方面的优势:

　　　　(1) 精准模拟资源请求: JMeter 可以精确模拟浏览器向服务器发起的各类资源请求，包括 HTML 文档、图片、脚本、样式表等，通过合理配置完全复现用户打开页面时浏览器的加载行为.

　　　　　例如：针对一个包含大量图片和脚本文件的网页，JMeter 可以按照实际页面中资源的加载顺序依次发送请求，精准测量每个资源的加载时间；又或者根据get URL 模拟用户触发查看页面的行为来查看响应时间.

　　　　(2) 精准模拟真实用户交互：Jmeter可以完美模拟用户的操作序列。从用户登录、点击菜单、填写表单到提交数据等一系列操作，真实还原用户操作流程.

　　　　(3) 基于多场景并发下的加载评估: 众所周知，jmeter最出名的其实是它作为压测工具的使用，利用其灵活的线程组设置，JMeter 能够模拟不同并发用户数场景下页面的加载情况.

　　　　　例如：在低并发时，可观察页面在日常流量下基础资源的加载是否流畅；中并发模拟正常业务高峰，查看资源加载的并发处理能力，查看是否因为并发请求过多导致资源排队等待加载时间延长；高并发考验系统极限，确保在极端流量下页面仍能有基本的加载呈现，不至于完全崩溃.

　　

　　2. Lighthouse在渲染性能方面的优势:

　　　　(1) 实时渲染追踪：Lighthouse 在测试过程中可以紧密跟踪页面渲染进程，精确捕捉首次绘制（FP）的确切时间点，以及后续内容逐步渲染的节奏和时间，并且可以准确评分.

　　　　(2) 资源优化：对于页面中的资源（如图片、字体等），Lighthouse 会提供资源加载优化的建议。除了前面提到的图片压缩，还会建议合理设置缓存策略，减少重复请求，提高资源加载效率.

　　

最后我的做法是设计了三个场景（基于页面平时真正的高峰时间段下的场景）查看高峰时间段系统是否可以完美承受压力，之后开始负载测试查看上压力后的各个资源的性能瓶颈，最后在附上lighthouse的测试报告方便开发优化.

下面是一些疑问和解析:

1. 疑问：jmeter的响应时间是否包含资源的加载时间?

我的答案：这个问题我问了两个不同的AI软件（chatgpt和豆包），结果给的答案截然相反，所以后续我又查了很多资料，最终确认在GET URL请求时是包括的，如果JMeter测得的响应时间过长，大概率意味着页面整体加载以及资源获取过程存在延迟因素，可以进一步排查是服务器处理缓慢、网络传输问题，还是资源本身加载异常.

2. 疑问：Lighthouse是否可以查看大量并发时页面渲染的结果?

我的答案：Lighthouse 本身不能查看大量并发的页面渲染响应结果，它没有内置机制来模拟大量并发用户访问同一个页面或者多个页面的情况，但是它可以结合jmeter来使用，在jmeter并发时进行测试来查看并发场景的页面渲染。（但是这里需要注意，响应时间如果太长lighthouse会直接判定失败不能出报告，所以建议在低并发时使用） 。

3. 疑问：Lighthouse是否只能对单一页面进行测试?

我的答案：Lighthouse 不能直接同时对多个页面进行测试，要是想要一下子知道多个页面，可能需要结合其他脚本来循环执行lighthouse才能得出结果.

4. 疑问：如何判断不是网络原因和带宽原因导致的响应时间过长或者超时?

我的答案：我是尝试了在多个网络环境下进行的测试才排除了网络的原因，但是也可以在测试时通过（ping [服务器 IP] -t）来查看是否丢包.

  。

最后此篇关于浅聊web前端性能测试的文章就讲到这里了,如果你想了解更多关于浅聊web前端性能测试的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。