Automating Core Web Vitals Monitoring with Lighthouse CI and GitHub Actions

Stop running ad hoc Lighthouse reports in your browser like a mere mortal. If you’re serious about technical SEO on a shoestring budget, you need to bake performance and Core Web Vitals audits directly into your development pipeline. The free tier of Google’s Lighthouse CI, paired with GitHub Actions, gives you a continuous, zero-cost site health audit that catches regressions before they ship. No cron jobs, no third-party dashboards, no manual screenshot comparisons. Just a blunt, data-driven check that runs every time you push code.

The typical startup marketer’s approach involves firing up Chrome DevTools, clicking “Generate report,” and then manually tabulating scores across a handful of URLs. That’s fine for a one-off, but it scales like a wet fart in a hurricane. For a real low-cost technical SEO hack, you need to treat your site health audit as code. Lighthouse CI (LHCI) is the tool that makes this possible. It wraps Google Lighthouse into a Node.js module that you can run headlessly, compare results across builds, and fail your CI pipeline if metrics degrade beyond a configurable threshold. And yes, the entire thing is free.

Start by adding LHCI to your project as a dev dependency. You’ll need `@lhci/cli` installed globally or via npm. The real power comes from its assertion mode. You define a `.lighthouserc.js` file where you set budgets for each metric: Largest Contentful Paint below 2.5 seconds, Cumulative Layout Shift under 0.1, First Input Delay (or Total Blocking Time for lab) under 200 milliseconds. If a new commit pushes LCP above 3.0? The build fails. Your marketing team doesn’t have to care about the numbers because they never see the numbers—they only see a green checkmark or a red X in their pull request.

But a standalone LHCI run still requires you to trigger it manually. That’s where GitHub Actions enters the equation. Write a workflow file that checks out your code, spins up a headless Chrome, and runs `lhci autorun` against your staging or production URL. You can even pass environment variables to point at different builds. For example, if you deploy a preview environment for every pull request, you can audit that preview URL specifically. This catches issues like bloated JavaScript bundles or missing lazy-load attributes that would tank your real-user metrics on production.

Now, here’s the nuance most tutorials gloss over: Lighthouse in CI mode doesn’t simulate a specific device by default. You must configure `--preset desktop` or `--chromeFlags=’--window-size=360,640’` if you want mobile audits. And don’t forget to set `collect.numberOfRuns` to at least three to smooth out variance from CPU throttling. Each run takes around thirty seconds, so your total CI time for one URL is under two minutes. For a startup with a handful of critical pages—say, homepage, product page, checkout, and blog template—you can audit all four within the free tier of GitHub Actions.

The real hack lies in extending LHCI with custom assertions. The built-in budgets cover only the Core Web Vitals and Lighthouse scores. But you can also assert on specific audits like `unused-javascript`, `render-blocking-resources`, or `uses-responsive-images`. Write a pattern like `assertions: