Performance Budget and Core Web Vitals for Teams, Lighthouse CI in Practice (2026)

TL;DR

A performance budget is a set of hard thresholds (LCP, INP, CLS, JS size) that CI blocks when a PR exceeds them, instead of discovering regression a week later in Search Console. Lighthouse CI runs an audit on the production build for every pull request and fails merge when mobile LCP > 2.5 s or CLS > 0.1. Dev, design, and marketing share one budget table: hero max 200 KB, third-party scripts only after review, GA4 afterInteractive, Ads lazyOnload. Hosting on DevStudioIT Cloud plus RUM after deploy closes the loop between CI synthetics and real users.

Who is this for

• Next.js / React teams adding components every sprint until the homepage LCP hits 4 s
• Product owners responsible for Google Ads conversions, slow landing pages raise CPC
• Companies without a dedicated performance engineer, Lighthouse CI is an automatic gatekeeper
• Designers adding animations and fonts, budget forces tradeoffs before merge
• Projects after an SEO audit with "yellow" CWV that need to stay green, not just a one-time fix

Keyword

performance budget core web vitals, lighthouse ci team, lcp inp cls thresholds, performance budget ci, performance regression pull request, lighthouse github actions 2026

What a performance budget is in 2026

A performance budget is measurable limits in CI and project documentation:

Budget does not replace optimization, it prevents regression. First optimization is manual work; budget maintains the result.

Core Web Vitals, targets for product teams

Google evaluates LCP, INP, and CLS in field data (CrUX). Lighthouse synthetics in CI correlate with CrUX but do not replace it, use both.

Marketing should know: a new tracking pixel without lazyOnload is a dev ticket with expected +200 ms LCP in LHCI, not "just add the script quickly."

Lighthouse CI, repository configuration

lighthouserc.json at repo root:

{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "startServerCommand": "npm run start",
      "startServerReadyPattern": "Ready",
      "url": ["http://localhost:3000/pl", "http://localhost:3000/en"]
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "interactive": ["warn", { "maxNumericValue": 3800 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

GitHub Actions workflow (summary):

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci && npm run build
      - run: npx @lhci/cli@0.14.x autorun

Key: npm run build + npm run start, same chain as deploy on DevStudioIT Cloud. Auditing next dev falsifies results.

Extended details: Lighthouse CI, Next.js audit.

JS and third-party budget, PR review rules

Checklist in PR template:

• New npm package, justification + bundle size
• Hero image, AVIF/WebP, priority only on LCP
• Marketing script, load strategy (lazyOnload / worker)
• Font, subset, display: swap, max 2 weights
• Client component, can it be a Server Component?

Responsibility table:

INP in practice, what teams catch

INP replaced FID as the interaction metric. Typical culprits on corporate sites:

• Chatbot loading afterInteractive on every page
• Mobile menu with heavy JS re-rendering the whole tree
• Scroll handlers without debounce
• Radix/shadcn, fine, but dozens of client components on landing

INP budget in LHCI (optional assert) or RUM monitoring (web-vitals library → endpoint).

RUM after deploy, closing the loop

LHCI = CI synthetics. After deploy on DevStudioIT Cloud add RUM:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric: Metric) {
  navigator.sendBeacon('/api/vitals', JSON.stringify(metric));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Compare p75 with CrUX weekly. Green CI but red RUM, regional TTFB, adblock on tags, or CDN path unlike CI localhost.

Escalation when budget blocks a feature

Process without permanently disabling LHCI:

1. Feature flag, enable after optimization
2. Temporary assert exception with ticket and removal date
3. Split bundle, lazy load heavy module
4. Scope cut, MVP without 3D animation

Permanently lowering minScore is technical debt in metrics, returns as conversion drop.

FAQ

Should desktop be tested in CI too?

Yes, but mobile assert is mandatory, Google CWV field data is mobile-first for most B2B sites. Desktop can be warn.

Performance 0.85 vs LCP 2.5 s, which matters more?

Assert LCP/CLS/INP directly, score is a synthetic aggregate. Score 0.9 with LCP 2.6 s still fails good CWV threshold.

Lighthouse CI on monorepo?

Separate lighthouserc.json per app or matrix url. Budget per product, marketing landing ≠ SaaS dashboard.

Who pays for performance regression?

Lower Ads Quality Score, lower organic CTR, fewer form leads. CI budget is insurance worth multiples of pipeline maintenance cost.

Want a performance budget in your repository?

• Contact us, we implement Lighthouse CI, CWV thresholds, and review process for your team
• Lighthouse CI Next.js, full workflow configuration
• Website performance optimization, practices beyond CI