Ta strona została przetłumaczona przez Cloud Translation API.

Monitorowanie wydajności za pomocą Lighthouse CI

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

Katie Hempenius

Lighthouse CI to zestaw narzędzi do korzystania z Lighthouse podczas ciągłej integracji. CI Lighthouse można włączyć do procesów programistycznych na wiele różnych sposobów. W tym przewodniku znajdziesz:

za pomocą interfejsu wiersza poleceń Lighthouse CI.
Konfiguruję dostawcę CI do uruchamiania CI Lighthouse.
Skonfiguruj GitHub Action i sprawdzenie stanu w Lighthouse CI. Dzięki temu wyniki Lighthouse będą automatycznie wyświetlane w prośbach o przeniesienie w GitHub.
Tworzę panel wydajności i magazyn danych na potrzeby raportów Lighthouse.

Omówienie

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

Podstawowe funkcje Lighthouse CI są dostępne w interfejsie wiersza poleceń Lighthouse CI. Uwaga: jest to inne narzędzie niż interfejs wiersza poleceń Lighthouse. Interfejs wiersza poleceń Lighthouse CI udostępnia zestaw poleceń do użycia w Lighthouse CI. Na przykład komenda autorun wykonuje wiele przebiegów Lighthouse, identyfikuje medianę raportu Lighthouse i przesyła raport do przechowywania. To zachowanie można dostosować, podając dodatkowe flagi lub dostosowując plik konfiguracji Lighthouse CI (lighthouserc.js).

Chociaż główna funkcjonalność Lighthouse CI jest głównie opakowana w CLI Lighthouse CI, Lighthouse CI jest zwykle używany w jednym z tych sposobów:

Uruchamianie Lighthouse CI w ramach ciągłej integracji
Używanie akcji GitHub Lighthouse CI, która uruchamia i komentuje każde żądanie pull
Śledzenie skuteczności na przestrzeni czasu za pomocą panelu udostępnianego przez serwer Lighthouse.

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

Alternatywy dla CI w Lighthouse to m.in. zewnętrzne usługi monitorowania wydajności lub tworzenie własnych skryptów do zbierania danych o wydajności podczas procesu CI. Usługę zewnętrzną warto rozważyć, 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. integracji z e-mailem lub Slackiem) bez konieczności samodzielnego ich tworzenia.

Lokalne korzystanie z automatyzacji CI w Lighthouse

W tej sekcji opisaliśmy, jak uruchomić i zainstalować interfejs wiersza poleceń Lighthouse CI na komputerze lokalnym oraz jak skonfigurować lighthouserc.js. Lokalne uruchomienie interfejsu wiersza poleceń CI w Lighthouse to najprostszy sposób, aby upewnić się, że lighthouserc.js jest prawidłowo skonfigurowany.

Zainstaluj interfejs wiersza poleceń Lighthouse CI.
```
npm install -g @lhci/cli
```
CI Lighthouse jest konfigurowany przez umieszczenie pliku lighthouserc.js w katalogu głównym repozytorium projektu. Ten plik jest wymagany i zawiera informacje o konfiguracji związane z 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 git.
W katalogu głównym repozytorium utwórz lighthouserc.js plik konfiguracji.
```
touch lighthouserc.js
```

Dodaj do pliku lighthouserc.js ten kod: Ten kod to pusta konfiguracja CI Lighthouse. W kolejnych krokach dodasz tę konfigurację.

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ę. To właśnie serwer umożliwia Lighthouse ładowanie strony nawet wtedy, gdy nie działają żadne inne serwery. Po zakończeniu działania Lighthouse CI serwer zostanie automatycznie wyłączony. Aby zapewnić prawidłowe wyświetlanie, skonfiguruj właściwości staticDistDir lub startServerCommand.

