Monitorowanie wydajności za pomocą Lighthouse CI

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

Katie Hempenius
Katie Hempenius
X

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;
  • Skonfiguruj dostawcę CI, aby przeprowadzać 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.
  • tworzenie panelu skuteczności i magazynu danych na potrzeby raportów Lighthouse.

Omówienie

Lighthouse CI to zestaw 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 CI Lighthouse są dostępne w interfejsie wiersza poleceń Lighthouse CI. (Uwaga: to narzędzie jest inne niż Lighthouse CLI). Interfejs wiersza poleceń Lighthouse CI udostępnia zestaw poleceń do korzystania z 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 wydajności w czasie za pomocą panelu udostępnianego przez Lighthouse Server;

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 lokalnie oraz jak skonfigurować lighthouserc.js. Uruchomienie narzędzia wiersza poleceń Lighthouse CI lokalnie to najprostszy sposób na sprawdzenie, czy lighthouserc.js jest prawidłowo skonfigurowany.

  1. 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ązanej z CI Lighthouse. 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.

  2. W katalogu głównym repozytorium utwórz lighthouserc.js plik konfiguracji.

    touch lighthouserc.js

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

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

  4. 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 wtedy, gdy nie działają żadne inne serwery. Po zakończeniu działania Lighthouse CI serwer zostanie automatycznie wyłączony. Aby mieć pewność, że wyświetlanie działa prawidłowo, 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',
}

  5. 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']
}

  6. 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. Ten przewodnik po konfiguracji używa opcji przesyłania „tymczasowy publiczny magazyn danych”, ponieważ jest ona szybka w konfigurowaniu. Informacje o innych sposobach przechowywania raportów Lighthouse znajdziesz w dokumentacji.

    upload: {
  target: 'temporary-public-storage',
}

    Lokalizacja 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 zadziała, ponieważ raport został już usunięty).

  7. Uruchom interfejs wiersza poleceń Lighthouse CI w terminalu za pomocą polecenia autorun. Spowoduje to uruchomienie Lighthouse 3 razy i przesłanie średniego raportu 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.

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

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

  9. 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 konfiguracji Lighthouse CI.

Konfigurowanie procesu CI do uruchamiania CI Lighthouse

Lighthouse CI można używać z ulubionym narzędziem CI. W sekcji Konfigurowanie dostawcy CI Lighthouse dokumentacji CI Lighthouse znajdziesz przykłady kodu pokazujące, jak włączyć CI Lighthouse do plików konfiguracyjnych popularnych narzędzi CI. Te przykłady kodu pokazują, jak uruchamiać Lighthouse CI w celu zbierania pomiarów wydajności podczas 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 stwierdzenia dotyczące wyników kategorii wydajności i dostępności 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: {
      // ...
    },
  },
};

Wygenerowany przez niego komunikat na konsoli będzie wyglądał tak:

Zrzut ekranu pokazujący komunikat ostrzeżenia wygenerowany przez Lighthouse CI

Więcej informacji o założeniach CI Lighthouse 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. Użyj tego w połączeniu z sprawdzeniem stanu, aby wyświetlać te wyniki w przypadku każdego żądania pull.

Zrzut ekranu z sprawdzaniem stanu w GitHub

  1. 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

  2. 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

  3. 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 tworzy przepływ pracy składający się z jednego 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 wykonywana integracja CI Lighthouse
    • Instalowanie i konfigurowanie Node
    • Instalowanie wymaganych pakietów npm
    • Uruchom Lighthouse CI i prześlij wyniki do tymczasowego publicznego miejsca na dane.

  4. Zatwierdź te zmiany i prześlij je do GitHuba. Jeśli wykonasz opisane powyżej czynności, wypchnięcie kodu do GitHuba spowoduje uruchomienie właśnie dodanego przez Ciebie workflow.

  5. 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.

    Zrzut ekranu karty „Ustawienia” w GitHubie

    Raport Lighthouse odpowiadający konkretnemu commitowi możesz otworzyć z karty Działania. Kliknij zatwierdzanie, a potem krok przepływu pracy Lighthouse CI, a następnie rozwiń wyniki kroku uruchomienie Lighthouse CI.

    Zrzut ekranu karty „Ustawienia” w GitHubie

    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 sprawdzania stanu w GitHubie

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

Zrzut ekranu karty „Ustawienia” w GitHubie

Poniżej znajdziesz instrukcje konfigurowania sprawdzania stanu CI Lighthouse.

  1. Otwórz stronę Aplikacji Lighthouse CI na GitHub i kliknij Skonfiguruj.

  2. (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.

  3. 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.

  4. Skopiuj wyświetlony token. Użyjesz go w następnym kroku.

  5. Aby dodać token, otwórz stronę Ustawienia w repozytorium GitHub, kliknij Tajemnice, a potem Dodaj nowy sekret.

    Zrzut ekranu karty „Ustawienia” w GitHubie

  6. W polu Name (Nazwa) wpisz LHCI_GITHUB_APP_TOKEN, a w polu Value (Wartość) wklej token skopiowany w ostatnim kroku. Następnie kliknij przycisk Add secret (Dodaj tajny klucz).

  7. 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: $
  1. 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ż pełnić rolę prywatnego długoterminowego magazynu danych dla raportów Lighthouse.

Zrzut ekranu panelu Lighthouse CI Server
Zrzut ekranu pokazujący porównanie 2 raportów Lighthouse na serwerze CI Lighthouse
  1. Wybierz, które zatwierdzenia chcesz porównać.
  2. Zmiana wyniku Lighthouse między 2 komitami.
  3. Ta sekcja zawiera tylko dane, które uległy zmianie między 2 komitami.
  4. Regresje są wyróżnione na różowo.
  5. Ulepszenia są wyróżnione na niebiesko.

Serwer CI Lighthouse najlepiej nadaje się dla użytkowników, którzy czują się pewniej, wdrażając i zarządzając własną infrastrukturą.

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

Więcej informacji