Performance Budget and Core Web Vitals for TeamsLighthouse 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