Frontend Academy · Lekcja

Automatyczne kontrole Lighthouse

Doda Pan/Pani akcję GitHub Lighthouse CI, ustawi progi wyników wydajności i dostępności oraz zablokuje scalanie zmian pogarszających Core Web Vitals.

Automatyczne kontrole Lighthouse to bezpłatna lekcja Frontend Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Frontend Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Dlaczego automatyzować Lighthouse?

Ręczne uruchamianie Lighthouse wykrywa regresje wydajności z opóźnieniem — zwykle dopiero po skardze prawdziwego użytkownika. Automatyczny Lighthouse CI uruchamia się przy każdym PR, przerywa kompilację, gdy kluczowe metryki ulegają pogorszeniu, i śledzi wyniki w czasie. Wydajność należy traktować tak samo jak zestaw testów.

Lighthouse CI

Opracowany przez Google, otwartoźródłowy zestaw narzędzi Lighthouse CI (lhci): wielokrotnie uruchamia Lighthouse, oblicza medianę, sprawdza wyniki względem progów i przesyła rezultaty.

npm install -D @lhci/cli

# Run locally:
npx lhci autorun

lighthouserc.json — konfiguracja

Należy skonfigurować adresy URL do testowania, liczbę uruchomień i asercje.

// lighthouserc.json
{
  "ci": {
    "collect": {
      "url": [
        "http://localhost:3000",
        "http://localhost:3000/blog",
        "http://localhost:3000/pricing"
      ],
      "numberOfRuns": 5,
      "startServerCommand": "npm run start"
    },
    "assert": {
      "assertions": {
        "categories:performance":   ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "categories:seo":            ["warn", { "minScore": 0.9 }],
        "largest-contentful-paint":  ["error", { "maxNumericValue": 2500 }],
        "total-blocking-time":       ["error", { "maxNumericValue": 200 }],
        "cumulative-layout-shift":   ["error", { "maxNumericValue": 0.1 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Integracja z GitHub Action

Oficjalna akcja treosh/lighthouse-ci-action uruchamia lhci przy każdym PR i publikuje kontrolę statusu.

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: [pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci && npm run build
      - uses: treosh/lighthouse-ci-action@v11
        with:
          configPath: ./lighthouserc.json
          uploadArtifacts: true
          temporaryPublicStorage: true

Mediana z wielu uruchomień

Wyniki Lighthouse różnią się między uruchomieniami z powodu zakłóceń związanych z pomiarem czasu. Ustawienie numberOfRuns: 5 oblicza medianę, która jest wystarczająco stabilna do porównywania z progami. Mniej niż 3 uruchomienia daje niestabilne wyniki.

Budżety wydajności

Oprócz wyników można ustawić sztywne limity rozmiaru i liczby zasobów. Kompilacja kończy się niepowodzeniem po przekroczeniu tych limitów.

// budget.json
[
  {
    "resourceSizes": [
      { "resourceType": "script", "budget": 300 },
      { "resourceType": "image", "budget": 100 }
    ],
    "resourceCounts": [
      { "resourceType": "third-party", "budget": 10 }
    ]
  }
]

// lighthouserc.json:
"collect": {
  "settings": { "budgetsPath": "./budget.json" }
}

Serwer Lighthouse CI

Serwer LHCI można hostować samodzielnie, aby zachowywać dane historyczne, wyświetlać wykresy trendów i porównywać gałęzie w czasie. W przypadku jednorazowych wyników PR można też użyć tymczasowego publicznego magazynu.

Testowanie stron wymagających uwierzytelnienia

Należy użyć skryptów Puppeteer, aby zalogować się przed uruchomieniem Lighthouse.

// lighthouserc.json
"collect": {
  "puppeteerScript": "./lighthouse-login.js",
  "url": ["http://localhost:3000/dashboard"]
}

// lighthouse-login.js
module.exports = async (browser, context) => {
  const page = await browser.newPage();
  await page.goto('http://localhost:3000/login');
  await page.fill('#email', 'test@example.com');
  await page.fill('#password', 'test123');
  await page.click('button[type=submit]');
  await page.waitForNavigation();
};

Powiadomienia Slack/Discord

Wyniki LHCI można przekazywać na czat zespołu — regresje wydajności zasługują na taką samą uwagę jak nieudane testy.

Urządzenia mobilne a komputery stacjonarne

Domyślna konfiguracja Lighthouse zakłada urządzenie mobilne (wolne połączenie 4G i procesor ze średniej półki). W przypadku komputera stacjonarnego należy ustawić preset: 'desktop'. Większość aplikacji produkcyjnych powinna być sprawdzana w obu trybach — jako osobne zadania w CI.

Dostosowywanie progów

Należy zacząć od obecnych wyników jako wartości bazowych. Pierwszego dnia nie należy przerywać PR-ów — najpierw wystarczy rejestrować ostrzeżenia. Gdy zespół przyzwyczai się do tego procesu, można stopniowo zaostrzać progi.

Co poza Lighthouse

Lighthouse dostarcza dane laboratoryjne. Należy połączyć go z monitorowaniem rzeczywistych użytkowników (RUM): pakiet npm web-vitals wraz z własną analityką albo usługi takie jak SpeedCurve i Calibre pokazują rzeczywiste trendy wydajności.

Szybkie sprawdzenie

Dlaczego Lighthouse CI zwykle oblicza medianę z wielu uruchomień (na przykład 5), zamiast korzystać z pojedynczego uruchomienia?

Podsumowanie: automatyczny Lighthouse

lhci autorun integruje się z CI. Konfigurację przeprowadza się w lighthouserc.json: adresy URL, liczbę uruchomień (5 lub więcej), asercje dotyczące kategorii i metryk oraz budżety wydajności. W przypadku GitHub należy użyć treosh/lighthouse-ci-action. Samodzielne hostowanie serwera LHCI pozwala śledzić trendy. Do stron wymagających uwierzytelnienia należy używać skryptów Puppeteer. Audyt powinien obejmować urządzenia mobilne i komputery stacjonarne. Na początku należy stosować ostrzeżenia, a następnie z czasem zaostrzać progi. Aby uzyskać pełny obraz, warto połączyć te działania z RUM.

Często zadawane pytania

Czy lekcja „Automatyczne kontrole Lighthouse” jest bezpłatna?

Tak — pełny tekst „Automatyczne kontrole Lighthouse” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Frontend Academy, przejdź na CoddyKit PRO. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Automatyczne kontrole Lighthouse”?

Doda Pan/Pani akcję GitHub Lighthouse CI, ustawi progi wyników wydajności i dostępności oraz zablokuje scalanie zmian pogarszających Core Web Vitals. Ćwiczysz Frontend Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Frontend Academy?

Nie wymagamy żadnego doświadczenia. Frontend Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Automatyczne kontrole Lighthouse”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Frontend Academy?

Tak. Każda lekcja Frontend Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

GitHub Actions dla frontendu: lint, test i build
Wdrażanie na Vercel, Netlify i Cloudflare Pages
Zmienne środowiskowe w CI
Automatyczne kontrole Lighthouse

← Powrót do Frontend Academy