Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Monitorowanie wydajności za pomocą Lighthouse CI

Jak dodać Lighthouse do systemu trybu ciągłej integracji, takiego jak GitHub Actions.

Katie Hempenius

Lighthouse CI to zestaw narzędzi do korzystania z Lighthouse podczas trybu ciągłej integracji. Lighthouse CI można włączyć do przepływów pracy programistów na wiele różnych sposobów. W tym przewodniku omówimy te tematy:

Korzystanie z interfejsu wiersza poleceń Lighthouse CI.
skonfigurować dostawcę CI, aby uruchamiał Lighthouse CI;
skonfigurowanie akcji GitHub i sprawdzania stanu dla Lighthouse CI; Spowoduje to automatyczne wyświetlanie wyników Lighthouse w żądaniach pull na GitHubie.
tworzenie panelu wydajności i magazynu danych na potrzeby raportów Lighthouse;

Przegląd

Lighthouse CI to zestaw bezpłatnych narzędzi, które ułatwiają korzystanie z Lighthouse do monitorowania wydajności. Pojedynczy raport Lighthouse zawiera podsumowanie wydajności strony internetowej w momencie jego wygenerowania. Lighthouse CI pokazuje, jak te wyniki zmieniały się w czasie. Można go używać do identyfikowania wpływu konkretnych zmian w kodzie lub do sprawdzania, czy progi wydajności są osiągane podczas procesów trybu ciągłej integracji. Chociaż monitorowanie wydajności jest najczęstszym przypadkiem użycia Lighthouse CI, można go używać do monitorowania innych aspektów raportu Lighthouse, takich jak SEO czy ułatwienia dostępu.

Główną funkcjonalność Lighthouse CI zapewnia interfejs wiersza poleceń Lighthouse CI. (Uwaga: to inne narzędzie niż interfejs wiersza poleceń Lighthouse). Interfejs wiersza poleceń Lighthouse CI udostępnia zestaw poleceń do korzystania z Lighthouse CI. Na przykład polecenie autorun wykonuje kilka uruchomień Lighthouse, identyfikuje medianę raportu Lighthouse i przesyła raport do przechowywania. To zachowanie można w dużym stopniu dostosować, przekazując dodatkowe flagi lub dostosowując plik konfiguracji Lighthouse CI, lighthouserc.js.

Chociaż główna funkcjonalność Lighthouse CI jest przede wszystkim zawarta w interfejsie wiersza poleceń Lighthouse CI, Lighthouse CI jest zwykle używany w jeden z tych sposobów:

Uruchamianie Lighthouse CI w ramach trybu ciągłej integracji
użycie akcji Lighthouse CI GitHub, która uruchamia się i dodaje komentarz do każdego żądania pull;
śledzenie skuteczności w czasie za pomocą panelu udostępnianego przez serwer Lighthouse.

Wszystkie te podejścia są oparte na interfejsie wiersza poleceń Lighthouse CI.

Alternatywy dla Lighthouse CI obejmują usługi monitorowania skuteczności innych firm lub pisanie własnego skryptu do zbierania danych o skuteczności podczas procesu CI. Rozważ skorzystanie z usługi innej firmy, jeśli wolisz, aby ktoś inny zarządzał serwerem monitorowania wydajności i urządzeniami testowymi, lub jeśli chcesz korzystać z funkcji powiadomień (np. przez e-mail lub integrację ze Slackiem) bez konieczności samodzielnego tworzenia tych funkcji.

Korzystanie z Lighthouse CI lokalnie

W tej sekcji wyjaśniamy, jak lokalnie uruchomić i zainstalować interfejs wiersza poleceń Lighthouse CI oraz jak skonfigurować lighthouserc.js. Uruchomienie interfejsu wiersza poleceń Lighthouse CI lokalnie to najprostszy sposób na sprawdzenie, czy plik lighthouserc.js jest prawidłowo skonfigurowany.

Zainstaluj interfejs wiersza poleceń Lighthouse CI.
```
npm install -g @lhci/cli
```
Lighthouse CI konfiguruje się, umieszczając plik lighthouserc.js w katalogu głównym repozytorium projektu. Ten plik jest obowiązkowy i zawiera informacje o konfiguracji Lighthouse CI. Chociaż Lighthouse CI można skonfigurować do używania bez repozytorium Git, instrukcje w tym artykule zakładają, że repozytorium projektu jest skonfigurowane do używania Gita.
W katalogu głównym repozytorium utwórz plik konfiguracji lighthouserc.js.
```
touch lighthouserc.js
```

