Monitorowanie wydajności za pomocą Lighthouse CI

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

Katie Hempenius
Katie Hempenius

Lighthouse CI to pakiet narzędzi do używania Lighthouse w trakcie 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że to służyć do określania wpływu konkretnych zmian w kodzie lub do sprawdzania progów wydajności w trakcie ciągłych procesów 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.

Główną funkcją Lighthouse CI jest interfejs wiersza poleceń Lighthouse. Uwaga: jest to inne narzędzie niż interfejs wiersza poleceń Lighthouse. Interfejs wiersza poleceń Lighthouse CI udostępnia zestaw komend do korzystania z Lighthouse CI. Na przykład polecenie autorun wykonuje kilka uruchomień narzędzia Lighthouse, identyfikuje medianę raportu Lighthouse i przesyła raport, żeby go przechowywać. 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życie w Lighthouse CI działania GitHub, które 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.

  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 plik konfiguracji lighthouserc.js.

    touch lighthouserc.js
    
  3. Dodaj do 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 */
        },
      },
    };
    
  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ć podana w postaci tablicy adresów URL. Ta tablica może zawierać co najmniej 1 adres URL. Domyślnie Lighthouse CI uruchomi Lighthouse 3 razy w odniesieniu do 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. 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).

  7. 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ć Lighthouse CI z działaniem GitHub. Sposób konfigurowania akcji na GitHubie wyjaśniamy w dalszej części tego artykułu.

    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 pole lighthouserc.js, aby używać właściwości 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 CI Lighthouse.

Konfigurowanie procesu CI do uruchamiania Lighthouse CI

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 konfiguracji 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 asercji:

  • 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 wypróbować, dodaj do pliku lighthouserc.js podane niżej asercje, a potem ponownie uruchom Lighthouse CI.

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 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 działa w ustalonym z góry czasie (np. po wypchnięciu kodu) i składa się z jednego lub wielu 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 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 węzła
    • Zainstaluj wymagane pakiety 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 dodanego przez Ciebie workflow.

  5. Aby sprawdzić, czy usługa Lighthouse CI została uruchomiona, 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 zatwierdzenie, kliknij krok przepływu pracy Lighthouse CI, a potem rozwiń wyniki kroku Uruchom Lighthouse CI.

    Zrzut ekranu karty „Ustawienia” w GitHubie

    Właśnie skonfigurowano działanie GitHub umożliwiające uruchomienie Lighthouse CI. Najlepiej sprawdza się w połączeniu z sprawdzaniem stanu w GitHubie.

Konfigurowanie sprawdzania stanu w GitHubie

Sprawdzanie stanu (jeśli zostało skonfigurowane) to komunikat wyświetlany przy każdym PR i zwykle zawiera informacje, takie jak wyniki testu lub powodzenie kompilacji.

Zrzut ekranu karty „Ustawienia” na GitHubie

Poniżej znajdziesz instrukcje konfigurowania sprawdzania stanu CI Lighthouse.

  1. Otwórz stronę Aplikacja GitHub Lighthouse CI 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 Nazwa wpisz LHCI_GITHUB_APP_TOKEN, a w polu Wartość wpisz token skopiowany w ostatnim kroku. Następnie kliknij przycisk Dodaj sekret.

  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ż 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
  1. Wybierz, które zatwierdzenia chcesz porównać.
  2. Wielkość zmiany wyniku Lighthouse między 2 komitami.
  3. Ta sekcja zawiera tylko wskaźniki, które uległy zmianie między 2 zatwierdzeniami.
  4. Regresje są zaznaczone 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 CI Lighthouse, w tym przepisy na wdrażanie za pomocą Heroku i Dockera, znajdziesz w tych instrukcjach.

Więcej informacji