由于我组主要是负责的是H5移动端项目，老板比较关注性能方面的指标，比如首页打开速度，所以一般会关注FP,FCP等等指标，所以一般项目写完以后都会用lighthouse查看，或者接入性能监控系统采集指标.
但是会出现两个问题，如果采用第一种方式，使用lighthouse查看性能指标，这个得依赖开发自身的积极性，他要是开发完就Merge上线，你也不知道具体指标怎么样。如果采用第二种方式，那么同样是发布到线上才能查看。最好的方式就是能强制要求开发在还没发布的时候使用lighthouse查看一下，那么在什么阶段做这个策略呢。聪明的同学可能想到，能不能在CICD构建阶段加上策略。其实是可以的，谷歌也想到了这个场景，提供性能守卫这个lighthouse ci插件
性能守卫
性能守卫是一种系统或工具，用于监控和管理应用程序或系统的性能。它旨在确保应用程序在各种负载和使用情况下能够提供稳定和良好的性能。
Lighthouse是一个开源的自动化工具，提供了四种使用方式：
- Chrome DevTools
- Chrome插件
- Node CLI
- Node模块
其架构实现图是这样的，有兴趣的同学可以深入了解一下
这里我们我们借助Lighthouse Node模块继承到CICD流程中，这样我们就能在构建阶段知道我们的页面具体性能，如果指标不合格，那么就不给合并MR
剖析lighthouse-ci实现
lighthouse-ci实现机制很简单，核心实现步骤如上图，差异就是lighthouse-ci实现了自己的server端，保持导出的性能指标数据，由于公司一般对这类数据敏感，所以我们一般只需要导出对应的数据指标JSON，上传到我们自己的平台就行了。
接下里，我们就来看看lighthouse-ci实现步骤：
- 启动浏览器实例：CLI通过Puppeteer启动一个Chrome实例。
const browser = await puppeteer.launch();
- 创建新的浏览器标签页：接着，CLI创建一个新的标签页（或称为"页面"）。
const page = await browser.newPage();
- 导航到目标URL：CLI命令浏览器加载指定的URL。
await page.goto('https://example.com');
- 收集数据：在加载页面的同时，CLI使用各种Chrome提供的API收集数据，包括网络请求数据、JavaScript执行时间、页面渲染时间等。
- 运行审计：数据收集完成后，CLI将这些数据传递给Lighthouse核心，该核心运行一系列预定义的审计。
- 生成和返回报告：最后，审计结果被用来生成一个JSON或HTML格式的报告。
const report = await lighthouse(url, opts, config).then(results => { return results.report; });
- 关闭浏览器实例：报告生成后，CLI关闭Chrome实例。
await browser.close();
// 伪代码 const puppeteer = require('puppeteer'); const lighthouse = require('lighthouse'); const {URL} = require('url'); async function run() { // 使用 puppeteer 连接到 Chrome 浏览器 const browser = await puppeteer.launch({ headless: true, args: ['--no-sandbox', '--disable-setuid-sandbox'], }); // 新建一个页面 const page = await browser.newPage(); // 在这里，你可以执行任何Puppeteer代码，例如: // await page.goto('https://example.com'); // await page.click('button'); const url = 'https://example.com'; // 使用 Lighthouse 进行审查 const {lhr} = await lighthouse(url, { port: new URL(browser.wsEndpoint()).port, output: 'json', logLevel: 'info', }); console.log(`Lighthouse score: ${lhr.categories.performance.score * 100}`); await browser.close(); } run();
导出的HTML文件
导出的JSON数据
实现一个性能守卫插件
在实现一个性能守卫插件，我们需要考虑以下因数：
- 易用性和灵活性：插件应该易于配置和使用，以便它可以适应各种不同的CI/CD环境和应用场景。它也应该能够适应各种不同的性能指标和阈值。
- 稳定性和可靠性：插件需要可靠和稳定，因为它将影响整个构建流程。任何失败或错误都可能导致构建失败，所以需要有强大的错误处理和恢复能力。
- 性能：插件本身的性能也很重要，因为它将直接影响构建的速度和效率。它应该尽可能地快速和高效。
- 可维护性和扩展性：插件应该设计得易于维护和扩展，以便随着应用和需求的变化进行适当的修改和更新。
- 报告和通知：插件应该能够提供清晰和有用的报告，以便开发人员可以快速理解和处理任何性能问题。它也应该有一个通知系统，当性能指标低于预定阈值时，能够通知相关人员。
- 集成：插件应该能够轻松集成到现有的CI/CD流程中，同时还应该支持各种流行的CI/CD工具和平台。
- 安全性：如果插件需要访问或处理敏感数据，如用户凭证，那么必须考虑安全性。应使用最佳的安全实践来保护数据，如使用环境变量来存储敏感数据。
// 伪代码 //perfci插件 const puppeteer = require('puppeteer'); const lighthouse = require('lighthouse'); const { port } = new URL(browser.wsEndpoint()); async function runAudit(url) { const browser = await puppeteer.launch(); const { lhr } = await lighthouse(url, { port, output: 'json', logLevel: 'info', }); await browser.close(); // 在这里定义你的性能预期 const performanceScore = lhr.categories.performance.score; if (performanceScore < 0.9) { // 如果性能得分低于0.9，脚本将抛出错误 throw new Error(`Performance score of ${performanceScore} is below the threshold of 0.9`); } } runAudit('https://example.com').catch(console.error);
使用
name: CI on: [push] jobs: lighthouseci: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: 16 - run: npm install && npm install -g @lhci/cli@0.11.x - run: npm run build - run: perfci autorun