Dodaj do pliku lighthouserc.js ten kod: Ten kod to pusta konfiguracja Lighthouse CI. W kolejnych krokach dodasz do tej konfiguracji więcej elementów.

module.exports = {
  ci: {
    collect: {
      /* Add configuration here */
    },
    upload: {
      /* Add configuration here */
    },
  },
};

Za każdym razem, gdy Lighthouse CI jest uruchamiany, uruchamia serwer, który obsługuje Twoją witrynę. Ten serwer umożliwia Lighthouse wczytywanie witryny, nawet gdy nie działają żadne inne serwery. Po zakończeniu działania Lighthouse CI automatycznie wyłączy serwer. Aby mieć pewność, że wyświetlanie działa prawidłowo, skonfiguruj właściwości staticDistDir lub startServerCommand.

Jeśli Twoja witryna jest statyczna, dodaj właściwość staticDistDir do obiektu ci.collect, aby wskazać, gdzie znajdują się pliki statyczne. Lighthouse CI będzie używać własnego serwera do wyświetlania tych plików podczas testowania witryny. Jeśli Twoja witryna nie jest statyczna, dodaj właściwość startServerCommand do obiektu ci.collect, aby wskazać polecenie, które uruchamia serwer. Lighthouse CI uruchomi nowy proces serwera podczas testowania i wyłączy go po zakończeniu.
```
// Static site example
collect: {
  staticDistDir: './public',
}
```
```
// Dynamic site example
collect: {
  startServerCommand: 'npm run start',
}
```
Dodaj właściwość url do obiektu ci.collect, aby wskazać adresy URL, pod którymi Lighthouse CI ma uruchomić Lighthouse. Wartość właściwości url powinna być podana jako tablica adresów URL. Może ona zawierać co najmniej 1 adres URL. Domyślnie Lighthouse CI uruchamia Lighthouse 3 razy dla każdego adresu URL.
```
collect: {
  // ...
  url: ['http://localhost:8080']
}
```
Uwaga: te adresy URL powinny być obsługiwane przez serwer skonfigurowany w poprzednim kroku. Jeśli więc Lighthouse CI działa lokalnie, te adresy URL powinny prawdopodobnie zawierać localhost, a nie hosta produkcyjnego.
Dodaj właściwość target do obiektu ci.upload i ustaw wartość na 'temporary-public-storage'. Raporty Lighthouse zebrane przez Lighthouse CI zostaną przesłane do tymczasowego publicznego miejsca na dane. Raport będzie tam przechowywany przez 7 dni, a potem zostanie automatycznie usunięty. W tym przewodniku po konfiguracji używamy opcji przesyłania „tymczasowe miejsce na dane publiczne”, ponieważ można ją szybko skonfigurować. Informacje o innych sposobach przechowywania raportów Lighthouse znajdziesz w dokumentacji.
```
upload: {
  target: 'temporary-public-storage',
}
```
Lokalizacja przechowywania raportu będzie wyglądać mniej więcej tak:
```
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
```
(Ten adres URL nie będzie działać, ponieważ raport został już usunięty).
Uruchom interfejs wiersza poleceń Lighthouse CI z terminala za pomocą polecenia autorun. Spowoduje to trzykrotne uruchomienie Lighthouse i przesłanie raportu Lighthouse z medianą.
```
lhci autorun
```
Jeśli Lighthouse CI jest prawidłowo skonfigurowany, po uruchomieniu tego polecenia powinny pojawić się dane wyjściowe podobne do tych:
```
✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server on port 65324...
Running Lighthouse 3 time(s) on http://localhost:65324/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:65324/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.
```
Możesz zignorować komunikat GitHub token not set w danych wyjściowych konsoli. Token GitHuba jest potrzebny tylko wtedy, gdy chcesz używać Lighthouse CI z GitHub Action. W dalszej części tego artykułu wyjaśniono, jak skonfigurować działanie GitHub.

Kliknięcie linku w wynikach, który zaczyna się od https://storage.googleapis.com..., spowoduje przejście do raportu Lighthouse odpowiadającego medianie uruchomień Lighthouse.

Domyślne ustawienia używane przez autorun można zastąpić za pomocą wiersza poleceń lub lighthouserc.js. Na przykład konfiguracja lighthouserc.js poniżej wskazuje, że przy każdym uruchomieniu autorun powinno zostać zebranych 5 uruchomień Lighthouse.

