I created a Lighthouse audit that uses machine learning to detect if an anchor tag looks like a button. This involved training a TensorflowJS model, building a custom Lighthouse gatherer to capture high-resolution screenshots, and processing those screenshots to identify anchors styled as buttons. The audit highlights these anchors in the Lighthouse report. The code for the scraper, web app, and Lighthouse audit are available on GitHub. While there are edge cases, this project demonstrates the potential of using ML for visual inspection tasks in web development.
I needed higher resolution screenshots for an ML model to classify elements on a webpage, but the default Lighthouse screenshot was too compressed. So, I created a custom Lighthouse Gatherer using Puppeteer. This gatherer captures a full-page, high-resolution screenshot encoded as base64 and returns it along with the device pixel ratio. This was a fun little project, and the code is surprisingly concise. However, future Lighthouse versions may include higher-resolution screenshots, making this gatherer redundant.
This post explores whether developers are actively addressing issues highlighted by Lighthouse performance audits. By analyzing HTTP Archive data and tracking Lighthouse scores over time, we aim to uncover potential improvements. While directly correlating specific fixes to Lighthouse test failures is challenging, we can investigate trends and infer the impact of Lighthouse on web development practices. A key consideration is the evolution of Lighthouse itself, such as changes to CPU performance calculations, which may affect the comparability of results over time.
