Performance budget i Core Web Vitals dla zespołuLighthouse CI w praktyce (2026)

TL;DR

Performance budget to twarde progi (LCP, INP, CLS, rozmiar JS), które CI blokuje, gdy PR je przekracza — zamiast odkrywać regresję tydzień później w Search Console. Lighthouse CI uruchamia audyt na buildzie produkcyjnym przy każdym pull requeście i failuje merge, gdy mobile LCP > 2,5 s lub CLS > 0,1. Zespół dev, design i marketing dzieli jedną tabelę budżetów: hero max 200 KB, third-party scripts tylko po review, GA4 afterInteractive, Ads lazyOnload. Hosting na DevStudioIT Cloud + RUM po deploy domyka pętlę między syntetyką CI a prawdziwymi użytkownikami.

Dla kogo to jest

• Zespołów Next.js / React, które co sprint dodają komponenty i „nagle" strona główna ma LCP 4 s
• Product ownerów odpowiadających za konwersje z Google Ads — wolny landing podnosi CPC
• Firm bez dedykowanego performance engineer — Lighthouse CI jest automatycznym gatekeeperem
• Designerów dodających animacje i fonty — budżet wymusza tradeoff przed merge
• Projektów po audycie SEO, gdzie CWV są „żółte" i trzeba utrzymać zielone, nie tylko jednorazowo naprawić

Fraza (SEO)

performance budget core web vitals, lighthouse ci zespół, lcp inp cls progi, budżet wydajności ci, regresja wydajności pull request, lighthouse github actions 2026

Czym jest performance budget w 2026

Performance budget to zestaw limitów mierzalnych w CI i w dokumentacji projektu:

Budżet nie zastępuje optymalizacji — zapobiega regresji. Pierwsza optymalizacja to praca ręczna; budżet utrzymuje wynik.

Core Web Vitals — cele dla zespołu produktowego

Google ocenia LCP ( Largest Contentful Paint ), INP ( Interaction to Next Paint ) i CLS ( Cumulative Layout Shift ) w field data (CrUX). Syntetyka Lighthouse w CI koreluje z CrUX, ale nie zastępuje — używaj obu.

Marketing musi wiedzieć: nowy pixel tracking bez lazyOnload to ticket do dev z oczekiwanym +200 ms LCP w LHCI — nie „dodajmy szybko skrypt".

Lighthouse CI — konfiguracja w repozytorium

Plik lighthouserc.json w korzeniu repo:

{
  "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"
    }
  }
}

Workflow GitHub Actions (skrót):

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

Klucz: npm run build + npm run start — ten sam łańcuch co deploy na DevStudioIT Cloud. Audyt na next dev fałszuje wyniki.

Szczegóły rozszerzone: Lighthouse CI — audyt Next.js.

Budżet JS i third-party — reguły review PR

Checklist w opisie PR (template):

• Nowy npm package — uzasadnienie + rozmiar bundle
• Obraz hero — format AVIF/WebP, priority tylko na LCP
• Skrypt marketingowy — strategia ładowania (lazyOnload / worker)
• Font — subset, display: swap, max 2 wagi
• Komponent kliencki — czy można Server Component

Tabela odpowiedzialności:

INP w praktyce — co łapie zespół

INP zastąpił FID jako metryka interakcji. Winowajcy na stronach firmowych:

• Chatbot ładujący się afterInteractive na każdej stronie
• Menu mobilne z ciężkim JS i re-render całego drzewa
• Event handlery bez debounce na scroll
• Radix/shadcn — OK, ale dziesiątki komponentów client na landing

Budżet INP w LHCI (opcjonalny assert na experimental-interaction-to-next-paint) lub monitoring RUM (web-vitals library → endpoint na Branchly / analytics).

RUM po deploy — zamykanie pętli

LHCI = syntetyka w CI. Po deploy na DevStudioIT Cloud dodaj 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);

Porównuj percentyl 75 z CrUX co tydzień. Jeśli CI zielone, a RUM czerwone — problem TTFB regionu, adblock na tagach, lub trasa CDN inna niż localhost CI.

Eskalacja gdy budżet blokuje feature

Proces bez „wyłączania LHCI na stałe":

1. Feature flag — włączenie po optymalizacji
2. Tymczasowy wyjątek w assert z ticketem i datą usunięcia
3. Split bundle — lazy load ciężkiego modułu
4. Odrzucenie scope — MVP bez animacji 3D

Permanentne obniżenie minScore to dług techniczny w metrykach — wraca jako spadek konwersji.

FAQ

Czy desktop też testować w CI?

Tak, ale mobile assert jest obowiązkowy — Google CWV field data mobile-first dla większości stron B2B. Desktop może być warn.

Performance 0,85 vs LCP 2,5 s — co ważniejsze?

Assertuj bezpośrednio LCP/CLS/INP — score jest syntetycznym agregatem. Score 0,9 przy LCP 2,6 s nadal failuje dobry próg CWV.

Lighthouse CI na monorepo?

Osobny lighthouserc.json per app lub url w matrix. Budżet per produkt — landing marketing ≠ dashboard SaaS.

Kto płaci za regresję wydajności?

Spadek Quality Score w Ads, niższy organic CTR, mniej leadów z formularza. Budżet w CI to ubezpieczenie o wartości wielokrotności kosztu utrzymania pipeline.

Chcesz performance budget w swoim repozytorium?

• Skontaktuj się z nami — wdrożymy Lighthouse CI, progi CWV i review proces pod Twój zespół
• Lighthouse CI Next.js — pełna konfiguracja workflow
• Optymalizacja wydajności strony — praktyki poza CI