Zaktualizuj lighthouserc.js, aby używać właściwości numberOfRuns:

module.exports = {
    // ...
    collect: {
      numberOfRuns: 5
    },
  // ...
  },
};

Uruchom ponownie polecenie autorun:

lhci autorun

Dane wyjściowe terminala powinny wskazywać, że Lighthouse został uruchomiony 5 razy, a nie domyślne 3 razy:

✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Automatically determined ./dist as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 64444...
Running Lighthouse 5 time(s) on http://localhost:64444/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:64444/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.

Aby dowiedzieć się więcej o innych opcjach konfiguracji, zapoznaj się z dokumentacją konfiguracji Lighthouse CI.

Skonfiguruj proces CI, aby uruchamiać Lighthouse CI

Lighthouse CI można używać z ulubionym narzędziem CI. Sekcja Configure Your CI Provider (Konfigurowanie dostawcy CI) w dokumentacji Lighthouse CI zawiera przykładowe kody pokazujące, jak włączyć Lighthouse CI do plików konfiguracji popularnych narzędzi CI. Te przykłady kodu pokazują, jak uruchomić Lighthouse CI, aby zbierać pomiary wydajności podczas procesu CI.

Dobrym punktem wyjścia do monitorowania wydajności jest zbieranie pomiarów wydajności za pomocą Lighthouse CI. Zaawansowani użytkownicy mogą jednak pójść o krok dalej i użyć Lighthouse CI, aby niepowodzeniem kończyły się kompilacje, które nie spełniają wstępnie zdefiniowanych kryteriów, takich jak zaliczenie określonych kontroli Lighthouse lub spełnienie wszystkich budżetów wydajności. To zachowanie jest konfigurowane za pomocą właściwości assert pliku lighthouserc.js.

Lighthouse CI obsługuje 3 poziomy asercji:

off: ignoruj asercje
warn: błędy drukowania w stderr
error: wyświetla błędy w stderr i zamyka Lighthouse CI z niezerowym kodem wyjścia

Poniżej znajdziesz przykład konfiguracji lighthouserc.js, która zawiera asercje. Ustawia asercje dla wyników Lighthouse w kategoriach wydajności i ułatwień dostępu. Aby to przetestować, dodaj do pliku lighthouserc.js asercje pokazane poniżej, a następnie ponownie uruchom Lighthouse CI.

module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },
    upload: {
      // ...
    },
  },
};

Dane wyjściowe konsoli, które generuje, wyglądają tak:

Zrzut ekranu z ostrzeżeniem wygenerowanym przez Lighthouse CI

Więcej informacji o asercjach Lighthouse CI znajdziesz w dokumentacji.

Konfigurowanie działania na GitHubie do uruchamiania Lighthouse CI

Do uruchamiania Lighthouse CI można użyć akcji na GitHubie. Spowoduje to wygenerowanie nowego raportu Lighthouse za każdym razem, gdy zmiana kodu zostanie przesłana do dowolnej gałęzi repozytorium GitHub. Użyj tego w połączeniu ze sprawdzaniem stanu, aby wyświetlać te wyniki przy każdym żądaniu pull.

Zrzut ekranu przedstawiający sprawdzanie stanu w GitHubie

W katalogu głównym repozytorium utwórz katalog o nazwie .github/workflows. W tym katalogu będą znajdować się przepływy pracy Twojego projektu. Przepływ pracy to proces, który jest uruchamiany w określonym czasie (np. gdy kod jest przesyłany) i składa się z co najmniej 1 działania.
```
mkdir .github
mkdir .github/workflows
```
W .github/workflows utwórz plik o nazwie lighthouse-ci.yaml. Ten plik będzie zawierać konfigurację nowego przepływu pracy.
```
touch lighthouse-ci.yaml
```

Dodaj do pliku lighthouse-ci.yaml ten tekst:

name: Build project and run Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 10.x
        uses: actions/setup-node@v1
        with:
          node-version: 10.x
      - name: npm install
        run: |
          npm install
      - name: run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"

Ta konfiguracja konfiguruje przepływ pracy składający się z jednego zadania, które będzie uruchamiane za każdym razem, gdy nowy kod zostanie przesłany do repozytorium. To zadanie składa się z 4 kroków:

Sprawdź repozytorium, w którym będzie uruchamiany Lighthouse CI.
Instalowanie i konfigurowanie Node
Instalowanie wymaganych pakietów npm
Uruchom Lighthouse CI i prześlij wyniki do tymczasowego publicznego miejsca na dane.