Jeśli 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 uruchamiające serwer. Podczas testowania Lighthouse CI uruchomi nowy proces serwera, a potem go zamknie.
```
// 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, dla których Lighthouse CI powinien uruchomić Lighthouse. Wartość właściwości url powinna być tablicą adresów URL. Tablica może 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ć dostępne na serwerze skonfigurowanym w poprzednim kroku. Dlatego jeśli uruchamiasz Lighthouse CI lokalnie, te adresy URL powinny zawierać localhost, a nie hosta produkcyjnego.
Dodaj właściwość target do obiektu ci.upload i ustaw jej wartość na 'temporary-public-storage'. Raporty Lighthouse zebrane przez Lighthouse CI zostaną przesłane do tymczasowego publicznego magazynu. Raport będzie tam dostępny przez 7 dni, a potem zostanie automatycznie usunięty. W tym przewodniku konfiguracji używana jest opcja przesyłania „tymczasowej pamięci publicznej”, ponieważ można ją szybko skonfigurować. Informacje o innych sposobach przechowywania raportów Lighthouse znajdziesz w dokumentacji.
```
upload: {
  target: 'temporary-public-storage',
}
```
Lokalizacja zapisu raportu będzie podobna do tej:
```
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
```
(Ten adres URL nie zadziała, ponieważ raport został już usunięty).
Uruchom interfejs wiersza poleceń Lighthouse CI w terminalu za pomocą polecenia autorun. Narzędzie Lighthouse uruchomi się 3 razy i prześle raport dotyczący mediany Lighthouse.
```
lhci autorun
```
Jeśli masz prawidłowo skonfigurowany Lighthouse CI, uruchomienie tego polecenia powinno spowodować wyświetlenie danych wyjściowych podobnych 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.
```
W wyjściu konsoli możesz zignorować komunikat GitHub token not set. Token GitHub jest potrzebny tylko wtedy, gdy chcesz używać CI Lighthouse z akcją GitHub. W dalszej części tego artykułu wyjaśniamy, jak skonfigurować działanie w GitHub.

Kliknięcie w wyniku linku zaczynającego się od https://storage.googleapis.com... spowoduje przejście do raportu Lighthouse odpowiadającego średniej wartości Lighthouse.

Wartości domyślne 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 za każdym razem, gdy zostanie wykonane działanie autorun, należy zebrać 5 wyników Lighthouse.

Zaktualizuj aplikację lighthouserc.js, aby korzystać z usługi numberOfRuns:

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

Ponownie uruchom polecenie autorun:

lhci autorun

Dane wyjściowe terminala powinny wskazywać, że Lighthouse został uruchomiony 5 razy zamiast domyślnych 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.

Więcej informacji o innych opcjach konfiguracji znajdziesz w dokumentacji dotyczącej CI Lighthouse.

Konfigurowanie procesu CI do uruchamiania Lighthouse CI

CI Lighthouse można używać z ulubionym narzędziem CI. Sekcja Skonfiguruj dostawcę CI w dokumentacji Lighthouse CI zawiera przykładowy kod pokazujący, jak włączyć Lighthouse CI do plików konfiguracji popularnych narzędzi CI. Przykładowe fragmenty kodu pokazują, jak uruchomić w Lighthouse CI pomiary wydajności w trakcie procesu CI.

Dobrym punktem wyjścia do monitorowania wydajności jest korzystanie z Lighthouse CI do zbierania pomiarów wydajności. Zaawansowani użytkownicy mogą jednak pójść o krok dalej i wykorzystać CI Lighthouse do anulowania kompilacji, jeśli nie spełniają zdefiniowanych wstępnie kryteriów, takich jak przejście określonych audytów 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 stwierdzeń:

off: ignoruj stwierdzenia
warn: wypisuje błędy do stderr
error: wypisuje błędy do stderr i kończy Lighthouse CI z wartością kodu wyjściowego inną niż 0.

Poniżej znajdziesz przykład konfiguracji lighthouserc.js zawierającej stwierdzenia. Ustawia asercje dla wyników kategorii wydajności i ułatwień dostępu w Lighthouse. Aby to przetestować, dodaj do pliku lighthouserc.js twierdzenia pokazane poniżej, a potem ponownie uruchom CI Lighthouse.

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

Dane wyjściowe wygenerowane przez konsolę będą wyglądały tak:

Zrzut ekranu pokazujący komunikat o ostrzeganiu wygenerowany przez Lighthouse CI

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

Konfigurowanie działania GitHub w celu uruchomienia Lighthouse CI

Do uruchamiania Lighthouse CI można użyć GitHub Action. Dzięki temu za każdym razem, gdy zmiana kodu zostanie wypchnięta do dowolnej gałęzi repozytorium GitHub, zostanie wygenerowany nowy raport Lighthouse. Możesz go używać w połączeniu ze sprawdzeniem stanu, aby wyświetlać wyniki przy każdym żądaniu pull.

Zrzut ekranu z sprawdzaniem stanu w GitHub

