How Do I Run Lighthouse CI Against Webflow Sites Without Breaking the Bank in 2026?

Why Did I Even Try Running Lighthouse CI Against Webflow Sites?

I broke the rules of a Webflow performance retainer two months ago. A client kept asking me to prove that the LCP and INP numbers I quoted in our weekly review were not cherry picked. Running Lighthouse manually in DevTools and screenshotting the score was no longer a credible answer. So I set up Lighthouse CI to run against every staging publish, expecting it to be expensive, fragile, and a waste of two weekends. It turned out to be cheap, sturdy, and one of the better calls I have made this year.

Google's web.dev team reported in May 2026 that sites running automated Core Web Vitals checks fix performance regressions about 4 times faster than sites that rely on manual audits. That ratio is conservative in my experience. The first time Lighthouse CI flagged a 280 millisecond INP regression from a third party script my client had added, we found it 90 minutes after publish instead of three weeks later when a user complained.

This piece walks through how I run Lighthouse CI against a Webflow site, where the money actually goes, and the small set of gotchas that almost made me give up before week two.

What Is Lighthouse CI and How Does It Work With Webflow?

Lighthouse CI is Google's open source automation layer around the Lighthouse audit you already run in Chrome DevTools. It runs the audit on a schedule or on a trigger, stores the results, and compares them against thresholds you set. When a metric crosses a threshold, it fails the build, posts to Slack, or both.

For Webflow, the trigger is the tricky bit. Webflow does not give you a publish webhook on the lower tier plans. What you do get is a site_publish webhook on Pro plans and above. I wire that webhook to a GitHub Actions workflow that runs Lighthouse CI against the published URL, stores results, and posts a summary back to the client's shared Slack channel.

How Much Does This Actually Cost to Run?

This was the question that kept me from starting for a year. The real answer is roughly five US dollars a month per client for a daily audit run, plus a free GitHub Actions allowance. The cost lives in two places. The compute time for the Lighthouse run, which fits inside the GitHub free tier for almost any small studio. And a tiny VPS for the Lighthouse CI server that stores history, which I run on a 5 dollar Hetzner box.

If you want zero infrastructure, you can swap the Lighthouse CI server for the public web.dev measure endpoint and store results in a Google Sheet via Apps Script. The trade off is that you lose the historical comparison graph that makes regressions obvious. For a client paying you a real retainer, the 5 dollar box is the better deal.

What Should You Actually Set as Performance Budgets?

The defaults are too permissive. I budget LCP at 2.0 seconds for the homepage, INP at 150 milliseconds for any page with a form, and CLS at 0.05 site wide. Core Web Vitals thresholds set by Google are 2.5 seconds, 200 milliseconds, and 0.1 respectively, but those are the "good" line, not the "great" line. Setting your budget at the great line catches regressions a full quarter before Google does.

For accessibility, I budget 95 or higher and treat anything that drops below 90 as a build failure. The full audit framework I lean on draws from my piece on how I audit Webflow sites for LCP issues without Lighthouse, which covers the manual checks I still run alongside the automated ones.

How Do You Wire Lighthouse CI to a Webflow Publish Event?

The shortest path is a small Node script in a GitHub repository, triggered by a Webflow webhook that posts to a repository_dispatch event. The Webflow webhook fires on site_publish, hits a Cloudflare Worker that re emits as a GitHub dispatch, and the workflow runs Lighthouse CI against your three or four most important URLs.

For clients on lower Webflow plans without the publish webhook, I fall back to a daily cron schedule in GitHub Actions. That misses the immediate post publish window but still catches multi day regressions. The cron route works for anyone, including students, on the entirely free GitHub tier.

Which URLs Should You Run Lighthouse Against?

Run the audit against the URLs your buyers actually land on, not your full sitemap. For most B2B Webflow sites that is the homepage, two top performing blog posts, the pricing page, and one or two service pages. Five URLs catch 80 percent of the regressions you would have seen across a 400 URL run, in my experience auditing about 30 client sites over the last year.

Adding more URLs has rapidly diminishing returns and starts to push the Lighthouse run past the GitHub Actions free tier. I would rather audit five URLs daily than fifty URLs weekly. Daily cadence is what catches a third party script regression while you can still remember what you changed.

What Are the Three Gotchas That Almost Made Me Quit?

First, Webflow's CDN sometimes serves a fresh version to the Lighthouse audit but stale assets to real users for ten or fifteen minutes after publish. I now wait two minutes after the publish webhook fires before triggering the audit. Second, Lighthouse runs in a clean environment with no cookies or login state, so any page that depends on those will misreport. Run the audit on logged out pages only.

Third, the INP metric in Lighthouse is a lab estimate, not a field measurement. The lab number can be wildly off from what real users see. I cross check against the Web Vitals report in Webflow Analyze, which uses real user data. If lab INP is 100 milliseconds but field INP is 280 milliseconds, trust the field number and dig into the regression.

How Do You Show the Client This Is Working?

The weekly Slack summary is the deliverable that has saved more retainers than any deck I have ever made. Each Monday morning, the client sees a single message with the LCP, INP, and CLS trend for each tracked URL, plus a green or red flag against the budget. If everything is green, the message is a 30 second read. If something is red, we have the conversation we were going to have anyway, with data instead of vibes.

I pair that with the edge cache and CWV detail from my piece on how Webflow's edge cache hit ratio report changes CWV tuning for any client that wants to dig past the Lighthouse number into root causes.

How Do You Set This Up This Week?

Spend a Saturday morning on three things. Create a GitHub repository with the Lighthouse CI configuration and the URLs you want audited. Set up a daily cron in GitHub Actions so you have a baseline before you wire the webhook. Then add the Webflow site_publish webhook pointing at a Cloudflare Worker that fires the GitHub dispatch event. You will have your first regression report by Monday morning.

If you want me to set this up for your Webflow site or just look at your current performance budgets, I am happy to walk through it. Let's chat.