Zatwierdź te zmiany i prześlij je do GitHuba. Jeśli wykonasz opisane powyżej czynności, przesłanie kodu do GitHuba spowoduje uruchomienie dodanego właśnie przepływu pracy.
Aby potwierdzić, że Lighthouse CI został uruchomiony, i wyświetlić wygenerowany przez niego raport, otwórz kartę Actions (Działania) w projekcie. Pod ostatnim zatwierdzeniem powinien być widoczny przepływ pracy Build project and Run Lighthouse CI (Skompiluj projekt i uruchom Lighthouse CI).

Raport Lighthouse odpowiadający konkretnemu zatwierdzeniu możesz otworzyć na karcie Actions (Działania). Kliknij zatwierdzenie, a następnie krok przepływu pracy Lighthouse CI i rozwiń wyniki kroku Uruchom Lighthouse CI.

Właśnie udało Ci się skonfigurować działanie GitHub, aby uruchomić Lighthouse CI. Będzie to najbardziej przydatne w połączeniu ze sprawdzaniem stanu w GitHubie.

Konfigurowanie sprawdzania stanu w GitHubie

Sprawdzanie stanu, jeśli jest skonfigurowane, to komunikat, który pojawia się przy każdym PR i zwykle zawiera informacje takie jak wyniki testu lub powodzenie kompilacji.

Zrzut ekranu przedstawiający kartę „Ustawienia” na GitHubie

Poniżej opisujemy, jak skonfigurować sprawdzanie stanu w Lighthouse CI.

Otwórz stronę aplikacji Lighthouse CI na GitHubie i kliknij Configure (Skonfiguruj).
(Opcjonalnie) Jeśli należysz do wielu organizacji na GitHubie, wybierz organizację, która jest właścicielem repozytorium, w którym chcesz używać Lighthouse CI.
Wybierz Wszystkie repozytoria, jeśli chcesz włączyć Lighthouse CI we wszystkich repozytoriach, lub Tylko wybrane repozytoria, jeśli chcesz używać go tylko w określonych repozytoriach, a następnie wybierz repozytoria. Następnie kliknij Zainstaluj i autoryzuj.
Skopiuj wyświetlony token. Będzie Ci potrzebny w następnym kroku.
Aby dodać token, otwórz stronę Settings (Ustawienia) repozytorium GitHub, kliknij Secrets (Sekrety), a następnie Add a new secret (Dodaj nowy sekret).
W polu Name (Nazwa) wpisz LHCI_GITHUB_APP_TOKEN, a w polu Value (Wartość) wpisz token skopiowany w ostatnim kroku, a następnie kliknij przycisk Add secret (Dodaj obiekt tajny).
Otwórz plik lighthouse-ci.yaml i dodaj nowy obiekt tajny środowiska do polecenia „run Lighthouse CI”.

-           name: run Lighthouse CI
            run: |
              npm install -g @lhci/cli@0.3.x
              lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+            env:
+              LHCI_GITHUB_APP_TOKEN: $

Sprawdzanie stanu jest gotowe do użycia. Aby to przetestować, utwórz nowe żądanie pull lub prześlij zatwierdzenie do istniejącego żądania pull.

Konfigurowanie serwera Lighthouse CI

Serwer Lighthouse CI udostępnia panel do przeglądania historycznych raportów Lighthouse. Może też służyć jako prywatny, długoterminowy magazyn danych na potrzeby raportów Lighthouse.

Zrzut ekranu panelu Lighthouse CI Server

Zrzut ekranu przedstawiający porównanie 2 raportów Lighthouse na serwerze Lighthouse CI

Wybierz commity do porównania.
Wartość, o którą zmienił się wynik Lighthouse między 2 zatwierdzeniami.
W tej sekcji wyświetlane są tylko dane, które uległy zmianie między tymi 2 zatwierdzeniami.
Regresje są wyróżnione na różowo.
Ulepszenia są wyróżnione na niebiesko.

Lighthouse CI Server jest najlepszym rozwiązaniem dla użytkowników, którzy nie mają problemów z wdrażaniem własnej infrastruktury i zarządzaniem nią.

Informacje o konfigurowaniu serwera Lighthouse CI, w tym instrukcje dotyczące wdrażania za pomocą Heroku i Dockera, znajdziesz w tym artykule.

Więcej informacji

Repozytorium Lighthouse CI na GitHubie