W katalogu głównym repozytorium utwórz katalog o nazwie .github/workflows. Procesy związane z Twoim projektem będą przechowywane w tym katalogu. Przepływ pracy to proces, który jest wykonywany w określonym czasie (np. gdy jest przesyłany kod) i składa się z jednego lub większej liczby działań.
```
mkdir .github
mkdir .github/workflows
```
W folderze .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 następujący tekst do: lighthouse-ci.yaml.

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 tworzy przepływ pracy składający się z pojedynczego zadania, które będzie wykonywane za każdym razem, gdy nowy kod zostanie przesłany do repozytorium. To zadanie składa się z 4 etapów:

Sprawdź repozytorium, w którym będzie wykonywany CI Lighthouse.
Instalowanie i konfigurowanie Node
Instalowanie wymaganych pakietów npm
Uruchom Lighthouse CI i prześlij wyniki do tymczasowej pamięci publicznej.

Zatwierdź te zmiany i prześlij je do GitHuba. Jeśli powyższe czynności zostały wykonane poprawnie, przesłanie kodu do GitHuba spowoduje uruchomienie dodanego przed chwilą przepływu pracy.
Aby sprawdzić, czy Lighthouse CI zostało uruchomione, i wyświetlić wygenerowany raport, otwórz kartę Działania w projekcie. W ramach ostatniego zatwierdzenia powinien być widoczny przepływ pracy Build project and Run Lighthouse CI.

Na karcie Działania możesz przejść do raportu Lighthouse dotyczącego konkretnego zatwierdzenia. Kliknij zatwierdzanie, a potem krok przepływu pracy Lighthouse CI, a następnie rozwiń wyniki kroku uruchomienie Lighthouse CI.

Właśnie skonfigurowałeś/skonfigurowałaś działanie GitHub, aby uruchomić CI Lighthouse. Najlepiej sprawdza się w połączeniu z sprawdzaniem stanu w GitHubie.

Konfigurowanie kontroli stanu na GitHubie

Jeśli jest skonfigurowana, sprawdzanie stanu to wiadomość, która pojawia się w każdej wersji roboczej. Zwykle zawiera informacje takie jak wyniki testu lub powodzenie kompilacji.

Zrzut ekranu karty „Ustawienia” w GitHubie

Poniżej znajdziesz instrukcje konfigurowania sprawdzania stanu CI Lighthouse.

Otwórz stronę Aplikacja GitHub Lighthouse CI i kliknij Skonfiguruj.
(Opcjonalnie) Jeśli należysz do kilku organizacji w GitHub, wybierz organizację, która jest właścicielem repozytorium, w przypadku którego chcesz używać CI Lighthouse.
Wybierz Wszystkie repozytoria, jeśli chcesz włączyć CI Lighthouse we wszystkich repozytoriach, lub Tylko wybrane repozytoria, jeśli chcesz używać tej funkcji tylko w wybranych repozytoriach, a potem wybierz te repozytoria. Następnie kliknij Zainstaluj i autoryzuj.
Skopiuj wyświetlony token. Użyjesz go w następnym kroku.
Aby dodać token, otwórz stronę Ustawienia w repozytorium GitHub, kliknij Tajemnice, a potem Dodaj nowy sekret.
W polu Nazwa wpisz LHCI_GITHUB_APP_TOKEN, a w polu Wartość wpisz token skopiowany w ostatnim kroku. Następnie kliknij przycisk Dodaj sekret.
Otwórz plik lighthouse-ci.yaml i dodaj tajny klucz nowego ś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 nową prośbę o przechwycenie lub wyślij zatwierdzone zmiany do istniejącej prośby o przechwycenie.

Konfigurowanie serwera CI Lighthouse

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

Zrzut ekranu panelu Lighthouse CI Server

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

Wybierz, które zatwierdzenia chcesz porównać.
Kwota, o jaką zmienił się wynik w Lighthouse między 2 zatwierdzeniami.
Ta sekcja zawiera tylko dane, które uległy zmianie między 2 komitami.
Regresje są wyróżnione na różowo.
Ulepszenia są wyróżnione na niebiesko.

Serwer Lighthouse CI Server najlepiej nadaje się dla użytkowników, którzy potrafią wdrażać własną infrastrukturę i nią zarządzać.

Informacje o konfigurowaniu serwera CI Lighthouse, w tym przepisy na wdrażanie za pomocą Heroku i Dockera, znajdziesz w tych instrukcjach.

Więcej informacji

repozytorium GitHub Lighthouse CI